¿Qué se debe comprobar primero después de que Google Schema Test muestre un error?

¿Qué debe comprobarse primero tras un error en Google Schema Test?

Introducción: Un error en Google Schema Test no significa que los datos estructurados del sitio web hayan dejado de funcionar por completo. El personal de evaluación técnica debe comprobar primero la sintaxis del código, las propiedades obligatorias, el estado de rastreo de la página y la correspondencia del tipo de Schema, para localizar rápidamente los problemas que afectan a la visualización en las búsquedas y a la indexación.

Primero determine el nivel del error: error, advertencia o fallo de rastreo

Después de ejecutar Google Schema Test, el primer paso no es modificar inmediatamente todos los avisos, sino confirmar si el resultado corresponde a un error, una advertencia o a que la herramienta no puede rastrear la página. Las prioridades de tratamiento de estos tres tipos de problemas son diferentes y determinan directamente la eficiencia de la posterior revisión.

Los errores suelen indicar que los datos estructurados no pueden analizarse correctamente o que faltan campos clave requeridos para determinado tipo de resultado enriquecido. Este tipo de problema puede impedir que Google identifique la entidad correspondiente y debe tratarse con la máxima prioridad.

Las advertencias suelen estar relacionadas con propiedades recomendadas, la integridad de la información o los requisitos para la visualización mejorada. No necesariamente afectan a la indexación básica, pero pueden reducir la probabilidad de activar resultados de búsqueda enriquecidos para productos, reseñas, FAQ, migas de pan y otros elementos.

Si la herramienta de prueba indica que no puede rastrear la página, que esta no es accesible o que el contenido está vacío, primero deben comprobarse el código de estado HTTP, las reglas de robots, las restricciones de inicio de sesión, las políticas de seguridad de CDN y el renderizado de JavaScript, en lugar de ajustar directamente el código Schema.

Compruebe primero si la sintaxis JSON-LD puede analizarse correctamente

Para la mayoría de los sitios web corporativos, JSON-LD es una forma de implementación de datos estructurados relativamente estable y fácil de mantener. Cuando Google Schema Test muestra un error, primero debe copiarse el fragmento de código correspondiente y revisar los paréntesis, las comillas, las comas y la jerarquía.

Los problemas de sintaxis habituales incluyen una coma adicional al final de un campo, comillas chinas que sustituyen a las comillas inglesas, arrays sin cerrar, objetos anidados sin llaves, y plantillas dinámicas que generan valores vacíos o variables incompletas.

El personal técnico también debe comprobar si la misma sección de Schema se inyecta repetidamente en la página. Algunos sistemas de creación web, plugins de SEO y componentes de temas pueden generar simultáneamente Organization, Product o BreadcrumbList, provocando conflictos de campos o información incoherente de las entidades.

En sitios web multilingües, debe confirmarse que el nombre, la descripción, la URL, la moneda y la información regional generados en cada versión de idioma correspondan con precisión a la página actual. No basta con copiar el Schema del idioma principal y sustituir el texto; los campos residuales también pueden provocar interpretaciones erróneas.

A continuación, verifique si las propiedades obligatorias coinciden con el contenido real de la página

Que la sintaxis sea válida no significa que los datos estructurados sean correctos. Los errores de negocio más frecuentes en Google Schema Test suelen deberse a la ausencia de propiedades obligatorias, por ejemplo, que Product carezca de name u offers, o que Article carezca de headline o image.

Durante la revisión, deben tomarse como referencia los requisitos oficiales del tipo de Schema y confirmarse uno por uno la existencia de los campos obligatorios, la corrección de su formato y si los valores de los campos pueden verificarse en el contenido que los usuarios realmente ven en la página.

Por ejemplo, si una página de producto indica precio, inventario y reseñas, debe garantizarse que la misma información se muestre también en el área visible de la página. Si el precio en el Schema es inferior al precio mostrado en la página, o el estado del inventario es contrario, puede afectar a la elegibilidad para resultados enriquecidos y a la credibilidad del sitio.

Los sitios web B2B de comercio exterior deben ser especialmente prudentes al usar el marcado Product. Si una página solo presenta las capacidades de un equipo, ofrece un formulario de consulta y no tiene una cotización de venta clara, no deben inventarse Offer ni datos de valoración agregada solo para obtener efectos de visualización.

Para los sitios web corporativos, normalmente es más adecuado priorizar la mejora de Organization, LocalBusiness, WebSite y BreadcrumbList. Estos elementos pueden ayudar a los motores de búsqueda a comprender la entidad de la marca, la estructura del sitio y la pertenencia de la página, con un riesgo relativamente controlable.

