Datos estructurados: qué hace el JSON-LD y qué no garantiza

Los datos estructurados son un bloque de código que describe la página en términos que el buscador entiende sin interpretar el texto: esto es un artículo, publicado en esta fecha, escrito por esta persona. El formato que recomienda Google es JSON-LD, porque es el más fácil de mantener (Centro de la Búsqueda de Google, introducción a los datos estructurados). El marcado hace que la página pueda optar a un resultado enriquecido, pero no garantiza que aparezca. Y solo vale cuando describe lo que la persona ve en pantalla.

Vocabulario y formato no son lo mismo

Hay dos piezas en juego. El vocabulario dice qué tipos y propiedades existen, como Article, Offer y datePublished. Casi todos los datos estructurados que usa la Búsqueda de Google vienen de schema.org (en inglés), un vocabulario creado por Google, Microsoft, Yahoo y Yandex y mantenido hoy por una comunidad abierta.

El formato dice cómo entra ese vocabulario en el HTML. Google acepta tres (Centro de la Búsqueda de Google):

JSON-LD, un bloque <script type="application/ld+json"> separado del texto visible. Es el recomendado.
Microdatos, atributos repartidos en las propias etiquetas del cuerpo.
RDFa, también con atributos, ligados al contenido visible.

Para Google, los tres valen lo mismo si el marcado es válido. La ventaja de JSON-LD es práctica: como no se mezcla con el texto, es más fácil anidar un elemento dentro de otro y más difícil romper el marcado al editar la página. Google también lee el JSON-LD cuando lo inserta JavaScript (Centro de la Búsqueda de Google).

Lo que puede aportar

La ganancia directa es el resultado enriquecido: un resultado de búsqueda con más información que el enlace azul, como una valoración, un precio, una ruta de navegación o una imagen más grande. La galería de funciones de la Búsqueda de Google muestra qué tipos tienen una presentación propia.

Google publica casos de sitios que añadieron el marcado. Rotten Tomatoes marcó 100.000 páginas y midió un porcentaje de clics un 25 % mayor en ellas que en las páginas sin marcado. Nestlé midió un porcentaje de clics un 82 % mayor en las páginas que aparecieron como resultado enriquecido (Centro de la Búsqueda de Google, introducción a los datos estructurados). Son cifras que las propias empresas le dieron a Google, sin el diseño de la prueba al lado. Sirven como señal de que vale la pena probar, no como previsión para otro sitio.

El NN/g, el Nielsen Norman Group, ayuda a entender el porqué, aunque no mide los datos estructurados en sí. Estudia los elementos especiales de la página de resultados, los que se salen del enlace azul de siempre. En un análisis de 471 búsquedas hechas entre 2017 y 2019, esos elementos recibieron miradas en el 74 % de los casos en que aparecieron (Kate Moran y Cami Goray, NN/g (en inglés)). La vista dejó de bajar por la lista en orden y empezó a saltar entre lo que destaca.

Moran y Goray señalan cuatro funciones para estos elementos (NN/g, tres elementos clave de la página de resultados (en inglés)). Hacen de señal de tráfico, porque la imagen confirma enseguida que el resultado trata de lo correcto. Atraen la atención, cambian la pregunta y a veces ya traen la respuesta.

También hay una ganancia menos visible. Google usa el marcado para entender la página y para reunir información sobre las personas, empresas y libros que aparecen en ella (Centro de la Búsqueda de Google). Según esa misma página, las propiedades de schema.org que Google no exige pueden servir a otros buscadores y herramientas.

Lo que no garantiza

Las directrices generales de Google son claras: marcar bien, aunque pase la prueba, no garantiza el resultado enriquecido. El marcado deja la función disponible, y el algoritmo decide si la muestra. Tiene en cuenta el historial de búsqueda, la ubicación y el dispositivo de quien busca, y a veces prefiere un resultado solo de texto.

La función también puede desaparecer. En junio de 2025, Google anunció que dejaría de mostrar siete tipos poco usados en la Búsqueda, entre ellos la información del curso, la revisión de la afirmación y las fichas de vehículos (Blog del Centro de la Búsqueda de Google). El mismo aviso dice que el cambio no afecta a la clasificación de las páginas, y que el uso de esos tipos fuera de la Búsqueda de Google sigue igual. El texto sobre preguntas frecuentes cuenta un recorte parecido, el de FAQPage.

Un marcado erróneo tiene un coste, pero limitado. Un problema de datos estructurados puede provocar una acción manual, y la página deja de poder optar al resultado enriquecido. Según Google, eso no cambia su posición en la búsqueda normal (directrices generales).

Las reglas que exige Google

Parte de las reglas es técnica, y una prueba automática la detecta. La otra parte es de calidad, y ninguna herramienta la revisa por ti. Las principales, de las directrices generales de datos estructurados:

