Verificación de datos estructurados

Una segunda copia de la página, escrita para máquinas

Enseña una página de producto a una persona y sabrá al instante cuál número es el precio y cuál las existencias. Un programa solo ve texto. Los datos estructurados le ahorran las suposiciones. Junto a la página visible, publicas los mismos datos como campos con etiqueta, usando nombres del vocabulario compartido de schema.org. Esto es un Product, su name es este, sus offers contienen un price de 49.00 en USD.

Hay tres maneras de escribirlo. JSON-LD pone todo en una sola etiqueta script, separada del diseño, y es la forma que recomienda Google. Microdata y RDFa reparten las etiquetas por las etiquetas HTML como atributos.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How tides work",
  "datePublished": "2026-03-14T09:30:00+00:00",
  "author": { "@type": "Person", "name": "Jane Doe" }
}
</script>

Los buscadores usan estos campos para dibujar resultados más ricos, con estrellas de valoración, un precio, la foto de una receta o la fecha de un evento. Se llaman resultados enriquecidos.

Qué lee esta verificación

Nuestro servidor descarga la página una vez, hasta 3 MB, y no ejecuta sus scripts. Después trabaja en cuatro pasos.

1. Sintaxis. Cada bloque JSON-LD pasa por un lector JSON estricto. En el primer fallo da la línea, el carácter y la causa probable: una coma antes de una llave de cierre, unas comillas dentro de un texto sin escapar, comillas tipográficas pegadas desde un procesador de texto, un comentario HTML, un salto de línea sin escapar. Un solo fallo basta para que el analizador descarte el bloque entero.
2. Elementos. Las listas @graph se abren para que cada elemento se muestre por separado, con su tipo y un resumen de sus propiedades. Una propiedad que apunta a otro elemento con @id se sigue cuando el destino está en la página.
3. Propiedades. En los tipos que alimentan un resultado enriquecido, el elemento se compara con una lista de propiedades obligatorias y recomendadas tomada de la documentación de Google.
4. Valores. En cada elemento, las direcciones deben ser absolutas, las fechas y duraciones deben seguir ISO 8601, @context debe ser schema.org y cada puntero @id debe llevar a alguna parte.

Los microdatos (itemscope, itemtype) y el RDFa (typeof) se cuentan y se nombran por tipo. Sus propiedades no se validan.

Los tipos que comparamos y lo que necesitan

Los demás tipos se resumen y se comprueban sus valores, sin una lista de propiedades obligatorias.

Cómo reparar lo que muestra el informe

Un fallo de sintaxis

Los bloques editados a mano se rompen con las comas y las comillas. Genera el bloque con un codificador JSON (json_encode en PHP, JSON.stringify en JavaScript) y toda esa familia de fallos desaparece. En un CMS, pega el JSON-LD en un campo de código. No uses nunca el editor visual para esto, porque convierte las comillas en tipográficas.

Falta una propiedad obligatoria

Añádela, con el valor que un visitante puede ver en la página. Los buscadores comparan ambos, y un marcado que describe algo que la página no muestra puede acarrearte una acción manual.

Una dirección relativa

Escribe https://www.example.com/img/cover.jpg completa, no /img/cover.jpg.

Una fecha que no es ISO 8601

Primero el año, luego T, luego la hora y el desfase respecto a UTC: 2026-03-14T09:30:00+00:00. Un día solo, 2026-03-14, también es válido.

Un puntero a ninguna parte

"author": {"@id": "…/#jane"} solo funciona si hay un elemento con ese @id exacto en la misma página. Añade el elemento o escribe el autor directamente.

Lo que esta verificación no puede decirte

Lee el HTML tal como se entrega. Los datos estructurados añadidos después con JavaScript o con un gestor de etiquetas son invisibles aquí, aunque Google puede verlos tras renderizar. Las imágenes no se descargan, así que una imagen rota o demasiado pequeña pasa inadvertida. Las listas de propiedades cubren los tipos de resultado más comunes. No cubren todos los tipos ni todos los campos opcionales.