Confirme si el tipo de Schema coincide con la intención de búsqueda de la página

La elección incorrecta del tipo de Schema es un problema fácil de pasar por alto en las pruebas técnicas. La función de los datos estructurados es describir la entidad de la página, no asignarle etiquetas populares; por ello, debe mantenerse la coherencia con el contenido de la página, el modelo de negocio y la intención del usuario.

Las noticias y los artículos de conocimiento son adecuados para Article o BlogPosting; las páginas de detalles de productos pueden evaluar Product; el contenido de preguntas y respuestas puede usar FAQPage cuando cumpla las condiciones; y las rutas de navegación pueden complementarse con BreadcrumbList.

No fuerce el marcado de una página común de presentación de servicios como FAQPage, Review o Product, ni acumule tipos no relacionados en una misma página. Google presta mayor atención a la autenticidad del contenido y a la coherencia estructural; un marcado incorrecto, por el contrario, aumenta los riesgos de mantenimiento y revisión.

El personal de evaluación técnica puede deducir el tipo a partir del objetivo principal de la página: ¿la página busca crear reconocimiento de marca, obtener consultas B2B, vender productos estandarizados o responder a preguntas concretas? Primero deben aclararse los objetivos de negocio y, después, determinar los campos de Schema verificables.

Compruebe la versión que Google realmente rastrea, no solo la página mostrada en el navegador

Que el código local sea correcto y se muestre normalmente en el navegador no significa que Google pueda obtener los datos estructurados completos. Especialmente en sitios web que utilizan renderizado frontend, gestores de etiquetas o interfaces asíncronas, es necesario verificar la salida del servidor y el resultado tras el renderizado.

Si el Schema depende de JavaScript para insertarse después de la carga de la página, puede ocurrir que la prueba de la herramienta sea correcta, pero que existan retrasos de rastreo, contenido faltante o una carga inestable en distintas páginas. La información de la entidad principal es más adecuada para generarse de forma estable en el HTML inicial.

También debe comprobarse si canonical apunta a otras páginas, si hreflang multilingüe está configurado correctamente y si los datos estructurados de las versiones móvil y de escritorio son coherentes. Google se basa principalmente en la página canónica para su evaluación, por lo que debe evitarse que diferentes versiones transmitan información contradictoria.

Para las páginas ya publicadas, puede utilizarse la herramienta de inspección de URL de Google Search Console para confirmar la hora de rastreo, el estado de indexación y el resultado del renderizado. Schema Test se encarga de detectar problemas de marcado, mientras que Search Console está más cerca del rendimiento real en las búsquedas.

Establezca un proceso de corrección ordenado por alcance de impacto

Una corrección eficiente no debe realizarse manualmente página por página, sino que primero deben identificarse los problemas a nivel de plantilla. Si páginas de productos similares, páginas de artículos o sitios por idioma presentan el mismo error, debe priorizarse la modificación de las plantillas de CMS, la lógica de los componentes o las reglas de asignación de campos de datos.

Se recomienda tratar los problemas en el siguiente orden: «disponibilidad de rastreo, análisis sintáctico, campos obligatorios, coherencia del contenido y propiedades recomendadas». Los dos primeros determinan si Google puede identificar los datos; los dos intermedios están relacionados con la credibilidad; y finalmente se optimizan las oportunidades de visualización mejorada.

Tras la corrección, es necesario volver a ejecutar Google Schema Test y realizar comprobaciones puntuales en páginas de diferentes plantillas, idiomas y dispositivos. En los sitios web que generan contenido en masa, también deben supervisarse problemas de fuentes de datos como campos vacíos, URL duplicadas y precios desactualizados.

Los datos estructurados no son una tarea de desarrollo puntual, sino un mecanismo a largo plazo mantenido conjuntamente por el contenido del sitio web, los datos de productos y las plantillas técnicas. Tras cada rediseño, migración, actualización de plugins o incorporación de una nueva versión de idioma, deben incluirse en la lista de comprobación previa a la publicación.

Resumen: primero corrija los problemas que afectan a la identificación y luego optimice las oportunidades de visualización

El orden correcto tras un error en Google Schema Test es: primero confirmar que la página puede rastrearse; después resolver los problemas de sintaxis JSON-LD y propiedades obligatorias; y posteriormente verificar si el tipo de Schema, el contenido de la página y la URL canónica mantienen la coherencia.

Para el personal de evaluación técnica, lo más importante no es buscar cero advertencias, sino garantizar que los datos estructurados sean auténticos, estables y mantenibles, y que puedan expresar con precisión la entidad de la página. Solo así podrán proporcionar una base fiable para la indexación de Google, la visualización enriquecida y el crecimiento SEO a largo plazo.