¿Cómo solucionar los errores de datos estructurados en Google Schema Markup Validator?

Revisa primero el error, no modifiques el código de inmediato

　　Al utilizar google schema markup validator para investigar datos estructurados, el error más común de los técnicos no es “no entender el mensaje”, sino modificar directamente los campos al ver el texto en rojo, lo que termina generando cada vez más confusión. Un enfoque más eficaz consiste en determinar primero a qué categoría pertenece el error: error de sintaxis, error de tipo, campo faltante, valor de campo no válido o falta de coincidencia entre el contenido de la página y el marcado. Las dos primeras categorías suelen provocar un fallo de análisis; las demás normalmente permiten analizar los datos, pero afectan la comprensión por parte de los motores de búsqueda y, en casos graves, pueden hacer que los resultados enriquecidos dejen de mostrarse.

　　Si eres responsable de la evaluación técnica de un sitio web y no del mantenimiento diario de contenidos, debes centrarte en tres aspectos: si el error bloquea el análisis, si afecta la aparición de la página objetivo en los resultados de búsqueda y si se trata de un problema a nivel de plantilla. Estos tres aspectos determinan la prioridad de reparación.

Si google schema markup validator muestra un error, ¿por dónde empezar?

　　Primero revisa cómo se insertan los datos estructurados en la página. Muchos sitios no escriben el JSON-LD manualmente, sino que lo generan dinámicamente mediante el CMS, la plantilla del tema, un plugin, una herramienta de gestión de etiquetas o un componente del frontend. Si no se identifica el origen, será difícil localizar el problema posteriormente.

　　Durante la revisión, normalmente sigo este orden:

1. Cuántos bloques de datos estructurados hay realmente en el código fuente de la página y qué tipo corresponde a cada uno.
2. A qué bloque apunta el error: JSON-LD, Microdata o RDFa.
3. Quién genera ese bloque: la plantilla, el plugin o la respuesta de una interfaz.
4. Si las páginas del mismo tipo también presentan el error, para determinar si se trata de un problema individual o masivo.
5. Si el contenido visible de la página respalda esos marcados, evitando “marcar algo que no se muestra en la página”.

　　Este paso parece básico, pero es fundamental. Especialmente cuando los sitios multilingües, los sitios de productos y los sitios de artículos comparten una plantilla, el mismo código puede producir errores completamente distintos en diferentes tipos de páginas.

¿Cuáles son los errores más comunes y cómo se establece la prioridad?

　　No todos los errores tienen el mismo nivel de gravedad. Durante la evaluación técnica, se recomienda analizarlos por separado.

　　Muchos equipos dejan las “advertencias” sin atender, pero si la advertencia afecta precisamente a un campo de resultados enriquecidos del que dependes, como el precio del producto, el inventario o la fecha de publicación del artículo, aunque no necesariamente provoque un fallo de análisis, puede afectar directamente la presentación en los resultados de búsqueda.

La página se abre correctamente, ¿por qué validator sigue mostrando un error de sintaxis?

　　Porque los navegadores toleran muchos problemas del frontend, mientras que los analizadores de datos estructurados no. Las situaciones más habituales son tres.

• Al concatenar JSON en la plantilla del backend, algún campo está vacío y queda una coma adicional al final.
• El valor de un campo contiene comillas dobles sin escapar, lo que interrumpe todo el bloque JSON-LD.
• Se utilizan scripts para insertar dinámicamente datos estructurados, pero la salida es texto de objeto y no JSON válido.

　　No revises este tipo de problemas únicamente a simple vista en la página. Consulta directamente el contenido application/ld+json del código fuente. Si es necesario, copia un único bloque JSON en la herramienta de validación para probarlo por separado; esto permite localizar el problema más rápidamente que realizar una depuración conjunta de toda la página.

¿Cuál es la diferencia esencial entre “falta un campo” y “campo no válido”?

　　La diferencia es importante. La falta de un campo significa que la información de marcado está incompleta; un campo no válido significa que se ha introducido, pero de una forma que no se puede reconocer. El primer caso suele deberse a que la plantilla no genera todos los datos comerciales necesarios, mientras que el segundo suele estar relacionado con un formato, un valor enumerado o un tipo de datos incorrectos.

　　Un caso habitual es el siguiente: una página de producto contiene un precio, pero en el schema el precio se escribe como un texto que mezcla moneda y número, por ejemplo “USD 199”; el validador puede indicar que el valor no es válido. Del mismo modo, si la fecha se escribe en un formato no estándar, el usuario puede entenderla, pero el analizador quizá no.

　　Por eso, al realizar una reparación, no basta con añadir el nombre del campo; también hay que comprobar si el formato del valor cumple los requisitos del tipo correspondiente. Durante la evaluación técnica, este paso permite identificar directamente si el diseño de la fuente de datos está normalizado.

¿Qué consecuencias tiene elegir incorrectamente el tipo de datos estructurados?

　　Elegir un tipo incorrecto es más problemático que omitir un campo. No se trata simplemente de que “falte un dato”, sino de que el significado de todo el bloque se desvía. Por ejemplo, aplicar Product a una página de servicios de un sitio corporativo, o aplicar FAQ o Review a una página de noticias común. Si la propia página no respalda esos contenidos, validator puede aprobarlos parcialmente, pero posteriormente el motor de búsqueda no los interpretará como se espera.

　　El método de evaluación es muy práctico: primero determina cuál es el objetivo principal de la página y después elige el tipo que mejor se ajuste a su contenido principal. No añadas todos los schemas posibles solo para intentar conseguir una mayor visibilidad en los resultados de búsqueda. Para los evaluadores técnicos, que el tipo y la intención de la página sean coherentes es un criterio más importante que “haber añadido algún marcado”.

