Los datos estructurados describen de forma estandarizada qué representa una página: un artículo, una organización, una ruta de navegación o un producto, por ejemplo. Schema.org aporta el vocabulario y JSON-LD es uno de los formatos para expresarlo. Su utilidad es hacer explícitas algunas relaciones; no sustituye el contenido ni concede posiciones o citaciones por sí solo.
Google explica que su buscador puede utilizar el marcado para comprender información y, en ciertos tipos admitidos, habilitar resultados enriquecidos. También aclara que AI Overviews y AI Mode no exigen ningún marcado Schema especial para aparecer en esas funciones. Por eso, en HatumGEO separamos beneficios documentados de expectativas que todavía no podemos demostrar. Fuentes: introducción oficial a los datos estructurados y funciones de IA en Google.
Schema.org, JSON-LD y resultados enriquecidos: tres conceptos distintos
Schema.org es un vocabulario común para describir objetos y relaciones. Un tipo Organization representa una organización; Article describe un artículo. JSON-LD es un formato legible por máquinas que expresa esos datos dentro del documento. Un resultado enriquecido es una presentación de búsqueda que Google puede mostrar cuando se cumplen sus requisitos, pero ni todo tipo de Schema habilita uno ni estar correctamente marcado garantiza que aparezca.
| Concepto | Qué es | Error frecuente |
|---|---|---|
| Schema.org | Vocabulario de tipos y propiedades | Creer que cada tipo produce un rich result |
| JSON-LD | Formato de implementación de información estructurada | Confundir código válido con información verdadera |
| Resultado enriquecido | Presentación elegible en ciertas funciones de búsqueda | Suponer que la prueba de validación garantiza su visualización |
| Marcado para IA | Datos que pueden aportar contexto a distintos sistemas | Vender un Schema «secreto» para aparecer en ChatGPT |
Cuando documentamos una oportunidad primero comprobamos el contenido visible. Después elegimos un tipo adecuado, revisamos propiedades y validamos el código. No empezamos inventando datos para completar una plantilla.
Ejemplo sencillo de Article con autor y editor
Consideremos una guía ficticia publicada por una empresa de ejemplo. El bloque siguiente es demostrativo, no una recomendación para copiarlo literalmente en una web real.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Cómo organizar un inventario",
"datePublished": "2026-01-15",
"author": {
"@type": "Person",
"name": "Persona de ejemplo"
},
"publisher": {
"@type": "Organization",
"name": "Empresa de ejemplo",
"url": "https://example.com/"
}
}En una implementación auténtica, headline debe corresponder al artículo, la fecha debe ser real y la autoría debe identificar a quien corresponda. Si no existe información verificable del profesional, no debemos inventarla. El ejemplo tampoco incluye un @id definitivo, imagen, URL de artículo ni otras propiedades que podrían ser pertinentes según el caso; esas decisiones se adoptan revisando la documentación específica.
En sitios WordPress, un plugin SEO suele generar parte del marcado. Antes de añadir otro bloque manual debemos inspeccionar el HTML renderizado para evitar entidades inconsistentes o declaraciones duplicadas. Puedes relacionar este tema con nuestra guía de entidades y Knowledge Graph.
Qué tipo de marcado corresponde a cada intención de página
Página corporativa: identidad y relaciones verificables
Para una organización puede resultar apropiado Organization con nombre, URL y datos oficiales disponibles. En un negocio local hay que revisar las posibilidades de marcado pertinentes sin declarar locales, horarios o direcciones que no existen. Para una persona autora, el contenido debe mostrar quién escribe y qué trayectoria puede comprobarse.
El propósito de estas propiedades es representar información real. Un nombre de marca idéntico en el contenido y en el JSON-LD es una comprobación de coherencia, no una medición de cuántas veces una IA la recomienda.
Artículos: contexto editorial y procedencia
En una guía informativa, Article o BlogPosting puede describir titular, autor, fecha de publicación y edición, cuando corresponda. Un tema sensible exige además cuidado editorial en las afirmaciones y revisión por profesionales competentes; añadir author no reemplaza esa comprobación.
Es posible que el CMS genere BlogPosting y BreadcrumbList automáticamente. Evaluamos si el contenido y los enlaces de navegación coinciden con lo declarado, en lugar de sumar bloques redundantes para aumentar la cantidad de Schema.
Páginas comerciales: productos y ofertas reales
En una ficha eCommerce, Product puede describir un artículo concreto y Offer puede incluir precio o disponibilidad si son reales, visibles y cumplen la documentación del tipo. En una página general de servicios no transformamos una explicación en Product solo para conseguir una propiedad adicional.
Las directrices cambian con el tiempo. Debemos consultar la galería y documentación vigente de Google para datos estructurados en lugar de publicar una lista de tipos supuestamente permanentes.
Cómo validar Schema sin confundir sintaxis con fiabilidad
- Identificamos el objeto principal de la página: artículo, organización, producto o función de navegación.
- Leemos el contenido visible y anotamos únicamente los datos que podemos verificar.
- Revisamos qué código ya inserta WordPress, el tema y el plugin SEO. Dos emisores de marcado pueden referirse a la misma entidad de formas incompatibles.
- Comprobamos que el JSON-LD pueda interpretarse y que los identificadores sean coherentes.
- Utilizamos Rich Results Test para tipos elegibles de resultados enriquecidos; no esperamos que apruebe tipos para los que Google no presenta esa función.
- Para inspeccionar marcado más amplio podemos contrastar la estructura contra vocabularios y validadores especializados.
- Verificamos que el resultado final no incluya reseñas, precios, certificaciones, autores ni fechas falsos.
- Después de publicar observamos los informes correspondientes en Search Console, sin confundir detección con visualización garantizada.
La política oficial de datos estructurados establece que la elegibilidad no garantiza aparición de resultados enriquecidos.
Errores de marcado que debemos evitar
El error más obvio es copiar un bloque JSON-LD de otra empresa y olvidar cambiar sus atributos. El más costoso es declarar datos que contradicen la página: precios desactualizados, puntuaciones fabricadas o perfiles de otra entidad. También es problemático encadenar identificadores @id sin una política consistente entre home, artículos y fichas.
Otro error consiste en interpretar «el test muestra cero errores» como «Google reconocerá inmediatamente una empresa y ChatGPT la citará». Son hechos distintos. El test observa condiciones técnicas de marcado; los resultados dependen de otros sistemas y contextos.
Para usuarios no técnicos, una buena regla es esta: si no podemos explicar qué entidad real representa una propiedad, probablemente no deberíamos publicarla. Esta revisión conecta con E-E-A-T y confianza y con la auditoría de factores GEO.
Cómo relacionamos datos estructurados con los factores HatumGEO
El catálogo de HatumGEO incluye parseabilidad de JSON-LD, adecuación al rol de la página, calidad de propiedades, coherencia entre entidad estructurada y visible, autoría y referencias sameAs. Clasificamos estas verificaciones como oficiales, híbridas o heurísticas según su respaldo. No son una lista de factores oficiales de ranking de motores generativos.
En la práctica, el trabajo consiste en detectar contradicciones o ausencias pertinentes. La prioridad será corregir un Organization mal identificado, por ejemplo, antes de añadir nuevos tipos sin propósito editorial. Después medimos resultados en otras herramientas; la validez del marcado no mide por sí sola presencia de la marca en una respuesta.
Preguntas frecuentes
¿Existe un Schema especial para que una web aparezca en AI Overviews?
Google dice expresamente que no exige marcado Schema adicional para sus funciones de IA. Seguimos las buenas prácticas SEO y el marcado adecuado a cada página.
¿Necesito JSON-LD si utilizo WordPress y Rank Math?
Primero inspeccionamos el código que ya generan el CMS y sus complementos. No tiene sentido duplicarlo sin una necesidad concreta.
¿Más propiedades de Schema significan mejor GEO?
No. Una implementación pequeña, precisa y coherente es preferible a una colección extensa de atributos sin respaldo.
Fuentes y conclusión
- Google: introducción a datos estructurados.
- Google: políticas de datos estructurados.
- Google: funciones de IA y SEO.
- Schema.org: especificación.
Conclusión: usamos Schema para describir contenido real de forma coherente; empleamos la evidencia y las mediciones para evaluar su utilidad. No confundimos datos estructurados, resultados enriquecidos y citas de IA.
