Datos estructurados (schema.org): por qué la IA cita a unos y a otros no

Qué son los datos estructurados

Una máquina que lee tu web ve texto, pero no siempre entiende qué es cada cosa. Los datos estructurados le ponen etiquetas: esto es un producto, esto es su precio, esto es una pregunta frecuente, este es el autor. El vocabulario estándar se llama schema.org y lo usan tanto los buscadores como los modelos de IA. Esta guía explica por qué ayudan a que te citen, qué tipos poner en cada página con ejemplos completos, los errores que restan credibilidad y cómo comprobar que están bien.

JSON-LD, la forma fácil

Hay varias maneras de escribir schema, pero la recomendada es JSON-LD: un bloque de script en formato JSON que colocas en la cabecera o el cuerpo de la página. No cambia nada de lo que ve el usuario y queda separado del HTML visible, así que es fácil de generar y revisar. Si usas Cursor, Bolt o Lovable, pedirle a tu IA que genere el JSON-LD de una página concreta es cuestión de un prompt. La alternativa, los microdatos incrustados en las etiquetas HTML, funciona igual pero es más difícil de mantener.

Por qué ayuda a que te citen

Cuando un modelo tiene que resumir tu página, el schema reduce la ambigüedad. En lugar de inferir que un número es un precio, lo sabe. En lugar de adivinar quién escribió el artículo, lo lee. En lugar de deducir que "Scanaris" es una empresa y no una persona, lo tiene declarado. Menos adivinar significa más confianza, y más confianza significa más probabilidad de ser usado como fuente. Además, el schema conecta tu web con el resto de internet: el campo sameAs enlaza con tus perfiles y el modelo entiende que todo habla de la misma entidad.

Qué tipos añadir y con qué propiedades

• Organization en la home: nombre, logo, URL, descripción en una frase y sameAs con tus perfiles públicos.
• SoftwareApplication (o Product) en la página de producto o precios: nombre, descripción, categoría, sistema operativo o plataforma, y offers con precio y moneda.
• FAQPage donde haya preguntas y respuestas reales y visibles.
• Article o BlogPosting en los posts, con autor, fecha de publicación y de modificación.
• BreadcrumbList para dar contexto de dónde encaja cada página.
• WebSite en la home, con el nombre del sitio, que ayuda a que aparezca correctamente en los resultados.

No los añadas todos porque sí. Marca solo lo que de verdad está en la página.

Un ejemplo completo para una app

Así queda el bloque de la home de un producto de software, con la organización y la aplicación en un mismo gráfico:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://tudominio.com/#org",
      "name": "Tu Producto",
      "url": "https://tudominio.com",
      "logo": "https://tudominio.com/logo.png",
      "description": "Tu Producto es un [qué es] para [quién] que [qué consigue].",
      "sameAs": [
        "https://github.com/tuproducto",
        "https://www.linkedin.com/company/tuproducto",
        "https://x.com/tuproducto"
      ]
    },
    {
      "@type": "SoftwareApplication",
      "name": "Tu Producto",
      "applicationCategory": "DeveloperApplication",
      "operatingSystem": "Web",
      "url": "https://tudominio.com",
      "description": "Tu Producto es un [qué es] para [quién] que [qué consigue].",
      "publisher": { "@id": "https://tudominio.com/#org" },
      "offers": {
        "@type": "Offer",
        "price": "24",
        "priceCurrency": "EUR",
        "url": "https://tudominio.com/pricing"
      }
    }
  ]
}
</script>

Fíjate en que la descripción es la misma frase en los dos bloques, y debería ser la misma que aparece en la home, en la meta descripción y en el llms.txt. Esa repetición exacta es lo que los modelos acaban citando.

Y uno para las preguntas frecuentes

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "¿Tu Producto modifica mi web?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Hace comprobaciones de solo lectura sobre información pública."
      }
    }
  ]
}
</script>

Cada pregunta del JSON tiene que existir, con el mismo texto, en la parte visible de la página.

Los errores más comunes

• Marcar lo que no se ve. Preguntas frecuentes que no aparecen en la página, reseñas inventadas, un precio en el JSON distinto del de la página. Resta credibilidad y puede traerte una acción manual de Google.
• Datos caducados. Cambias el precio en la página y olvidas el schema. Genera el JSON-LD desde la misma fuente de datos que la página, no a mano.
• Nombre inconsistente. "Tu Producto" en la home, "TuProducto" en el schema, "tu-producto" en los perfiles. Elige una grafía y úsala en todas partes.
• Tipo equivocado. Un Product físico para un servicio web, o un Article en una página de precios.
• JSON inválido. Una coma de más y el bloque entero se ignora en silencio.

Dónde ponerlo según tu framework

En Next.js, un elemento script con type="application/ld+json" en el layout o en la página, con el JSON serializado desde un objeto. En Nuxt, con useHead y un script del mismo tipo. En una SPA de Vite, en el index.html si el bloque es estático, o inyectado en el prerender si varía por página. Lo importante es que llegue en el HTML inicial: un JSON-LD que solo existe tras ejecutar JavaScript no lo leen los bots que no renderizan.

Cómo comprobar que está bien

Pide tu página con curl y busca el bloque:

curl -s https://tudominio.com/ | grep -o 'application/ld+json' | wc -l

Si sale cero, no llega en el HTML. Después valida el contenido con la herramienta de resultados enriquecidos de Google o con el validador de schema.org, que te marcan errores de sintaxis y propiedades desconocidas. Y léelo tú: ¿dice lo mismo que la página? Si no, uno de los dos miente.

Scanaris revisa tu schema

El pilar de visibilidad ante IA de Scanaris detecta si tienes datos estructurados, de qué tipo, si llegan en el HTML sin JavaScript y si tienen sentido para la página, y te da un fix prompt con el JSON-LD sugerido para pegar en tu IA. Es una comprobación de solo lectura sobre el HTML público de tu web. Forma parte de la guía de AEO y de la revisión de SEO y AEO en la misma página.

Preguntas frecuentes

¿Google penaliza el schema incorrecto?

El schema con errores de sintaxis simplemente se ignora. El schema engañoso (marcar reseñas o preguntas que no existen) puede recibir una acción manual que te quita los resultados enriquecidos. Marca solo lo visible.

¿JSON-LD o microdatos?

JSON-LD. Es lo que recomiendan Google y schema.org, se genera desde datos sin tocar el HTML visible y es mucho más fácil de mantener.

¿Hace falta en todas las páginas?

En las públicas que quieres que se entiendan: home, producto, precios, blog, preguntas frecuentes. El panel privado no lo necesita porque nadie externo lo lee.