Datos estructurados: qué son, ejemplos JSON-LD y errores comunes

Los datos estructurados son bloques de código estandarizado (normalmente JSON-LD con el vocabulario de Schema.org) que describen de forma explícita qué contiene una página: un producto con su precio, un negocio con su horario, un artículo con su autor. Google los usa para entender mejor el contenido y, si la página cumple sus requisitos, puede mostrarla como resultado enriquecido con estrellas, precios o imágenes. Esta guía práctica explica qué son, cómo se escriben con ejemplos de código listos para adaptar, qué errores aparecen en Search Console y cómo implementarlos tanto en un sitio pequeño como en uno con miles de páginas.

Qué son los datos estructurados

Los datos estructurados son fragmentos de código estandarizado que se añaden al HTML de una página web para clasificar su contenido de forma explícita. Sirven para que los motores de búsqueda entiendan el contexto exacto de la información, diferenciándose del texto visible normal porque los algoritmos los leen directamente sin ningún tipo de ambigüedad.

El origen de este sistema es la necesidad de un vocabulario común. Antes, un buscador tenía que adivinar si una cadena de números era un teléfono, un precio o un código postal. Para resolverlo, Google, Microsoft, Yahoo y Yandex lanzaron en 2011 el proyecto Schema.org, un vocabulario compartido de tipos (Product, Article, LocalBusiness…) y propiedades (name, price, openingHours…).

Conviene distinguir tres conceptos que a menudo se confunden:

El siguiente gráfico resume las profundas diferencias entre los métodos de estructuración semántica más populares y su viabilidad actual.

Concepto técnico	Diferencia funcional principal	Ejemplo de uso práctico y sintaxis
Schema.org (Vocabulario)	Es el diccionario central que define propiedades universales.	Declarar oficialmente que la entidad "Product" siempre debe tener un campo "price" asociado.
JSON-LD (El formato de entrega)	Es un bloque de texto independiente escondido en el código fuente.	El uso de etiquetas <script type="application/ld+json"> alejadas del contenido visible.
Microdata (El formato heredado)	Son etiquetas HTML entrelazadas de manera compleja con el diseño.	Usar atributos invasivos como <div itemprop="name">Zapatos de cuero</div>.

Ejemplo ilustrativo: si tu web fuera un libro entregado a una biblioteca, el texto completo sería el contenido visible y los datos estructurados serían la ficha bibliográfica (autor, género, año) que el bibliotecario lee en segundos para catalogarlo sin leer cada página.

El propósito fundamental de los datos estructurados

El propósito de los datos estructurados es traducir el lenguaje humano, lleno de matices, a un formato estricto que las máquinas procesan sin ambigüedad. Benefician a dos partes: a los buscadores, que clasifican el contenido con más seguridad, y a los propietarios de sitios, que pueden optar a formatos de resultado más visibles.

Dentro del SEO, esta capa llega después de la base técnica: un sitio rastreable (revisa tu archivo robots.txt), con sitemap limpio y buena experiencia de página (las Core Web Vitals miden carga, interactividad y estabilidad visual). Lo que viene después es la fase de presentación, en la que Google decide si muestra o no un resultado enriquecido.

El siguiente gráfico ilustra cómo fluye la información desde el código fuente hasta la pantalla del usuario final.

Si ignoras esta capa, pierdes la opción a resultados enriquecidos: mientras otros resultados muestran precio, disponibilidad o valoraciones, el tuyo queda como un enlace de texto simple, lo que suele restar clics. Además, das a los sistemas automáticos menos señales claras sobre quién es el autor, qué vendes o dónde está tu negocio.

Cuándo no necesitas datos estructurados: en un blog personal sin intención comercial, en páginas internas o en textos legales como la política de privacidad, el marcado aporta poco. Google no muestra resultados enriquecidos para ese tipo de páginas, así que el tiempo rinde más mejorando el contenido o la velocidad.

Valor comercial y beneficios operativos

La adopción de datos estructurados se justifica en dos capas: el valor para el negocio (más clics cualificados y menos errores de interpretación) y los beneficios operativos para los equipos de contenido y desarrollo. La métrica principal es el CTR (porcentaje de clics): clics divididos entre impresiones, por 100. Por ejemplo, 450 clics sobre 1500 impresiones equivalen a un CTR del 30%.

Mejora drástica de la visibilidad y el porcentaje de clics

El beneficio más visible es que tu resultado puede ocupar más espacio y dar más información: valoraciones, tiempo de preparación de una receta o disponibilidad de stock. El usuario confirma antes de hacer clic que la página tiene lo que busca, lo que atrae tráfico más cualificado.

