Formato basado en JSON para expresar datos estructurados enlazados, que suele incrustarse en un elemento script para que una página describa entidades y relaciones sin cambiar el HTML visible.
La decisión y sus límites
JSON-LD es una forma de serializar datos enlazados en JSON. En las páginas web suele colocarse en un elemento script y se usa con el vocabulario de Schema.org para describir las mismas entidades que ve el lector: un artículo, un producto, una organización, una miga de pan o un evento. Es un formato de representación, no una promesa de resultado enriquecido. El grafo debe ser sintácticamente válido y coincidir con los datos visibles y actuales de la página.
Qué revisar
Obtén el HTML tras el renderizado en lugar de suponer que la plantilla de origen sobrevivió al despliegue. Analiza el JSON-LD, identifica cada nodo y sus identificadores, y compara las propiedades importantes con la página visible. Comprueba que las URL responden, que las referencias apuntan a las entidades previstas y que valores como fechas, precios, disponibilidad, autor o imagen no están desactualizados. Interpreta los avisos del validador en su contexto: un mensaje del validador es un indicio que revisar, no necesariamente un defecto.
Un camino práctico de implementación
Elige el tipo de Schema.org más sencillo que encaje, modela primero la entidad principal y añade entidades vinculadas solo cuando la página muestre sus datos. Genera los valores desde la misma fuente estructurada que usa la plantilla visible, siempre que sea posible. Valida una página representativa tras el lanzamiento y añade comprobaciones de regresión para las plantillas que generan muchas páginas. Mantén separadas las comprobaciones de sitemap, canonical y robots de la validación de JSON-LD.
Errores y límites de medición
El fallo típico es el «teatro del schema»: añadir vocabulario que la página no respalda para forzar una función de búsqueda. Las propiedades ocultas, inventadas o contradictorias crean riesgo de mantenimiento y pueden hacer el grafo menos fiable. Primero valido los datos estructurados contra la página visible y después reviso el grafo. Corrijo solo los errores reales de vocabulario o de referencias, no cualquier cosa que haga callar al validador.
Ejemplo práctico de implementación. En un artículo editorial, parte del registro visible: titular, firma, fecha de publicación, imagen principal, URL canónica e identidad del editor. Modela ese artículo en JSON-LD a partir de los mismos campos de contenido que renderizan la página. Asigna al artículo un identificador estable y enlaza el editor y la imagen solo cuando esas entidades sean reales y existan. Si el autor, la fecha o la imagen no aparecen en la página visible, no los inventes en el grafo para contentar a un validador.
Criterios de comprobación. Obtén el HTML renderizado tras el despliegue, extrae cada script JSON-LD y analiza cada grafo. Compara los valores de titular, fecha, imagen, URL y autor con la página tal como la ve el usuario. Confirma que los identificadores y las URL llevan a los recursos previstos y que un artículo no describe por error otra entidad de la plantilla. Ejecuta la prueba de datos estructurados correspondiente, pero clasifica los hallazgos: un error de análisis, una discrepancia de vocabulario, una recomendación opcional que falta y una nota sobre la elegibilidad para una función de búsqueda son cosas distintas.
Errores habituales. No pegues un bloque de schema genérico en todas las páginas ni marques un servicio, una categoría y un producto como la misma entidad principal. No uses JSON-LD para ocultar precios, valoraciones, stock, reseñas o autores que los usuarios no pueden ver. Una prueba de resultados enriquecidos no puede verificar canonical, robots, sitemap ni la veracidad del contenido, así que esas comprobaciones también deben formar parte de la revisión previa al lanzamiento. JSON-LD ayuda a describir una página; no compensa una página inaccesible o poco útil.