Inicio/Glosario/Datos estructurados
SEO técnicoDatos estructurados
Los datos estructurados son marcado en el código de una página, normalmente JSON-LD con vocabulario Schema.org, que describe su contenido a las máquinas. Su función documentada es reforzar el SEO clásico y dar acceso a resultados enriquecidos (rich snippets) en buscadores.
Qué es
Datos estructurados es el marcado que se añade al HTML de una página para describir su contenido en un formato que las máquinas leen sin ambigüedad. El estándar habitual es JSON-LD con el vocabulario de Schema.org; también existe microdata. Define entidades y propiedades: tipos como Organization, Article, Product, FAQPage o BreadcrumbList y los atributos que los acompañan.
No es contenido visible para el usuario. Es una capa paralela para los buscadores. Con ese marcado, Google puede mostrar resultados enriquecidos y entender mejor las entidades de la página, lo que conecta con su Knowledge Graph y, en general, con el trabajo de Entidades y grafos de conocimiento.
Hay un matiz técnico que cambia el resultado: si el JSON-LD solo se inyecta por JavaScript, un agente que recibe el HTML en texto plano no lo ve, aunque el Rich Results Test de Google lo valide. Es el mismo problema que aborda JavaScript SEO: lo que solo existe tras renderizar el DOM puede quedar fuera del alcance de quien consume HTML crudo. El marcado tiene que servirse de forma que se pueda extraer.
Por qué importa
Los datos estructurados son la vía documentada para optar a resultados enriquecidos en la SERP y para describir tus entidades con precisión. Eso afecta a cómo aparece tu sitio en el buscador y a la coherencia con que se entiende tu marca. El prerrequisito sigue siendo el de siempre: estar correctamente cubierto por el Rastreo e indexación, porque sin indexación no hay rich result que valga.
Conviene ser honesto sobre el límite. Google confirma que los datos estructurados no son obligatorios para la búsqueda con IA generativa, aunque recomienda mantener el marcado por su valor en rich results. Su efecto en que un LLM cite tu sitio está en discusión. La explicación técnica es que un chatbot suele recibir texto plano, y el Schema solo es visible vía SERP indexada, agentes que renderizan el DOM o entrenamiento. El impacto en IA generativa no está demostrado.
Hay además un riesgo de calidad. Buena parte del marcado autogenerado por un LLM resulta inválido. Nadie puede garantizar posiciones ni citas por marcar Schema. Lo que sí se puede es construir un marcado correcto, válido y extraíble, y medir su elegibilidad a rich results. La citabilidad por IA —que un sistema generativo te recoja como fuente— se persigue en GEO · Generative Engine Optimization y en AI Overviews y AI Mode, no aquí; y si quieres saber si funciona, la Medición de la visibilidad en IA es la palanca, no el Schema.
En profundidad
El grafo on-page: @id, @graph y aristas explícitas
La coherencia de entidad no se infiere sola: se construye. Con @id das a cada nodo un identificador interno estable; cuando el mismo @id se repite entre bloques, declaras que son la misma entidad y evitas duplicados dentro del sitio —un objetivo emparentado con la Canonicalización y duplicados, que persigue lo mismo a nivel de URL. El contenedor @graph reúne varias entidades enlazadas en un solo bloque JSON-LD y deja las relaciones por escrito: WebPage isPartOf WebSite, WebSite publisher Organization, Article mainEntityOfPage WebPage, Person worksFor Organization. En lugar de dejar las conexiones a la inferencia del NLP, las instrumentas como aristas; es la versión on-page de lo que Entidades y grafos de conocimiento hace a escala de web.
Límite operativo que conviene tener presente: Google procesa los datos estructurados página por página y no fusiona los @id automáticamente entre páginas. Cada página debe llevar su entidad completa; el patrón @id + url sirve para referenciar entidades entre páginas, no para que el motor las una por ti. Construye el grafo a propósito y verifícalo.
| Arista (relación) | Sujeto → Objeto | Qué declara |
|---|---|---|
| isPartOf | WebPage → WebSite | La página pertenece al sitio |
| publisher | WebSite → Organization | Quién publica el sitio |
| mainEntityOfPage | Article → WebPage | Esta página es la canónica del artículo |
| worksFor | Person → Organization | Vínculo persona-entidad |
| @id (repetido) | Nodo ↔ mismo nodo | Misma entidad dentro del @graph |
Desambiguación: enlazar tu entidad al Knowledge Graph
sameAs apunta hacia fuera: conecta tu entidad con URIs externas autoritativas para que el buscador resuelva homónimos y consolide la identidad. No lo confundas con @id, que es referencia interna. El objetivo más potente es Wikidata, por ser input directo del Knowledge Graph de Google; LinkedIn, Crunchbase o registros oficiales funcionan como verificación secundaria. La lógica es de convergencia: cuantas más fuentes coincidan en los mismos datos, mayor confianza de entidad. Esa convergencia de señales externas conversa con E-E-A-T, donde la consistencia de identidad y la procedencia verificable también pesan.
Aquí toca criterio. Las cifras concretas de "entity score" que circulan salen de vendors, no de Google, y los casos de mejora publicados son estudios de proveedor. Útiles como hipótesis de trabajo, no como ley. Lo verificable es la mecánica: declara sameAs hacia fuentes que de verdad describan tu entidad, mantenlas vivas y deja que la coincidencia haga su trabajo.
Validez no es calidad: guías de Google y acciones manuales
Pasar el Rich Results Test confirma la sintaxis, no que cumplas las políticas. Las guías de calidad de Google exigen que el marcado no cubra contenido invisible para el usuario, que sea una representación fiel del contenido de la página, que completes las propiedades recomendadas y que no engañe ni suplante. Saturar la página de Schema.org ("schema stuffing") va en dirección contraria: más marcado no es mejor marcado. El criterio de oficio es marcar lo que responde a un objetivo y mantenerlo.
El peor caso es una acción manual por marcado de spam. Según Google, hace perder la elegibilidad como rich result, pero no afecta a cómo posiciona la página en la búsqueda web. Se revisa en el informe de Acciones Manuales de Search Console y se revierte corrigiendo las violaciones y enviando una solicitud de reconsideración. Conviene dimensionar bien el riesgo: el daño típico del marcado inválido o abusivo es quedarte sin rich snippets, no caer en posiciones —un patrón distinto al de una penalización por contenido, más cercano al criterio que exige cualquier intervención bajo riesgo de las Actualizaciones del algoritmo (core updates).
Búsqueda con IA: separar el valor real del humo
Aquí toca honestidad. Google es explícito: los datos estructurados no son necesarios para sus funciones de IA generativa, y no hay un schema especial que añadir. La forma en que Search encuentra y procesa tus páginas sigue siendo el núcleo de cómo sus sistemas de IA acceden a tus datos. El prerrequisito es estar indexado y ser apto para mostrarse con un fragmento, cumpliendo los requisitos técnicos de Search; el structured data viene después. Lo que de verdad mueve la aguja en respuestas generativas es la Citabilidad en respuestas de IA, que depende del contenido extraíble, no del marcado.
Hay señales de la industria que apuntan a un efecto muy limitado del JSON-LD sobre las citas en respuestas de IA. Las tratamos como señal, no como prueba cerrada: el estudio que circula lo conocemos por una newsletter, no por su informe original. La lectura útil es esta: el valor sólido de los datos estructurados está en el SEO tradicional —rich results, desambiguación, Knowledge Graph—; venderlos como palanca directa de GEO · Generative Engine Optimization es donde empieza el humo. Construye el grafo por sus beneficios reales y mide. No por una promesa de citación que nadie ha confirmado.
No. Google es explícito: los datos estructurados no son necesarios para sus funciones de IA generativa y no hay un schema especial que añadir fuente. El núcleo sigue siendo cómo Search encuentra y procesa tus páginas: el prerrequisito es estar indexado y ser apto para fragmento, cumpliendo los requisitos técnicos. El valor sólido del JSON-LD está en el SEO tradicional —rich results, desambiguación, Knowledge Graph—; venderlo como palanca directa de citación en IA es donde empieza el humo. Señales de la industria apuntan a un efecto muy limitado sobre las citas, pero las tratamos como señal, no como prueba cerrada fuente.
En vídeo y audio
Qué observar
Las señales que importan.
Tipo y cobertura
Los tipos de Schema.org deben encajar con el contenido real de la página. El marcado de relleno, sin correspondencia con lo publicado, no aporta y puede penalizar.
Validez técnica
El marcado válido pasa el Rich Results Test y el Schema Markup Validator. Las propiedades inventadas o fuera de especificación invalidan el bloque.
Extraíble en el HTML
El JSON-LD servido en el HTML inicial es legible por cualquier agente. Si depende solo de JavaScript que no se ejecuta, el marcado queda invisible.
Coherencia de entidad
Organization y sameAs describen una entidad única. Su descripción debe ser consistente en todo el sitio para que la entidad se consolide.
Elegibilidad a rich snippets
El resultado enriquecido solo aparece si el marcado cumple los requisitos específicos de Google para ese tipo de snippet.
Conceptos clave
El vocabulario del término.
- @id
- Identificador interno estable de un nodo del grafo JSON-LD: reutilizarlo entre bloques declara que se trata de la misma entidad (deduplicación interna), a diferencia de sameAs, que apunta a fuentes externas.
- @graph
- Contenedor de JSON-LD que reúne varias entidades interrelacionadas en un solo bloque y, combinado con referencias @id, las conecta en un grafo coherente on-page.
- sameAs
- Propiedad de Schema.org (definida en el tipo base Thing, por lo que aplica a cualquier entidad) que enlaza tu entidad con URLs externas autoritativas (Wikidata, LinkedIn, registros oficiales) para desambiguarla y consolidarla en el Knowledge Graph.
- Desambiguación de entidad
- Proceso por el que el buscador determina a qué entidad real se refiere una página y resuelve homónimos; los datos estructurados, vía sameAs hacia URIs autoritativas, lo aceleran.
- isPartOf / publisher / mainEntityOfPage
- Propiedades que hacen explícitas las aristas del grafo on-page (WebPage isPartOf WebSite, WebSite publisher Organization, Article mainEntityOfPage WebPage) en lugar de dejarlas a la inferencia del NLP.
- Guías de calidad de structured data
- Políticas de Google que van más allá de la sintaxis: el marcado debe describir contenido visible y ser una representación fiel de la página, incluir las propiedades recomendadas y no engañar ni suplantar; validar la sintaxis no garantiza cumplirlas.
- Spammy Structured Markup (acción manual)
- Sanción manual de Google por marcado engañoso o sobre contenido invisible que hace perder la elegibilidad como rich result pero no afecta al ranking en la búsqueda web; se revierte corrigiendo las violaciones y pidiendo reconsideración en Search Console.
- Schema stuffing
- Anti-patrón de saturar una página con marcado excesivo de Schema.org; el criterio es marcar solo lo que responde a un objetivo y mantenerlo, porque más schema no implica mejor resultado.
Aún no mostramos casos.
No inventamos resultados. Cuando tengamos casos reales —anonimizados y medibles— donde este concepto marcó la diferencia, vivirán aquí.
Fuentes
- Guía de Google sobre la optimización para las funciones de IA generativa de la Búsqueda · 2026-05-22
- Agentes web y la importancia del HTML semántico y accesible - Natzir Turrado · 2025-11-13
- SEO en LLMs: Mitos y Realidades - Carlos Ortega y Javier Martínez · 2025-09-25
- General Structured Data Guidelines | Google Search Central
- Intro to How Structured Data Markup Works | Google Search Central
- Using @id in Schema.org Markup for SEO, LLMs, & Knowledge Graphs | Momentic
Una pieza del glosario.
Forma parte del glosario de SEO, analítica e IA de InnovaOrigen Tech: un mapa de conceptos definidos con criterio y fuentes. Si quieres llevarlo a tu caso, lo vemos sin compromiso.