Ejemplo ilustrativo: una pequeña importadora de herramientas con cinco empleados marcó con el tipo Product sus treinta productos más vendidos. Al principio, los precios aparecían sin impuestos y generaban quejas; lo corrigieron ajustando las propiedades price y priceCurrency del bloque Offer para que coincidieran con el precio visible. Desde entonces, sus resultados pueden mostrar precio y disponibilidad junto al enlace, sin aumentar el presupuesto publicitario.

Medición precisa del retorno de inversión en Search Console

Toda inversión técnica debe poder medirse. En el informe de Rendimiento de Search Console, el filtro «Aspecto en búsqueda» separa las impresiones y clics de cada tipo de resultado enriquecido. Si cruzas esos datos con tu analítica web, sabrás qué secciones del sitio generan más negocio.

Ejemplo ilustrativo: el blog de una empresa de software con un equipo de ocho personas añadió marcado Article y BreadcrumbList a sus manuales técnicos. Su herramienta de analítica no distinguía los clics de resultados enriquecidos de los demás, así que el equipo usó el filtro «Aspecto en búsqueda» de Search Console y comparó el CTR de las páginas marcadas con el de las no marcadas durante el mismo trimestre. Con ese informe pudo justificar ante la dirección que el trabajo técnico merecía continuar.

Claridad estructural para el equipo de desarrollo y contenido

En el día a día, un vocabulario estricto obliga a redactores, diseñadores y programadores a acordar qué datos son obligatorios antes de publicar: fecha, autor, precio, ubicación.

Ejemplo ilustrativo: una agencia de turismo de aventura con 18 empleados publicaba sus salidas con formatos distintos según cada redactor. Al adoptar el tipo Event, definieron campos obligatorios (startDate, location, offers). Los redactores se resistían a rellenar hojas de cálculo, así que el responsable técnico añadió un formulario en su gestor de contenidos que genera el código automáticamente. Resultado: menos errores de fechas y menos quejas por información desactualizada.

Beneficio para el negocio	Métrica para medirlo	Cuándo empezar a revisarla
Más espacio y detalle en la página de resultados	CTR de las páginas marcadas frente a las no marcadas	Cuando Google haya rastreado de nuevo las páginas
Saber qué formato rinde mejor	Filtro «Aspecto en búsqueda» del informe de Rendimiento	Tras acumular varias semanas de datos comparables
Menos errores técnicos	Avisos y errores en los informes de mejoras de Search Console	Después de cada despliegue de cambios

Descubre Orova.vn – una plataforma Biz AI Agent con la solución OROVA SEO completa, destinada a todos los sitios web. El sistema acompaña la optimización para motores de búsqueda de A a Z con las siguientes funciones: investigación de palabras clave, redacción de nuevos artículos optimizados para SEO, optimización de los contenidos existentes, seguimiento de posiciones, además del análisis de la competencia y el análisis técnico en profundidad. Regístrate hoy mismo para descubrir OROVA SEO de forma totalmente gratuita (oferta válida hasta el 7 de julio de 2027).

Cómo funcionan los datos estructurados y su impacto en SEO

Los datos estructurados funcionan como una ficha técnica que acompaña a la página: en lugar de obligar al buscador a deducir el contenido a partir de los párrafos, le entregan los datos clave en un formato fijo. El proceso tiene tres fases: generación del código, validación por el rastreador y presentación en resultados.

El siguiente esquema ayuda a decidir qué tipo de marcado conviene según el contenido principal de la página.

Entradas de datos y generación de código

Todo empieza con la sintaxis. La documentación de Google Search Central recomienda JSON-LD (JavaScript Object Notation for Linked Data) porque el bloque va separado del HTML visible: puede ir en el <head> o en el <body> sin tocar el diseño.

Cada bloque se abre con <script type="application/ld+json"> y contiene pares propiedad-valor entre comillas dobles, separados por comas. Este es un ejemplo mínimo de marcado Article que puedes adaptar:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Cómo elegir botas de montaña para principiantes",
  "image": ["https://www.ejemplo.com/img/botas-montana.jpg"],
  "datePublished": "2026-10-01T08:00:00+02:00",
  "dateModified": "2026-10-05T09:30:00+02:00",
  "author": {
    "@type": "Person",
    "name": "Lucía Martín",
    "url": "https://www.ejemplo.com/autores/lucia-martin"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Tienda Ejemplo",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.ejemplo.com/img/logo.png"
    }
  }
}
</script>