¿Es normal o genera conflictos que aparezcan varios bloques de schema en una misma página?

　　Es normal, siempre que describan distintas entidades de la misma página o que la relación entre las entidades sea clara. Por ejemplo, normalmente no hay problema si una página de artículo contiene simultáneamente Article, BreadcrumbList y Organization. El problema surge con las duplicidades y las contradicciones.

　　Entre los conflictos más habituales se incluyen:

• El plugin y la plantilla generan cada uno un bloque Product para la misma página de producto.
• El nombre, el precio o el enlace no coinciden entre los dos bloques de datos.
• La ruta de navegación no coincide con la navegación real de la página.

　　Incluso si validator no marca todos estos problemas en rojo, deben resolverse. Para los motores de búsqueda, las entidades duplicadas aumentan el coste de interpretación y, en casos graves, pueden hacer que las señales importantes se neutralicen entre sí.

¿Por qué los resultados de validación son correctos, pero los resultados de búsqueda siguen sin mostrar resultados enriquecidos?

　　Este es uno de los puntos que muchas personas malinterpretan sobre google schema markup validator. La herramienta resuelve la cuestión de “si los datos se pueden analizar correctamente”, pero no garantiza que los resultados de búsqueda vayan a mostrarse. Superar la validación solo indica que los datos estructurados son básicamente válidos.

　　Si no aparecen resultados enriquecidos, normalmente hay que revisar también varios aspectos:

1. Si la página ya ha sido rastreada e indexada.
2. Si el contenido de la página cumple las condiciones de visualización correspondientes.
3. Si los datos estructurados coinciden con la información visible de la página.
4. Si el tipo objetivo pertenece al conjunto de formatos de visualización admitidos actualmente por el motor de búsqueda.

　　En otras palabras, el validador es la primera etapa, no la herramienta definitiva para determinar la aparición en los resultados. Durante la evaluación, los técnicos deberían informar por separado sobre la “corrección del análisis” y la “obtención de visibilidad”.

¿Cómo identificar un error a nivel de plantilla y por qué debe tener mayor prioridad que un error de una sola página?

　　Comprueba si el error aparece de forma constante en las URL del mismo tipo. Por ejemplo, si a todas las páginas de detalle de producto les falta brand, o si el formato de la fecha de publicación es incorrecto en todas las páginas de artículos, se trata de un problema típico de plantilla. El riesgo no se limita a una sola página, sino que seguirá extendiéndose a medida que se creen nuevas páginas.

　　El procedimiento es sencillo: realiza una revisión de muestra en páginas del mismo directorio, con la misma plantilla y en distintas versiones lingüísticas. Si el patrón de error es coherente, vuelve primero a la plantilla o a la capa de la interfaz de datos para repararlo. Para los equipos que utilizan sistemas inteligentes de creación de sitios web o un backend unificado para varios sitios, este tipo de problema suele poder resolverse en todo un conjunto de páginas con un único cambio, por lo que ofrece el mayor rendimiento de reparación.

Durante la evaluación, ¿qué campos merecen mayor atención?

　　No es necesario analizar en profundidad todos los atributos uno por uno. Primero céntrate en los campos más relacionados con el valor de la página. Las prioridades varían según el tipo de página:

• Página de producto: nombre, imagen, precio, moneda, inventario y enlace.
• Página de artículo: título, fecha de publicación, fecha de actualización, autor e imagen principal.
• Página corporativa: nombre de la organización, sitio web oficial, logotipo e información de contacto.
• Migas de pan: comprobar si los nombres de los niveles y los enlaces de destino son reales y accesibles.

　　Si estos campos principales no son estables, no tiene mucho sentido añadir después atributos secundarios. Primero hay que corregir la estructura principal y luego considerar las mejoras.

Después de la reparación, ¿cómo confirmar que el problema realmente se ha resuelto?

　　No te limites a comprobar que la prueba local sea correcta. Un método de confirmación más fiable consiste en realizar una revisión en tres pasos: “nivel de código, nivel de página y nivel de muestra”.

1. Nivel de código: confirma que la lógica de generación se ha modificado en la plantilla o interfaz correcta y que no se ha cambiado temporalmente una sola página.
2. Nivel de página: vuelve a rastrear el código fuente de la página online y confirma que el contenido generado ha cambiado.
3. Nivel de muestra: revisa aleatoriamente páginas del mismo tipo para verificar que no se trata de un caso aislado de una URL que funciona correctamente.

　　Si estás realizando la aceptación técnica de un proyecto de creación de sitios web o marketing internacional, no debes omitir este paso. Los errores de datos estructurados a menudo no son “imposibles de corregir”, sino problemas en los que “se ha corregido esta página, pero otras siguen mostrando errores”.

¿Qué criterio debe utilizarse finalmente para determinar si los datos estructurados cumplen los requisitos?

　　Un criterio suficiente es el siguiente: que puedan analizarse de forma estable, que el tipo sea coherente con la página, que los campos principales estén completos, que el formato de los valores sea correcto y que coincidan con el contenido visible de la página. Si se cumplen estos cinco puntos, la investigación de errores de google schema markup validator puede considerarse correctamente realizada.

　　Durante la evaluación técnica, no es necesario intentar completar todos los atributos recomendados. Primero elimina los problemas clave que afectan el análisis, la comprensión y la visualización; después determina si es necesario ampliar los tipos de schema. Este enfoque se ajusta mejor al ritmo de los proyectos reales y facilita aplicar los resultados de la reparación a las plantillas y los procesos, en lugar de limitarse a una revisión manual puntual.