Schema markup para AI Search: qué datos estructurados usar en 2026

El schema markup es código de datos estructurados (normalmente JSON-LD) que describe el contenido de una página para las máquinas: quién es el autor, qué producto ofreces o cuándo se actualizó un artículo. Para AI Search no garantiza que te citen, pero reduce la ambigüedad y refuerza la claridad de tu entidad y de tus contenidos.

Resumen rápido

• El schema es una capa de claridad, no un atajo: debe reflejar lo que ya es visible en la página.
• Para un sitio SaaS o un blog, los tipos más útiles son Organization, WebSite, SoftwareApplication, BlogPosting/Article y BreadcrumbList.
• Ningún dato estructurado garantiza aparecer en AI Overviews, AI Mode, ChatGPT search o Perplexity.
• La regla práctica: cada propiedad del JSON-LD debe tener un equivalente visible y verificable en la página.
• Valida siempre antes de publicar y vuelve a revisar cuando cambies la plantilla.

¿Qué es el schema markup y para qué sirve en AI Search?

El schema markup es un vocabulario compartido, definido en schema.org, con el que anotas tu página para que un sistema automatizado entienda de qué trata y sobre qué entidades habla. En AI Search ayuda a que el contenido se interprete sin adivinar el contexto, aunque la citación depende de muchas otras señales.

Google lo explica en su introducción a los datos estructurados: el markup ayuda a comprender el contenido de la página y la información sobre las entidades que aparecen en ella. Lo que importa para la búsqueda con IA es esa palabra, "entender": el schema es una forma de decir con precisión quién habla, de qué y desde cuándo.

¿El schema hace que aparezca mi página en AI Overviews?

No. Google no afirma que los datos estructurados sean un requisito ni una palanca garantizada para aparecer en AI Overviews o AI Mode. Su documentación sobre funciones de IA en Search se centra en las bases de siempre: contenido útil, página indexable y datos estructurados que coincidan con el texto visible.

Por eso conviene tratar el schema como una señal de apoyo. Funciona junto a otras piezas:

• Contenido citable, con respuestas directas al inicio de cada sección.
• HTML inicial renderizado, sin depender de JavaScript para mostrar el texto principal.
• Enlaces internos que dejen clara la estructura del tema.
• Autoridad externa y menciones fiables.
• Actualización real y fechas honestas.
• Una entidad de marca consistente en todo el sitio.

Si quieres entender cómo se arma una respuesta con varias fuentes, lee query fan-out: por qué una búsqueda se convierte en varias preguntas.

¿Qué tipos de schema necesita un SaaS o un blog?

Un SaaS o un blog corporativo necesita pocos tipos, bien hechos: Organization para la empresa, WebSite para el sitio, SoftwareApplication para el producto, BlogPosting para cada artículo y BreadcrumbList para la jerarquía. Añadir más tipos no mejora nada si la página no los respalda con contenido visible.

Tipo	Dónde va	Qué comunica
Organization	Página de inicio o "Sobre nosotros"	Nombre, logo, URL y perfiles oficiales de la empresa
WebSite	Página de inicio	El sitio como entidad y, si existe, su buscador interno
SoftwareApplication	Página del producto	Qué es la aplicación, categoría y sistema de uso
BlogPosting / Article	Cada artículo	Titular, autor, fechas, imagen y editor
BreadcrumbList	Páginas con migas de pan	La jerarquía de navegación
FAQPage	Páginas con preguntas visibles	Pares de pregunta y respuesta que el lector ve

Para ver todas las propiedades posibles de cada tipo, la referencia completa del vocabulario es schema.org.

¿Qué propiedades debe incluir el schema de un artículo?

Un artículo debe llevar, como mínimo, titular, descripción, fecha de publicación, fecha de modificación (solo si realmente lo actualizaste), autor, editor, imagen y la URL de la página como entidad principal. Con ellas, un sistema puede atribuir el texto a una persona y a una organización y saber qué tan reciente es.

La lista práctica de propiedades para BlogPosting o Article:

