¿Qué hacer si Google Schema Testing Tool no detecta datos?

La página ya incluye código JSON-LD, pero al abrir google schema testing tool aparece el mensaje «No se han detectado datos estructurados». No se apresure a reescribir todo el marcado. Este resultado normalmente no significa que el Schema sea necesariamente inválido; es más habitual que el contenido de la página obtenido por la herramienta de prueba no coincida con el que se visualiza en el navegador, o que existan problemas con la ubicación del marcado, la sintaxis del código o el estado de acceso a la página.

En la práctica, las situaciones que más fácilmente provocan diagnósticos erróneos son: los desarrolladores ven que el código funciona correctamente en el entorno de pruebas, pero la herramienta no puede rastrearlo tras la publicación; o bien, el backend del sitio ya ha guardado campos como productos, migas de pan y artículos, pero la página del frontend no genera realmente datos estructurados. Al solucionarlo, primero debe confirmarse si «el HTML obtenido por la herramienta contiene el marcado», después comprobar si el marcado puede analizarse y, por último, determinar si los tipos y las propiedades cumplen los requisitos.

Primero distinga: no se ha detectado nada o se ha detectado, pero no cumple los requisitos de resultados enriquecidos

«No se han detectado datos» y «se han detectado datos, pero existen advertencias» son dos tipos de problemas distintos. El primero indica que la herramienta no ha podido analizar Microdata, RDFa o JSON-LD reconocibles en la página actual; el segundo indica que el marcado ya existe, pero faltan algunos campos recomendados, lo que no necesariamente afecta al reconocimiento básico.

La herramienta original de Google, Structured Data Testing Tool, ya no recibe mantenimiento. Actualmente, para realizar comprobaciones, puede utilizar la herramienta de prueba de resultados enriquecidos para verificar si la página cumple las condiciones de visualización enriquecida compatibles con Google, o Schema Markup Validator para comprobar la sintaxis y la jerarquía de Schema.org. No concluya directamente que todos los datos estructurados de la página han dejado de funcionar solo porque una herramienta no muestre resultados; las distintas herramientas no se centran exactamente en los mismos tipos compatibles, la renderización con JavaScript ni las reglas de validación.

Primer paso: confirme que ha enviado la página final accesible

Abra primero la URL que desea probar en una ventana de incógnito y confirme que puede accederse a ella directamente, que devuelve una página normal y que no requiere inicio de sesión, código de verificación, restricciones regionales ni Cookies especiales. Las herramientas de prueba no pueden leer contenido bloqueado, con redireccionamientos anómalos o de acceso restringido.

• Compruebe si la URL redirige automáticamente de http a https o de sin www a www; debe probarse la dirección final de destino.
• Confirme que la página no sea un borrador, un enlace de vista previa, una página de edición del backend ni una dirección de prueba visible solo en la intranet.
• Revise si se producen múltiples redireccionamientos. Si la cadena de redirecciones es demasiado larga o conduce a una página de selección de idioma o de error, la herramienta no detectará la página de contenido objetivo.
• Compruebe si el servidor devuelve contenido diferente a los rastreadores, por ejemplo debido a protección de seguridad, limitación de frecuencia, errores 403, 503 o páginas en blanco.

Algunos sitios web devuelven versiones diferentes según el idioma, la IP o el User-Agent del visitante. Que el navegador acceda correctamente no significa que la herramienta de rastreo obtenga un HTML normal. En este caso, debe confirmar en los registros del servidor, las reglas de protección del CDN o los resultados de rastreo de la página si la solicitud ha sido bloqueada.

Segundo paso: busque los datos estructurados en el código fuente de la página

No los busque únicamente en «Inspeccionar elemento» del navegador. Las herramientas de desarrollo muestran el DOM después de que la página ejecute JavaScript, mientras que la herramienta de prueba puede no ejecutar los scripts de la misma manera. Debe utilizar «Ver código fuente de la página» y buscar application/ld+json, schema.org, itemtype o itemscope.

Para JSON-LD, una práctica habitual es colocar el contenido dentro de la etiqueta <script type="application/ld+json">. Si esta sección no aparece en el código fuente y solo está presente en el DOM dinámico, el problema probablemente procede de una inserción asíncrona en el frontend. Especialmente en aplicaciones de una sola página, páginas de filtrado y páginas de detalle de producto en ventanas emergentes, los datos estructurados pueden generarse solo después de que la interfaz devuelva datos; las diferencias en el momento del rastreo pueden hacer que google schema testing tool no los detecte.

