Los datos estructurados se refieren al marcado de Schema.org, que a menudo se implementa como JSON-LD. Ayudan a los sistemas de búsqueda a interpretar información clave de una página y sus entidades. Pueden habilitar rich results en Google Search cuando corresponde y facilitar que otros sistemas entiendan el significado de la página, pero no son una vía garantizada para que tu contenido se cite en respuestas con IA.
Google indica de forma explícita que no existe un marcado especial de Schema.org obligatorio para AI Overviews o AI Mode. Trátalo como marcado semántico que aclara lo que ya es visible en la página, no como un atajo de posicionamiento para IA. Debe coincidir con el contenido visible, y solo deberías usar tipos como Organization, Article, Product y SoftwareApplication cuando describan con precisión la página.
Qué pueden y qué no pueden hacer los datos estructurados en la búsqueda con IA
Lo que sí pueden hacer - Ayudar a los sistemas de búsqueda a entender información de una página y habilitar rich results compatibles cuando aplique. - Reducir la ambigüedad sobre entidades y atributos de la página al aportar afirmaciones explícitas legibles por máquina que coinciden con el contenido visible. - Mejorar la coherencia del sitio cuando las mismas entidades aparecen en varias páginas.
Lo que no pueden hacer - No garantizan la inclusión o la cita en AI Overviews, AI Mode u otras respuestas generadas por IA. - No existe un “schema de IA” dedicado. Añadir más marcado no produce automáticamente más AI Visibility. - No pueden contradecir, ampliar o “mejorar” de forma segura lo que la página muestra. Si el contenido no es visible, el marcado no debería afirmarlo.
Referencias oficiales: - https://developers.google.com/search/docs/appearance/ai-features - https://developers.google.com/search/docs/appearance/structured-data
Qué tipos de Schema priorizar
No todos los tipos de schema aportan el mismo valor. Prioriza los que describen con fidelidad tu página y que puedas mantener coherentes en todo el sitio.
Schema de Organization
Usa marcado Organization cuando la página describa realmente a tu organización y las propiedades incluidas estén respaldadas por contenido visible, por ejemplo en páginas de About, Contact o páginas de marca.
Propiedades típicas que los equipos suelen mantener:
- name, url, logo, description
- foundingDate (solo si está indicado en el sitio)
- sameAs (enlaces a perfiles oficiales que representan a tu organización)
- contactPoint, areaServed (solo si el texto visible lo respalda)
Restricción importante: no trates sameAs como un lugar para listar todos los directorios. Incluye únicamente perfiles legítimos sobre tu organización, que controles o que claramente te representen. Si tu sitio no respalda visiblemente una afirmación, no la añadas al JSON-LD.
Schema de Article
Usa marcado Article en páginas que claramente sean artículos, como entradas de blog, noticias o contenido editorial. Article puede ayudar a los sistemas de búsqueda a entender los datos básicos de una pieza: título, autor, editor y fechas.
Incluye solo lo que sea verdadero y visible, normalmente:
- headline
- author (con una página real del autor si la tienes)
- datePublished, dateModified (solo si se muestran o se presentan de forma clara en la página)
- publisher
- image
- description
- mainEntityOfPage
Recordatorio: los datos estructurados pueden ayudar a los sistemas a entender información, pero no garantizan citas en IA.
Schema de Product
Usa marcado Product solo en páginas que realmente sean fichas de producto, donde el producto descrito sea el foco visible de la página. Sigue la guía de datos estructurados de Product de Google y mantén cada propiedad alineada con lo que los usuarios pueden ver.
Referencia oficial: - https://developers.google.com/search/docs/appearance/structured-data/product
Si tu página describe software que se ofrece como producto, asegúrate de que el contenido respalda el tipo que elijas. Si es una página de producto de software, SoftwareApplication puede ser apropiado, pero solo cuando describa con precisión la entidad y el contenido visibles.
Schema de SoftwareApplication
SoftwareApplication es adecuado cuando la página trata sobre una aplicación de software específica e incluye detalles que los usuarios esperan, como qué hace, plataforma y detalles de la oferta cuando aplique. Úsalo solo si la página es visiblemente una página de aplicación de software y las propiedades coinciden con la página.
Si no tienes claro si encaja mejor Product o SoftwareApplication, elige el que mejor se ajuste a la intención visible de la página y a la entidad que estás describiendo, y no fuerces ambos a la vez salvo que esté realmente justificado por lo que presenta la página.
FAQPage y HowTo: úsalos teniendo en cuenta los límites actuales de Google
El soporte de Google ha cambiado: - Los rich results de HowTo están deprecated en Google Search. - Los rich results de FAQ están generalmente limitados a sitios gubernamentales y de salud con autoridad.
Referencia oficial: - https://developers.google.com/search/blog/2023/08/howto-faq-changes
Esto no significa que nunca debas usar estos tipos, pero sí que no deberías implementarlos esperando rich results de Google, y deberías ser especialmente estricto con la correspondencia con el contenido visible en la página.
Si incluyes marcado FAQPage: - Úsalo solo en páginas de FAQ reales, donde las preguntas y respuestas sean visibles para los usuarios. - Mantén las respuestas precisas, no promocionales y coherentes con la página.
Si incluyes marcado HowTo: - Úsalo solo cuando la página sea una guía paso a paso con pasos visibles. - No lo añadas como un truco de “formato para IA”, especialmente dada la deprecación de rich results de HowTo en Google.
Ejemplos de JSON-LD que puedes adaptar de forma segura
Trata estos ejemplos como patrones de marcado semántico. Ajústalos a tus páginas reales y elimina cualquier campo que no puedas respaldar con contenido visible.
Ejemplo de schema Organization
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Nombre de tu marca",
"url": "https://www.yourbrand.com",
"logo": "https://www.yourbrand.com/logo.png",
"description": "Descripción de una frase sobre qué hace tu marca y a quién sirve.",
"foundingDate": "2020-01-15",
"founder": {
"@type": "Person",
"name": "Nombre del fundador"
},
"sameAs": [
"https://www.linkedin.com/company/yourbrand",
"https://twitter.com/yourbrand",
"https://en.wikipedia.org/wiki/Your_Brand"
],
"contactPoint": {
"@type": "ContactPoint",
"contactType": "customer service",
"email": "support@yourbrand.com",
"url": "https://www.yourbrand.com/contact"
},
"areaServed": "US",
"knowsAbout": [
"Tu tema principal",
"Tu tema secundario",
"Tu tema terciario"
]
}
Notas para una implementación segura:
- No añadas una URL de Wikipedia o Wikidata a menos que exista de verdad y sea sobre tu organización.
- Incluye foundingDate y founder solo si esos datos se muestran en el sitio.
- Usa knowsAbout solo cuando refleje lo que tu organización demuestra cubrir en el sitio.
Ejemplo de schema FAQPage
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "¿Qué hace tu marca?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Respuesta clara y concisa que un sistema podría extraer y presentar directamente."
}
},
{
"@type": "Question",
"name": "¿Cómo se compara tu producto con alternativas?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Comparación factual que refleje lo que tu página realmente afirma y respalda."
}
}
]
}
Dadas las limitaciones actuales de Google sobre rich results de FAQ, implementa el marcado FAQPage principalmente para aclarar la semántica de la página, no como una promesa de una apariencia mejorada en búsqueda. Asegúrate de que cada pregunta y respuesta sea visible en la página y se mantenga actualizada.
Ejemplo de schema Article
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Título de tu artículo",
"author": {
"@type": "Person",
"name": "Nombre del autor",
"url": "https://www.yourbrand.com/team/author-name",
"jobTitle": "Cargo del autor",
"worksFor": {
"@type": "Organization",
"name": "Nombre de tu marca"
}
},
"datePublished": "2026-03-15",
"dateModified": "2026-03-28",
"publisher": {
"@type": "Organization",
"name": "Nombre de tu marca",
"logo": {
"@type": "ImageObject",
"url": "https://www.yourbrand.com/logo.png"
}
},
"description": "Meta description que resume el principal aprendizaje del artículo.",
"image": "https://www.yourbrand.com/images/article-image.jpg",
"mainEntityOfPage": "https://www.yourbrand.com/blog/article-slug"
}
Incluye dateModified solo si realmente registras y muestras actualizaciones significativas. Para el marcado de autor, asegúrate de que la identidad y el rol del autor estén respaldados por firmas visibles y, cuando sea posible, por páginas de autor.
Cómo usa Google los datos estructurados y qué implica para las funciones con IA
La documentación de datos estructurados de Google es clara sobre su función principal: los datos estructurados ayudan a Google a entender información elegible y a habilitar rich results compatibles. No garantizan mejoras de ranking ni garantizan que ninguna función de IA cite tu página.
Para AI Overviews y AI Mode en concreto, Google afirma que no se requiere un marcado especial. En la práctica, esto implica que tu estrategia de marcado debería centrarse en: - Precisión y coherencia con lo visible en la página - Elegir tipos de schema que realmente encajen con la intención de la página - Mantener el marcado a medida que tu contenido cambia
Referencias: - https://developers.google.com/search/docs/appearance/ai-features - https://developers.google.com/search/docs/appearance/structured-data
Reglas de implementación para evitar los fallos más comunes
Mantén el marcado alineado con el contenido visible
Los datos estructurados deben coincidir con lo que los usuarios pueden ver. Si añades propiedades que la página no respalda, puedes confundir a los sistemas que comparan el marcado con el texto y los elementos de la interfaz. Una regla interna simple: si un usuario no puede verificarlo en la página, no lo marques en esa página.
Usa el tipo correcto para la página, no para el resultado que quieres
No añadas marcado Product a una homepage de marketing que no presenta un producto específico en formato de ficha. No añadas marcado Article a landing pages. Usa marcado Organization donde realmente se describa la organización, normalmente en la homepage y en páginas de About.
Evita “ampliaciones invisibles” de tus afirmaciones
No uses schema para colar funciones extra, premios, precios, valoraciones o comparaciones que no aparecen en la página. Esto puede crear incoherencias internas en tu sitio y debilitar señales de confianza.
Mantén las URLs estables y correctas
Problemas comunes que rompen la utilidad del marcado:
- URLs canónicas incorrectas en mainEntityOfPage
- Enlaces sameAs rotos
- URL del logo que redirige o devuelve 404
- URLs de autor que no existen
Mantén fechas y autoría con responsabilidad
Las fechas pueden ser útiles cuando reflejan comportamientos reales de publicación y actualización. Evita actualizar dateModified de forma mecánica sin revisiones significativas. Si tu sitio usa páginas de autor, mantén consistentes los nombres de autor entre firmas y schema.
Flujo de pruebas y validación
Usa dos validadores y luego confirma el marcado en la página renderizada.
-
Google Rich Results Test
https://search.google.com/test/rich-results
Útil para problemas de sintaxis y validaciones de datos estructurados elegibles para Google. -
Schema.org Validator
https://validator.schema.org/
Útil para una validación más amplia de Schema.org, más allá de lo que Google soporta. -
Confirma en el código fuente de la página
Comprueba que el bloque<script type="application/ld+json">esté presente en el HTML final renderizado y que el JSON se analice correctamente. -
Monitoriza en Google Search Console
https://search.google.com/search-console/
Usa los informes para encontrar errores y advertencias de datos estructurados.
Errores comunes de datos estructurados que conviene corregir
Marcado que contradice la página
Si el marcado afirma algo distinto de lo que muestra la página, los sistemas que hacen comprobaciones cruzadas pueden descartarlo. Mantén la descripción de tu Organization, las etiquetas de categoría y los atributos principales coherentes en todo el sitio.
Keyword stuffing en campos de schema
Los campos de schema no son meta tags. Escribe descripciones pensando primero en personas y mantén el contenido factual. Si no pondrías esa frase en la página, no la pongas en el JSON-LD.
Mal uso de FAQPage y HowTo
Con las limitaciones actuales de Google, no añadas FAQPage o HowTo esperando rich results. Úsalos solo cuando describan con precisión contenido visible y estés dispuesto a mantenerlos como cualquier bloque de contenido on page.
Usar el tipo correcto de schema en la página equivocada
Esto suele pasar con Product schema en páginas top of funnel o con Article schema en landings de comparación. Trata el schema como un reflejo de la intención de la página, no como una herramienta para forzar elegibilidad.
Marcar solo una página
Si tu sitio publica artículos, tiene páginas de producto y una sección About, considera una base coherente: - Organization en tu homepage y página About donde se describa la organización - Article en páginas editoriales - Product o SoftwareApplication en fichas de producto - FAQPage en páginas de FAQ reales en tu centro de ayuda
Artículos relacionados
CTA: mide cómo describen tu marca las plataformas de IA
Si estás trabajando los datos estructurados para reducir la ambigüedad sobre tus entidades, normalmente también querrás una forma de comprobar si ese trabajo se refleja con el tiempo en cómo hablan de ti los sistemas de IA. Friction AI es una opción para hacer seguimiento de visibilidad en varios asistentes de IA y comparar salidas conforme cambia tu sitio.