1. headline: el título real del artículo.
2. description: un resumen fiel, no un texto promocional distinto.
3. datePublished: la fecha original.
4. dateModified: solo cuando haya una actualización de contenido real.
5. author: una persona identificable, con su página de autor si existe.
6. publisher: la organización editora.
7. image: una imagen que esté en la página.
8. mainEntityOfPage: la URL canónica del artículo.

Un detalle que importa en 2026: si cambias dateModified sin tocar el contenido, creas una señal falsa de frescura. Es mejor una fecha antigua y honesta que una reciente inventada.

¿Qué pasa con FAQPage y HowTo?

FAQPage sigue siendo un tipo válido y útil para describir preguntas y respuestas que el usuario ve en la página, pero los resultados enriquecidos de preguntas frecuentes en Google están limitados desde 2023 a ciertos sitios, según su documentación de FAQPage. Su valor hoy es semántico, no un adorno en la SERP.

Esto lleva a una decisión editorial sensata: escribe la sección de preguntas frecuentes porque ayuda al lector y a los motores de respuesta a extraer respuestas cortas, y marca esas preguntas solo si aparecen tal cual en la página. No lo hagas para "ganar un rich result". HowTo, por su parte, perdió buena parte de su visibilidad en Google, así que no merece prioridad para un blog.

¿Cómo mantengo el schema coherente con el contenido visible?

Usa una regla de espejo: cada afirmación del JSON-LD debe poder verse en la página. Si el schema dice que el autor es una persona, esa persona aparece firmando el artículo. Si declara una fecha, se ve la fecha. Si marca preguntas, esas preguntas están escritas. Lo que no tenga espejo en la página, se elimina del schema.

Esta es la auditoría de espejo que recomendamos en cinco pasos:

1. Abre la página y el JSON-LD lado a lado (la herramienta de inspección del navegador sirve).
2. Recorre cada propiedad y localiza su equivalente visible.
3. Marca las propiedades sin espejo: reseñas, precios, valoraciones, FAQ ocultas o imágenes que no aparecen.
4. Elimina o corrige esas propiedades en la plantilla, no página por página.
5. Repite la revisión cuando cambie el diseño, el tema de WordPress o el plugin de SEO.

El punto 4 es clave: el schema casi siempre lo genera una plantilla, el tema o un plugin de SEO. Un error en la plantilla se replica en cientos de páginas, y también se corrige de una sola vez.

¿Qué no debo marcar nunca con schema?

No marques contenido que el usuario no ve ni información que no puedas respaldar: reseñas inventadas, valoraciones sin una fuente real, precios que no coinciden con la página o preguntas que no existen. Las directrices de datos estructurados de Google advierten sobre este tipo de prácticas, y además dañan la confianza de cualquier sistema que lea tus datos.

Lista corta de errores frecuentes:

• Marcar valoraciones o reseñas que no existen en la página.
• Usar el mismo FAQPage en decenas de páginas con preguntas que no aparecen en ellas.
• Cambiar dateModified sin cambiar el contenido.
• Declarar un autor genérico ("Admin") o una organización distinta en cada plantilla.
• Duplicar el mismo tipo de schema desde el tema y desde un plugin, con valores diferentes.

¿Cómo valido el schema antes de publicar?

Valida con la Prueba de Resultados Enriquecidos de Google para ver qué elementos pueden generar resultados enriquecidos, y con un validador de JSON-LD para comprobar la sintaxis. Después, compara a mano con la página renderizada: ninguna herramienta sabe si tu contenido visible coincide.

Antes de publicar, revisa esta lista:

• El JSON-LD no tiene errores de sintaxis.
• El contenido marcado aparece en la página.
• La URL, el logo y el nombre de la organización son idénticos en todas las plantillas.
• Las fechas son reales.
• No hay contenido oculto marcado.

Después de publicar, el informe de mejoras de Search Console te avisa si Google detecta problemas de datos estructurados en el sitio.

¿Cómo encaja el schema en un flujo editorial con IA?