Una solución más fiable es generar el JSON-LD de las páginas principales junto con el HTML inicial, o adoptar una solución fiable de renderización del lado del servidor o prerenderizado. La información principal de las páginas de detalle de productos, artículos y categorías debe poder leerse prioritariamente en la respuesta inicial, en lugar de depender por completo de su carga tras la interacción del usuario.

Tercer paso: revise la sintaxis de JSON-LD, no solo el contenido de los campos

Al copiar código, es fácil introducir comillas de ancho completo, comas finales, comillas dobles sin escapar o paréntesis incompletos. Si el análisis de JSON falla, la herramienta normalmente ignorará todo el bloque de datos. Que el código parezca Schema no significa que sea JSON válido.

Compruebe también que @context sea https://schema.org y que @type esté escrito correctamente. Los valores de las propiedades deben mantenerse coherentes con el contenido visible de la página. Por ejemplo, los precios, el inventario, las valoraciones y las fechas de publicación de los productos no pueden conservar durante mucho tiempo en el marcado información caducada o inexistente en la página. Que la herramienta pueda analizarla no significa que el motor de búsqueda vaya a utilizar esa información para mostrarla.

Los problemas causados por plantillas, plugins y caché son más difíciles de detectar

Al utilizar un sistema de creación de sitios o un CMS, si sigue sin detectarse nada después de marcar «Habilitar datos estructurados» en el backend, a menudo el problema no es que se haya elegido un tipo de Schema incorrecto, sino que la plantilla no llama al componente correspondiente. Por ejemplo, una plantilla de artículos muestra el título y el cuerpo, pero omite el módulo Schema del artículo; los datos del producto se rellenan en el sistema de productos, pero la página de detalle actual utiliza una plantilla personalizada y los campos relacionados no se han transferido.

Otro problema frecuente es la caché. Tras actualizar la página, la configuración del backend ya ha cambiado, pero el CDN, la caché de página o la caché de objetos siguen devolviendo HTML antiguo. El orden de comprobación debe ser: guardar la configuración y publicar la página, limpiar la caché del sitio y del CDN, consultar el código fuente utilizando la URL pública final y volver a enviar la prueba. Ver código nuevo únicamente en la página de vista previa del backend no demuestra que la página en línea se haya actualizado.

No genere datos contradictorios duplicados en la misma página

Algunos sitios activan simultáneamente el marcado SEO integrado en el tema, el marcado de plugins de tienda y plugins SEO de terceros. Como resultado, una página de producto puede mostrar dos Product y dos Offer, incluso con precios o inventarios inconsistentes. Estas páginas no necesariamente mostrarán «No se han detectado datos», pero dificultarán los diagnósticos posteriores y también pueden reducir la credibilidad del marcado.

Se recomienda conservar la entidad principal según la función de cada página: las páginas de detalle de artículos deben centrarse en Article o BlogPosting, las páginas de detalle de productos en Product y el área de navegación puede complementarse con BreadcrumbList. Primero elimine o desactive las fuentes duplicadas y vuelva a realizar la prueba. Para entidades globales como Organization y WebSite, también deben mantenerse coherentes datos como el nombre, la URL y el Logo, evitando que distintos plugins generen versiones diferentes por separado.

Secuencia de validación después de la corrección

1. Abra el código fuente de la página pública y confirme que los datos estructurados se hayan generado realmente.
2. Valide por separado el fragmento de código JSON-LD para descartar errores de comas, comillas, paréntesis y codificación.
3. Utilice una herramienta de validación de Schema para confirmar que se pueden analizar el tipo de entidad, la jerarquía de propiedades y las relaciones de referencia.
4. Después, utilice la herramienta de prueba de resultados enriquecidos para comprobar los tipos de visualización específicos compatibles con Google y los campos faltantes.
5. Vuelva a probar la URL después de limpiar la caché; si la página ya está indexada, puede solicitar un nuevo rastreo en la herramienta de gestión de recursos de búsqueda.

Por último, debe mantenerse un límite de criterio: que los datos estructurados superen la validación solo significa que las máquinas pueden comprender parte de la información de la página, y no garantiza que se obtenga una visualización enriquecida; por el contrario, que un tipo de Schema no se muestre en la herramienta de resultados enriquecidos tampoco significa necesariamente que el marcado no tenga valor. Para el problema de «no se detectan datos», priorizar la accesibilidad de la página, la generación del HTML inicial, la sintaxis JSON y la versión de caché suele ser más eficaz que añadir campos repetidamente.