La sintaxis es estricta: una coma de más o de menos, una llave sin cerrar o comillas simples invalidan el bloque entero.

Hay dos vías para generarlo. La manual: un generador en línea o una plantilla como la anterior, copiada en el gestor de contenidos; sirve para sitios pequeños. La programática: el servidor (en PHP, Python u otro lenguaje) toma título, precio o autor de la base de datos y genera el bloque para cada página, imprescindible cuando hay cientos o miles de URL.

Procesamiento y validación algorítmica por los rastreadores

Cuando el rastreador visita la página, extrae el bloque JSON-LD y lo interpreta por separado del texto. Después comprueba si cumple los requisitos de cada tipo: por ejemplo, para un resultado de evento Google exige al menos nombre, fecha de inicio (startDate) y ubicación (location).

Si faltan propiedades obligatorias o el formato es incorrecto (una fecha escrita como texto libre, por ejemplo), ese elemento no podrá optar al resultado enriquecido y Search Console lo marcará como no válido. Ten en cuenta que Google ha indicado que los datos estructurados no son un factor de posicionamiento directo: ayudan a entender la página y a optar a ciertos formatos, no a subir puestos por sí mismos.

Salida visual y generación de Rich Snippets

Si el marcado es válido y la página es relevante para la búsqueda, Google puede usar esos datos al construir el resultado. Es la fase de presentación.

Aquí el enlace simple puede convertirse en un resultado enriquecido (rich snippet): una imagen, el número de valoraciones, el precio y la disponibilidad o la ruta de navegación aparecen junto al título. Que aparezcan o no depende de Google; el marcado solo te habilita para competir por ese formato.

Errores comunes y depuración en Search Console

Search Console avisa de los problemas en los informes de mejoras (uno por cada tipo detectado: productos, rutas de navegación, eventos…). Revísalos con regularidad. Si necesitas una introducción a la herramienta, consulta esta guía de Google Search Console.

El siguiente cuadro destaca los puntos críticos obligatorios para mantener un ecosistema libre de errores fatales.

Estos son los errores más habituales y cómo corregirlos:

Error número uno: Falta el campo obligatorio 'price' (Precio). Aparece cuando se declara un Product pero no se anida correctamente la entidad Offer con el precio. La solución es incluir dentro de offers tanto price como priceCurrency (código ISO de la moneda, por ejemplo "EUR"), con el mismo precio que se ve en la página:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Botas de montaña impermeables",
  "image": "https://www.ejemplo.com/img/botas.jpg",
  "sku": "BM-0423",
  "offers": {
    "@type": "Offer",
    "price": "89.90",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://www.ejemplo.com/botas-montana"
  }
}

Error número dos: Tipo de valor no válido. Ocurre cuando una propiedad espera un formato concreto y recibe otro: por ejemplo, datePublished debe ir en formato ISO 8601 ("2026-10-01" o "2026-10-01T08:00:00+02:00") y no como "Publicado ayer". Corrige la plantilla o la variable del servidor que genera ese valor.

Error número tres: Datos estructurados que no se pueden analizar (Fallo de Parseo). Es el fallo más grave: el JSON tiene un error de sintaxis (una coma sobrante, una llave sin cerrar, comillas simples) y no se puede leer. Pasa el bloque por un validador antes de publicarlo.

Error número cuatro: Falta el campo recomendado 'author' (Autor). Habitual en blogs y medios: se usa Article sin indicar autor. Declara un objeto Person u Organization con su nombre (y, si puedes, la URL de su página de autor), como en el ejemplo de Article de arriba.

Error número cinco: Violación flagrante de las políticas de marcado. Ocurre cuando se marca contenido que el usuario no ve o que no corresponde a la página: valoraciones inventadas, reseñas escritas por el propio negocio o un artículo promocional marcado como receta. Google puede aplicar una acción manual que retira los resultados enriquecidos. La salida es eliminar el marcado engañoso, asegurarse de que cada dato marcado sea visible en la página y solicitar una reconsideración desde Search Console.

Intersección con la Inteligencia Artificial: Preparando el terreno para LLMs

Los buscadores incorporan cada vez más respuestas generadas por IA, como las AI Overviews de Google. Los modelos de lenguaje funcionan bien con texto, pero pueden equivocarse cuando la información es ambigua.

