Los datos estructurados describen el contenido de una página en un vocabulario normalizado que los buscadores saben leer. Bien implementados, abren el acceso a los resultados enriquecidos —estrellas de valoración, ruta de navegación, preguntas desplegables— sin cambiar nada de lo que ve el visitante. Esta guía detalla el formato JSON-LD, los tipos de Schema.org realmente útiles y cómo desplegarlos y controlarlos.
Qué son los datos estructurados
Un dato estructurado es un marcado que anota el contenido de una página para explicitar su sentido: «esto es un artículo», «su autor es fulano», «se publicó en tal fecha». El vocabulario de referencia es Schema.org, mantenido por un consorcio formado por Google, Microsoft, Yahoo y Yandex. Este marcado no modifica la presentación: se dirige a las máquinas, no al lector.
Lo que está en juego es la visibilidad. Los buscadores se apoyan en estas anotaciones para generar resultados enriquecidos, más grandes y con más clics. No son un factor de posicionamiento directo, pero la ganancia de superficie y de tasa de clics es medible —un efecto que conviene seguir en los informes de Search Console—.
JSON-LD, Microdata, RDFa: cuál elegir
Tres sintaxis coexisten para expresar el mismo vocabulario. JSON-LD se ha impuesto porque separa el marcado del HTML: un bloque de script autónomo, más sencillo de generar, inyectar y mantener.
| Formato | Dónde vive | Mantenimiento | Recomendación |
|---|---|---|---|
| JSON-LD | Un bloque <script> autónomo | Sencillo, desacoplado del HTML | Formato recomendado por Google |
| Microdata | Atributos en el HTML visible | Acoplado al marcado, verboso | Heredado, a migrar |
| RDFa | Atributos en el HTML | Potente pero complejo | Casos específicos |
Los tipos de Schema.org que importan
El vocabulario tiene cientos de tipos, pero un puñado cubre lo esencial de un sitio profesional.
| Tipo | Uso | Resultado enriquecido posible |
|---|---|---|
Article / NewsArticle | Contenido editorial | Miniatura grande, fecha, autor |
Product + Offer | Ficha de producto | Precio, disponibilidad, valoraciones |
FAQPage | Preguntas y respuestas | Acordeón desplegado bajo el enlace |
BreadcrumbList | Ruta de navegación | Camino de navegación mostrado |
Organization / LocalBusiness | Identidad, datos de contacto | Panel de conocimiento, horarios |
Dos principios guían la elección: marcar solo lo que es visible en la página y priorizar los tipos que realmente activan una presentación enriquecida para la actividad en cuestión.
Escribir un bloque JSON-LD correcto
Un bloque JSON-LD se coloca en el <head> o en el <body>, dentro de una etiqueta script con un tipo dedicado. Este es un ejemplo completo para un artículo:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Structured data with JSON-LD",
"datePublished": "2026-09-08",
"dateModified": "2026-09-08",
"author": { "@type": "Person", "name": "Simon Janvier" },
"publisher": {
"@type": "Organization",
"name": "Mail Studio",
"logo": { "@type": "ImageObject", "url": "https://www.mail-studio.com/logo.png" }
},
"image": "https://www.mail-studio.com/cover.jpg"
}El bloque se declara después en la página, solo en su etiqueta:
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Article", "headline": "..." }
</script>Algunas reglas evitan la mayoría de los errores: fechas en formato ISO 8601, URL absolutas y una coherencia estricta entre los valores marcados y el contenido mostrado.
Los datos estructurados no cambian nada de lo que ve el lector; cambian cómo aparece la página en los resultados de búsqueda.
Generar e inyectar el marcado sin repetirse
Pocos sitios escriben su JSON-LD a mano, página por página. Tres enfoques conviven según la stack:
- Generación en el servidor: la plantilla produce el bloque a partir de los datos de la página (título, fecha, autor). Es el enfoque más fiable, porque la fuente de verdad es única.
- Extensión de CMS: en WordPress, los complementos SEO colocan automáticamente
Article,BreadcrumbListyOrganization. Cómodo, pero conviene auditarlo: los ajustes por defecto marcan a veces tipos inútiles. - Gestor de etiquetas: inyectar el JSON-LD mediante un gestor de etiquetas es posible, pero depende del renderizado de JavaScript por el motor —menos robusto que un renderizado en servidor—.
Sea cual sea el método, prima un principio: una sola fuente de verdad. Un datePublished que contradice la fecha mostrada es una señal negativa, no un detalle.
Los errores que hacen fracasar un marcado
La mayoría de los datos estructurados que los motores ignoran lo son por razones repetitivas, fáciles de corregir una vez identificadas. Conocerlas ahorra un tiempo real en el despliegue.
- Propiedades obligatorias que faltan. Cada tipo impone propiedades obligatorias: un
Productsinnamenioffersválidos no abrirá ningún resultado enriquecido. La prueba de resultados enriquecidos indica con precisión lo que falta. - Valores que contradicen la página. Un precio marcado distinto del mostrado, una nota media sin valoraciones visibles: señales que activan una acción manual en lugar de una ventaja de visibilidad.
- Varios bloques en competencia. Un tema, un complemento SEO y un gestor de etiquetas que colocan cada uno su
Organizationproducen duplicados contradictorios. Una sola fuente debe generar cada tipo. - Entidades no enlazadas. Enlazar los objetos con
@idevita redeclarar la organización o el autor de una página a otra y ayuda a los motores a consolidar el grafo del sitio. - Imágenes no conformes. Varios tipos recomiendan imágenes de alta resolución y en proporciones concretas; una URL de imagen ausente o demasiado pequeña priva al artículo de su miniatura grande.
- Contenido cargado con JavaScript. Si los datos marcados solo existen tras ejecutar un script, el rastreador debe poder verlos al renderizar; de lo contrario, el marcado describe una página que no percibe.
Un mismo documento puede combinar tipos legítimamente: un artículo que responde a preguntas frecuentes lleva a la vez Article y FAQPage. La anidación está permitida, siempre que cada tipo añadido corresponda a un contenido realmente presente, so pena de diluir la señal. Ninguno de estos errores es fatal: todos se detectan antes de publicar, en cuanto la prueba se convierte en un paso sistemático del despliegue.
Desplegar, probar y supervisar
Antes de publicar, la prueba de resultados enriquecidos de Google valida la sintaxis y señala las propiedades que faltan. Ya en producción, el informe «Mejoras» de Search Console sigue la indexación del marcado, los avisos y los errores por tipo.
La supervisión se une entonces al pilotaje global del sitio: los resultados enriquecidos se leen en los mismos paneles que el tráfico y los Core Web Vitals, junto a los cuales forman la base técnica del SEO.
Punto de vigilancia. Marcar contenido ausente de la página, inflar valoraciones o declarar una FAQ invisible expone a una acción manual por «spam de datos estructurados». El marcado debe reflejar siempre fielmente lo que es realmente visible.
Lo que hay que recordar
- Los datos estructurados anotan el contenido para los motores; abren los resultados enriquecidos sin modificar la presentación.
- JSON-LD es el formato recomendado: desacoplado del HTML, sencillo de generar y mantener.
- Centrarse en unos pocos tipos útiles (Article, Product, FAQPage, BreadcrumbList, Organization) y marcar solo lo visible.
- Validar con la prueba de resultados enriquecidos y luego supervisar el informe «Mejoras» de Search Console.
En mis propios sitios de medios, el marcado Article y BreadcrumbList hizo más por la visibilidad que muchas optimizaciones más vistosas. Mi consejo: empezar poco a poco, con un solo tipo limpio y probado, en lugar de una acumulación de esquemas aproximados que Google acabará ignorando. La regularidad vence a la exhaustividad. — Simon Janvier
Fuente primaria: la documentación de Google sobre datos estructurados y el vocabulario de referencia de Schema.org.
