Cómo validar datos estructurados sin herramientas de Google

La validación de datos estructurados se ha vuelto extrañamente dependiente de herramientas orientadas a Google. Es comprensible: muchos equipos añaden JSON-LD porque quieren resultados enriquecidos, y las herramientas de prueba de Google resultan familiares. Pero los datos estructurados no son un formato de Google. Normalmente son JSON-LD con vocabulario de Schema.org, incrustado en HTML, interpretado por muchos consumidores y mantenido por tu propio flujo de publicación.

Si solo validas desde la perspectiva de un motor de búsqueda, puedes pasar por alto problemas básicos: JSON no válido, datos que desaparecen después del renderizado, precios de productos desactualizados, URLs canónicas en conflicto o marcado que es técnicamente válido pero semánticamente absurdo.

Un mejor flujo de trabajo empieza por los estándares. Valida los datos como datos, luego valida el vocabulario y después valida la página tal como existe en producción.

¿Qué estás validando realmente?

“Datos estructurados” no es una sola cosa. En la mayoría de los sitios web tiene cuatro capas:

1. Sintaxis JSON — ¿se puede analizar el código?
2. Modelo JSON-LD — ¿se expande en datos enlazados significativos?
3. Vocabulario de Schema.org — ¿son plausibles los tipos y las propiedades?
4. Veracidad a nivel de página — ¿coincide el marcado con lo que usuarios y rastreadores pueden ver?

Las herramientas de Google se centran sobre todo en la cuarta capa más la elegibilidad específica de Google para resultados enriquecidos. Útiles, sí. Completas, no.

Por ejemplo, esto puede ser JSON-LD válido y aun así ser datos estructurados deficientes:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Aquí no hay nada roto. Pero si la página visible tiene un titular diferente, no muestra atribución de autor y tiene una fecha de última modificación que contradice el marcado, tienes un problema de calidad más que un problema de sintaxis.

Paso 1: Analiza el JSON antes de pensar en SEO

Empieza por la comprobación aburrida: ¿se puede analizar el JSON?

El JSON-LD incrustado en HTML suele romperse por pequeños errores de plantilla:

• comas finales
• comillas sin escapar en nombres de productos
• saltos de línea no válidos dentro de cadenas
• llaves que faltan después de campos condicionales
• bloques de script duplicados por herencia de layouts
• plugins de CMS que generan objetos parciales

Para comprobaciones locales, no necesitas una plataforma SEO. Usa las herramientas que ya forman parte de tu stack de desarrollo.

En JavaScript:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

En CI, extrae el contenido de los scripts del HTML renderizado y analízalo como JSON. Esto detecta muchos problemas antes de que lleguen a producción.

El punto importante: haz esto antes de cualquier validación de Schema.org. Un validador de vocabulario no puede ayudar si los datos no son JSON válido.

Paso 2: Comprueba el comportamiento de JSON-LD, no solo la sintaxis JSON

Un JSON válido no es automáticamente JSON-LD válido. JSON-LD usa conceptos como @context, @type, @id y relaciones de grafos. Si están mal formados, los analizadores pueden interpretar tus datos de forma distinta a la que pretendías.

Como mínimo, confirma que:

• cada bloque tiene un @context adecuado
• las entidades principales tienen valores @type claros
• las entidades repetidas usan valores @id estables cuando resulta útil
• las entidades anidadas están conectadas de forma lógica
• se usan arrays cuando puede haber varios valores

Para sitios grandes, los identificadores estables son especialmente útiles. Si tu organización aparece en datos de Article, Product, BreadcrumbList y FAQPage, usar el mismo @id ayuda a los consumidores a entender que son referencias a la misma entidad, no cuatro organizaciones no relacionadas con el mismo nombre.

Un patrón típico se ve así:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

No estás intentando impresionar a un validador. Estás haciendo que tus datos sean menos ambiguos.

Paso 3: Valida contra el vocabulario de Schema.org

Una vez que el JSON y la estructura JSON-LD estén correctos, revisa el vocabulario.

El validador de Schema.org es útil porque prueba contra términos de Schema.org, no contra las reglas de resultados enriquecidos de un único motor de búsqueda. Puede mostrar si las propiedades son reconocidas, si los tipos se interpretan como se espera y si tus estructuras anidadas tienen sentido.

Aquí es donde detectas errores como:

• publishingDate en lugar de datePublished
• imageUrl cuando se espera image
• marcado Product en un listado de categoría que no es un producto
• AggregateRating sin un elemento reseñado significativo
• Person usado para una cuenta de marca

Ten cuidado con las advertencias. Schema.org es flexible por diseño. Un validador puede permitir una propiedad que no resulta útil para tu caso de uso, o advertir sobre algo que es opcional. Trata la validación como evidencia, no como veredicto.

Una regla práctica: si una propiedad ayuda a una máquina a entender la página con más precisión, consérvala. Si existe solo porque alguien la copió de un generador de snippets, cuestiónala.

Paso 4: Compara el marcado con el contenido visible

Los motores de búsqueda y otros consumidores de datos tienden a desconfiar del marcado que no coincide con la página. Más importante aún: los usuarios merecen consistencia.

Para cada tipo de datos estructurados, compara el marcado con la página visible:

Article y BlogPosting