Los datos estructurados ayudan a reducir esa ambigüedad: afirman de forma explícita que X es el autor de Y, que Y se publicó en la fecha Z o que un producto cuesta un precio concreto. Google ha indicado que no hace falta un marcado especial para aparecer en sus funciones de IA, así que no es una garantía de ser citado; pero un sitio con entidades bien descritas y coherentes con el texto visible facilita que cualquier sistema automático lo entienda correctamente.

Tipo de Schema Estándar	Característica técnica principal	Ideal para qué modelo de negocio
Article / NewsArticle	Indica autor, fecha y titular	Blogs, editoriales y medios
Product & Review	Expone el precio actual, la disponibilidad en almacén y calificaciones	Tiendas online (E-commerce) con extensos catálogos dinámicos
LocalBusiness	Proporciona latitud, longitud, teléfono y horarios de apertura	Cadenas de restaurantes, consultorios médicos y tiendas físicas
FAQPage	Marca preguntas y respuestas; desde 2023 Google solo muestra este resultado enriquecido en sitios gubernamentales y de salud con autoridad	Útil para describir el contenido, pero no esperes el formato desplegable en un sitio comercial

Qué hacer para empezar a implementar datos estructurados

Para empezar con los datos estructurados, adapta el enfoque al tamaño de tu sitio y a tus recursos: no tiene sentido montar una integración corporativa para cinco páginas, ni mantener diez mil URL copiando bloques a mano.

El siguiente gráfico divide y ordena la carga de trabajo en función del esfuerzo requerido y el premio esperado.

Dueños de pequeños negocios locales (Enfoque manual y preciso)

Si tienes una tienda de barrio, un taller o una clínica dental, tu objetivo es que los buscadores sepan dónde estás, a qué hora abres y cómo contactarte. Céntrate en el tipo LocalBusiness (o uno más específico, como Dentist o AutoRepair).

1. Identifica y limpia meticulosamente tu información de NAP (Nombre corporativo, Dirección completa y Número de teléfono) para asegurar que sea idéntica en todos tus perfiles públicos en línea.
2. Crea tu bloque JSON-LD con un generador gratuito o adapta esta plantilla:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Clínica Dental Sonrisa",
  "image": "https://www.ejemplo.com/img/fachada.jpg",
  "telephone": "+34 910 000 000",
  "url": "https://www.ejemplo.com",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Calle Mayor 12",
    "addressLocality": "Madrid",
    "postalCode": "28013",
    "addressCountry": "ES"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "20:00"
    }
  ]
}
</script>

1. Inserta el bloque en la página principal o en la de contacto (muchos CMS tienen un campo o plugin para scripts) y comprueba que no rompe el diseño.

Responsables de marketing corporativo (Escalado y automatización)

En portales grandes, tiendas con miles de referencias o redes de sitios, la gestión manual no es viable. Necesitas que el marcado se genere desde la base de datos, sin retrasar la producción de tu calendario de contenidos.

1. Acuerda con el equipo de backend qué variables (precio, stock, autor, fechas) se exponen a las plantillas.
2. Genera el JSON-LD en la plantilla del servidor o, si no es posible, mediante Google Tag Manager leyendo esas variables desde la capa de datos (dataLayer).
3. Añade controles de calidad: valida una muestra de URL tras cada despliegue y revisa los informes de mejoras de Search Console.

Agencias SEO o consultores independientes (Auditoría y gobernanza)

Si gestionas sitios de clientes, tu papel es auditar y vigilar. Rara vez escribirás el código desde cero; dedicarás más tiempo a encontrar marcado antiguo y plantillas mal configuradas.

1. Rastrea el sitio con una herramienta de escritorio que extraiga datos estructurados para localizar conflictos y marcado obsoleto.
2. Prepara informes que conecten el marcado con métricas de negocio (clics, solicitudes, ventas).
3. Forma a los equipos editoriales del cliente para que no publiquen sin completar los campos obligatorios.

Error frecuente de implementación	Consecuencia directa e inevitable	Solución técnica recomendada a implementar
Marcar contenido oculto o que no está en la página	Acción manual por datos estructurados engañosos	Comprobar que cada dato del código sea visible en la página
Usar un tipo de Schema que no corresponde	Google ignora el marcado para resultados enriquecidos	Consultar la documentación del tipo antes de implementarlo
Dejar vacías propiedades obligatorias	Elementos no válidos en los informes de Search Console	Validar el código en un entorno de pruebas antes de publicarlo

Con OROVA.VN y el módulo OROVA SEO, pones fin definitivamente a las jornadas agotadoras de trabajo manual. En lugar de batallar durante horas para redactar artículos y elaborar informes, todo el proceso queda ahora optimizado y completado en tan solo 5 minutos.