Un flujo editorial con IA debería tratar el schema como parte de la plantilla de publicación, no como una tarea manual por artículo. El texto lo genera y revisa el equipo; el markup se produce de forma consistente a partir de campos reales (autor, fecha, imagen, título). Así el schema nunca depende de que alguien se acuerde de añadirlo.

En Contentor ese es el enfoque general. La plataforma está pensada para generar artículos con IA con estructura SEO (la guía completa está en cómo generar artículos con IA), publicarlos en WordPress y mantener el ritmo con Auto Blog. Tu tema de WordPress o tu plugin de SEO se encarga de la capa de datos estructurados a partir de los campos del artículo, y tú validas el resultado. Después puedes medir en el panel de resultados con Search Console y en AI Visibility si el contenido empieza a ser citado por ChatGPT.

Si montas un sitio nuevo, este orden suele funcionar mejor: primero el contenido útil, luego la plantilla con schema correcto y, solo entonces, los enlaces que aportan autoridad. El schema no sustituye ninguno de los dos. Y para reforzar la capa de entidades, te servirá entidades y SEO semántico.

¿Qué tiene que ver el schema con AEO y GEO?

El schema es una de las técnicas de apoyo de AEO (optimización para motores de respuesta) y de GEO (optimización para motores generativos), porque ayuda a que las máquinas atribuyan bien el contenido y la entidad. No es el núcleo de ninguna de las dos: lo central sigue siendo escribir respuestas claras, verificables y bien estructuradas para personas.

Si quieres ver el marco completo, revisa AEO: optimización para motores de respuesta y GEO: optimización para motores generativos. En ambos, el schema aparece como una pieza de una estrategia mayor, junto al contenido citable, la autoridad y la medición.

Preguntas frecuentes

¿El schema markup mejora el posicionamiento directamente?

No hay evidencia de que los datos estructurados sean un factor de posicionamiento directo. Su función es ayudar a los sistemas a entender mejor la página y, en algunos casos, habilitar resultados enriquecidos. El posicionamiento sigue dependiendo de la calidad del contenido, la relevancia, la autoridad y la experiencia de la página.

¿Qué formato de datos estructurados es mejor, JSON-LD o microdatos?

Google recomienda JSON-LD siempre que sea posible, porque se mantiene separado del HTML visible y es más fácil de generar y de corregir desde una plantilla. Los microdatos y RDFa también son válidos, pero en un sitio moderno, JSON-LD suele ser la opción más cómoda y menos propensa a errores de mantenimiento.

¿Necesito schema para aparecer en ChatGPT search o Perplexity?

No es un requisito conocido. Esos sistemas leen el contenido de la página y valoran la claridad, la fiabilidad de la fuente y la actualidad. El schema puede ayudar a que la información de autor, fecha y organización sea inequívoca, pero un texto bien estructurado y fácil de citar pesa mucho más que cualquier marcado.

¿Cuántos tipos de schema debo implementar?

Los necesarios para describir tus páginas reales, y no más. Un blog corporativo suele cubrirse con Organization, WebSite, BlogPosting y BreadcrumbList; un SaaS añade SoftwareApplication. Es mejor tener pocos tipos completos, consistentes y validados que muchos tipos incompletos o contradictorios.

¿Cada cuánto debo revisar el schema?

Revísalo cada vez que cambies el tema, el plugin de SEO o la plantilla del blog, y haz una auditoría periódica de muestra, por ejemplo cada trimestre. Los errores de schema suelen aparecer tras una actualización técnica y se replican en muchas páginas, así que conviene detectarlos pronto con Search Console.

¿Puedo usar IA para generar el JSON-LD?

Sí, siempre que alimentes la plantilla con datos reales y valides el resultado. La IA puede ayudarte a redactar el borrador del JSON-LD, pero no debe inventar valoraciones, precios o autores. La revisión humana y la regla de espejo siguen siendo obligatorias antes de publicar.

Si quieres que tu contenido llegue a las respuestas de IA con una base técnica sólida, Contentor te ayuda a crear, publicar y medir artículos pensados para AI Search, y a ver cuándo ChatGPT empieza a citarlos.