Comprueba que el titular, el autor, la fecha de publicación, la fecha de modificación, la imagen y el editor sean visibles o razonablemente inferibles. Si publicas contenido asistido por IA, tus datos estructurados no deberían usarse para blanquear una autoría poco clara. Hemos escrito por separado sobre la divulgación honesta de IA en un sitio web pequeño, y aquí se aplica el mismo principio: los metadatos deben aclarar, no ocultar.

Product

Comprueba nombre, precio, disponibilidad, moneda, variantes, valoraciones y recuentos de reseñas. Los datos estructurados de producto son especialmente propensos a quedarse obsoletos porque los precios y el estado de stock cambian fuera del CMS.

LocalBusiness

Comprueba nombre, dirección, número de teléfono, horario de apertura y área de servicio. Si tu pie de página dice una cosa y tu JSON-LD dice otra, el JSON-LD no es “mejor”. Es contradictorio.

BreadcrumbList

Comprueba que las posiciones de las migas de pan coincidan con la ruta de migas visible y que las URLs sean canónicas, rastreables y no redirijan innecesariamente.

Este trabajo no es glamuroso. También es donde se encuentran muchos problemas de datos estructurados.

Paso 5: Valida la página renderizada, no tu plantilla

Muchos sitios generan JSON-LD mediante JavaScript, gestores de etiquetas, capas de personalización o hidratación de componentes. Eso significa que el archivo de plantilla puede no representar lo que un rastreador o un navegador ve realmente.

Valida el HTML renderizado en al menos tres estados:

• build de desarrollo local
• URL de staging o vista previa
• URL de producción

Usa DevTools del navegador para inspeccionar el DOM final. Busca application/ld+json y copia el contenido exacto del script que existe después del renderizado. Si el marcado renderizado en servidor difiere del marcado hidratado, decide qué versión esperas que lean los consumidores.

Comprueba también si los datos estructurados se están duplicando. Los bloques Article o Product duplicados son comunes cuando un plugin de CMS y un componente personalizado emiten schema a la vez. La duplicación no siempre es fatal, pero la duplicación con conflictos sí es un problema: dos precios, dos autores, dos fechas de publicación o dos URLs canónicas.

Esto se parece a leer informes de rendimiento y diagnóstico: la primera tarea no es entrar en pánico, sino separar la señal del ruido. El mismo hábito ayuda cuando lees un informe de Lighthouse sin entrar en pánico, aunque los datos estructurados en sí no deberían reducirse a una sola puntuación.

Paso 6: Comprueba los detalles de transporte en producción

Los datos estructurados pueden ser perfectos en tu código fuente y aun así fallar en producción porque la página no es accesible de la forma que asumes.

Comprueba:

• que el código de estado final sea 200, no un 404 blando
• que la URL canónica coincida con la página que estás validando
• que las redirecciones sean intencionales y estables
• que las directivas robots no bloqueen la indexación donde se espera indexación
• que el HTML no sea sustituido por una página de error para algunos agentes de usuario
• que las páginas en caché no estén sirviendo JSON-LD obsoleto

Aquí es donde importa la inspección HTTP. Si una página de producto redirige a través de tres URLs antes de llegar a un destino canónico, valida la página final, no la primera URL copiada del CMS. Para la mecánica básica, nuestra guía sobre depuración de redirecciones y cabeceras HTTP en producción es un complemento útil.

Los datos estructurados no viven en el vacío. Viajan con cabeceras, redirecciones, caché, etiquetas canónicas y directivas robots.

Paso 7: Añade pruebas de datos estructurados a tu proceso de publicación

La validación manual está bien para una página. No escala a cientos o miles de URLs.

Un conjunto sencillo de pruebas automatizadas puede detectar los errores más costosos:

• obtener URLs representativas de cada tipo de plantilla
• extraer todos los bloques JSON-LD
• analizarlos con JSON.parse
• afirmar los campos requeridos para cada tipo de página
• comprobar que las fechas sean cadenas ISO 8601 válidas
• comprobar que las URLs sean absolutas y canónicas
• comprobar que los precios y la disponibilidad existan en páginas de producto
• comprobar que las entidades duplicadas no entren en conflicto

Puedes ejecutar esto en CI para plantillas y de forma programada para URLs de producción. El objetivo no es demostrar que aparecerá cada función de resultados enriquecidos. Nadie fuera del motor de búsqueda puede prometer eso. El objetivo es mantener tus propios datos precisos, analizables y consistentes.

<!-- tool-cta:start -->

💡 Prueba esto: Antes de validar la lógica del esquema, pasa tu JSON-LD por el JSON Formatter para detectar errores de sintaxis que, de lo contrario, romperían cada comprobación posterior.

<!-- tool-cta:end -->

Una lista de comprobación de validación basada en estándares

Usa esta breve lista antes de preguntar si a un motor de búsqueda le gusta la página:

• ¿Es cada bloque JSON-LD JSON válido?
• ¿Incluye cada bloque el @context y el @type correctos?
• ¿Están escritas correctamente las propiedades de Schema.org?
• ¿Coincide el marcado con el contenido visible?
• ¿Están actualizados fechas, precios, valoraciones y disponibilidad?
• ¿Son las URLs absolutas, canónicas y alcanzables?
• ¿Es la página de producción renderizada la misma página que probaste?
• ¿Son las entidades duplicadas intencionales y no conflictivas?

Si puedes responder sí a esas preguntas, has hecho la parte duradera del trabajo con datos estructurados. Las pruebas específicas de búsqueda aún pueden ser útiles más adelante, pero deberían ser la comprobación final de compatibilidad, no la base de tu proceso de validación.