Tendencias de datos estructurados en los próximos años: mi perspectiva

Las tendencias de los datos estructurados apuntan a un papel menos centrado en el adorno visual y más en describir entidades con claridad para buscadores y asistentes de IA. Estas son tres opiniones personales, no predicciones con fecha.

El diagrama resume cómo veo esa evolución.

La transición de la búsqueda visual a la respuesta conversacional

En mi opinión, los resultados enriquecidos clásicos seguirán existiendo, pero el valor del marcado se desplazará hacia otra función: ayudar a que los sistemas generativos identifiquen sin ambigüedad quién publica, qué ofrece y cuándo. Creo que los sitios con entidades bien descritas partirán con ventaja, aunque nadie puede garantizar cómo citará cada sistema sus fuentes.

La automatización total del marcado semántico

Creo que escribir JSON-LD a mano será cada vez menos habitual. Veo que muchos CMS y plugins ya generan el marcado básico, y me parece probable que integren asistentes que propongan el marcado a partir del borrador. Aun así, pienso que siempre hará falta una persona que revise que los datos coinciden con lo que se ve en la página.

Nuevos vocabularios específicos para el comercio descentralizado

Creo que el vocabulario de comercio seguirá creciendo: precio y disponibilidad estáticos se quedan cortos cuando los asistentes de compra comparan ofertas, envíos y devoluciones. En mi opinión, quien conecte bien su catálogo con el marcado (precios, stock, políticas de devolución y envío) estará mejor preparado para esos cambios.

Preguntas frecuentes sobre datos estructurados

Estas son las dudas más habituales sobre datos estructurados.

¿Los datos estructurados garantizan la aparición de fragmentos enriquecidos?

No. Un marcado correcto te habilita para optar a un resultado enriquecido, pero Google decide si lo muestra en cada búsqueda según la calidad de la página, la relevancia y el dispositivo.

¿Los datos estructurados siguen siendo necesarios cuando ya existe la IA?

Sí. Los sistemas de IA leen texto, pero los datos estructurados declaran explícitamente autor, fechas, precios o ubicación y reducen la ambigüedad. No garantizan que la IA te cite, pero ayudan a que tu información se interprete correctamente.

¿Cuántos tipos de Schema puedo usar en una sola página URL?

Puedes usar varios tipos en una misma página siempre que describan contenido visible en ella. Por ejemplo, un Product con su AggregateRating y una BreadcrumbList para la ruta de navegación. Lo que no debes hacer es mezclar tipos que no correspondan, como marcar un análisis como receta.

¿Cómo solucionar el problema de un tema web que genera código obsoleto?

Si tu plantilla genera Microdata antiguo que choca con tu nuevo JSON-LD, lo más seguro es trabajar sobre un tema hijo (child theme) y pedir a un desarrollador que desactive las funciones que imprimen ese marcado. Después implementa solo JSON-LD para evitar entidades duplicadas o contradictorias.

¿Cómo validar los datos antes de publicarlos en el sitio en vivo?

Usa la Prueba de resultados enriquecidos de Google para saber si tu página puede optar a esos formatos y el Validador de Schema.org para revisar la sintaxis general. Si aparecen errores, corrígelos antes de publicar; las advertencias indican propiedades recomendadas que conviene completar. Después, la herramienta de inspección de URLs de Search Console te muestra cómo ve Google la versión publicada.

¿Por dónde empezar?

Por dónde empezar depende del punto en que esté tu sitio hoy.

El siguiente proceso resume un camino ordenado para empezar sin poner en riesgo todo el dominio.

Si no tienes ningún marcado: elige las cinco páginas más importantes del sitio y añade a mano el tipo adecuado (Organization o LocalBusiness en la portada, Article en el blog, Product en las fichas clave). Valídalas, solicita la indexación con la herramienta de inspección de URLs y observa los informes durante unas semanas.

Si ya tienes marcado antiguo y desordenado: rastrea el sitio completo con una herramienta de escritorio, identifica dónde conviven Microdata y JSON-LD, y planifica la migración progresiva a un único sistema JSON-LD generado desde las plantillas.

Si ya tienes marcado limpio pero no mides su efecto: abre el informe de Rendimiento de Search Console, aplica el filtro «Aspecto en búsqueda» y compara trimestre a trimestre el CTR de las páginas con resultados enriquecidos frente a las demás. Así podrás demostrar con datos si los datos estructurados están aportando valor a tu sitio web.