Solo lo que está en pantalla. Si el JSON-LD describe a un artista, el cuerpo de la página tiene que hablar de ese artista. La información oculta queda fuera, aunque sea correcta.
Un retrato fiel de la página. El ejemplo de Google es un sitio de carpintería que marca sus instrucciones como recetas. El código puede ser válido, y el dato sigue siendo irrelevante.
Todas las propiedades obligatorias. Un elemento al que le falta una propiedad exigida por su tipo no entra en el resultado enriquecido.
El tipo más específico. Si dos tipos de schema.org encajan, usa el más preciso.
En la página que describe. El marcado vive en la propia página, no en una página vacía creada solo para él.
Acceso abierto. Si robots.txt o noindex bloquean la página, su marcado no se lee.

Más propiedades no siempre es mejor. La introducción de Google prefiere pocas propiedades recomendadas, completas y correctas, antes que todas rellenadas con datos mal formados.

Cuando la página tiene más de un elemento, como un artículo y su ruta de navegación, pueden ir anidados o por separado. Si dos elementos separados hablan de lo mismo, @id los une (Centro de la Búsqueda de Google).

Fechas con zona horaria

La fecha del artículo es un detalle que suele salir mal. La documentación de artículos de Google espera datePublished y dateModified en formato ISO 8601 y recomienda indicar la zona horaria. Sin ella, Google usa la zona horaria de su propio robot, y la hora registrada puede no ser la que el sitio quería decir.

Cómo comprobar antes y después de publicar

Google propone un camino en tres momentos (introducción a los datos estructurados):

Durante el desarrollo, la prueba de resultados enriquecidos valida el marcado y, en algunos casos, muestra una vista previa.
Después de publicar, los informes de estado de resultados enriquecidos siguen tus páginas en Search Console, el panel de Google para dueños de sitios. El marcado puede romperse más tarde por un problema en la plantilla de la página.
Para medir el efecto, compara páginas antes y después durante unos meses en el informe de rendimiento. Elige páginas estables, que no dependan de la época del año.

Para revisar el marcado frente al vocabulario de schema.org en general, sin mirar funciones de Google, existe el validador de schema.org (en inglés).

Cómo aparece en mi trabajo

En kahue.net, cada texto del blog sale con un bloque BlogPosting armado a partir de su propio frontmatter. Las fechas llevan la hora y la zona horaria de Brasilia, como en el marcado de este texto:

"datePublished": "2026-10-20T19:00:00-03:00",
"dateModified": "2026-10-20T19:00:00-03:00"

Cuando el texto no tiene fecha de revisión, dateModified repite la de publicación. Lo dejé escrito en el propio código: repetir la publicación es honesto, y una fecha de modificación inventada no lo es. La misma página lleva un BreadcrumbList con el camino de inicio, blog y texto, que es lo que la persona ve arriba.

En Vexor, el producto que creé para atender por WhatsApp con IA, el sitio brasileño (en portugués) declara la oferta y el precio en los datos estructurados. Los valores son los de la tabla visible: R$ 1.500 de instalación en el plan mensual y una cuota mensual de R$ 400, R$ 650 o R$ 1.200. R$ es el símbolo del real brasileño. Ese es el sentido de la regla: un precio que existiera solo en el código sería justo la información oculta que Google prohíbe.

Ninguno de estos sitios tiene mediciones publicadas del efecto del marcado en la búsqueda. Los ejemplos muestran cómo apliqué las reglas, no un resultado.

Dónde la documentación parece contradecirse

Google pide seguir su propia documentación, y no la de schema.org, para saber cómo se comporta la Búsqueda de Google (Centro de la Búsqueda de Google). schema.org tiene muchos tipos y propiedades que Google no usa, aunque otros buscadores y herramientas sí podrían. De ahí sale una división práctica: quien quiere el resultado enriquecido sigue a Google. Quien quiere describir bien la página para cualquier lector automático puede ir más allá, siempre que todo siga visible.

La diferencia mayor tiene que ver con el clic. Los casos de Google muestran más clics en las páginas marcadas. El NN/g recuerda la otra cara: cuando la respuesta ya aparece en la página de resultados, la persona resuelve la duda ahí y no hace clic en nada (Kate Moran y Cami Goray, NN/g (en inglés)). Para quien busca, eso es bueno. Para el sitio que escribió la información, no tanto. Moran y Goray lo ven sobre todo en dudas simples, como una dirección, un teléfono o una definición (NN/g (en inglés)). Cuando la decisión exige abrir la página, como comparar planes o leer el texto entero, el clic sigue siendo el camino.

El error común: marcar lo que la página no muestra

El error más caro es usar los datos estructurados como un escaparate paralelo. Una valoración que no aparece en el texto, un precio de oferta que solo existe en el código, un autor que la página no nombra. La prueba automática lo aprueba, porque la sintaxis es correcta. Lo que pide Google es otra cosa: el marcado tiene que ser un retrato fiel de la página, y las reseñas falsas pueden acabar en una acción manual (directrices generales). La comprobación que lo resuelve es sencilla: para cada propiedad del bloque, señala dónde está en la pantalla.