Para conseguir resultados enriquecidos en los resultados de búsqueda, primero es necesario comprobar la precisión del marcado schema. Este artículo presenta a los evaluadores técnicos los métodos de comprobación, los errores comunes y los puntos clave de optimización.

Los usuarios que buscan “comprobar schema” normalmente no quieren conocer la definición básica de Schema, sino confirmar si el marcado existente en una página puede analizarse, si cumple las directrices de Google y por qué no aparecen resultados enriquecidos.
Los evaluadores técnicos se preocupan más por evidencias verificables: si el código es válido, si el contenido de la página coincide con el marcado, si los campos clave están completos, si el motor de búsqueda ya ha rastreado la página y cuál es la verdadera razón por la que no aparecen resultados enriquecidos.
Por lo tanto, al comprobar Schema no basta con ver si una herramienta muestra “aprobado”. Una evaluación más precisa debe incluir seis aspectos: sintaxis, tipo de entidad, integridad de propiedades, contenido visible de la página, estado de indexación y elegibilidad en las plataformas de búsqueda.
Debe quedar claro que unos datos estructurados correctos no garantizan la obtención de resultados enriquecidos. Schema proporciona señales semánticas comprensibles para las máquinas; la decisión final de mostrarlos sigue dependiendo de la evaluación de calidad del motor de búsqueda, el tema de la página y el entorno competitivo.
El primer paso para comprobar schema no es abrir un validador, sino confirmar el tipo de página y el objetivo de negocio. Las páginas de detalle de producto, artículos, servicios, FAQ, presentación de organización y navegación con migas de pan requieren marcados diferentes.
Por ejemplo, las páginas de productos de empresas manufactureras B2B normalmente deben comprobar primero Product, Offer, Brand y BreadcrumbList; las páginas de contenido informativo se adaptan mejor a estructuras como Article, FAQPage, HowTo o WebPage, en lugar de copiar mecánicamente plantillas de productos.
Si el contenido de una página solo presenta capacidades de servicio, pero se añaden campos Product con precios, inventario o valoraciones inexistentes, algunas herramientas de comprobación podrían no informar errores, pero esto supone una incoherencia entre el contenido y el marcado y conlleva el riesgo de perder la elegibilidad para aparecer.
En los sitios independientes multilingües, también debe confirmarse que el nombre, la descripción, la moneda del precio, las imágenes y los enlaces de las páginas en distintos idiomas correspondan a la versión lingüística actual. No permita que las páginas en inglés hereden campos en chino ni que las páginas de diferentes regiones reutilicen direcciones Offer no válidas.
Para la validación básica se puede utilizar Schema Markup Validator, centrado en comprobar si la sintaxis de JSON-LD, Microdata o RDFa puede analizarse y si existen errores en las relaciones entre tipos, los campos obligatorios y los formatos de los valores de las propiedades.
Si el objetivo son los resultados enriquecidos de Google, también se debe utilizar Rich Results Test. Esta herramienta identifica si una página cumple los tipos de resultados enriquecidos admitidos por Google y clasifica los problemas como errores, advertencias y elementos no reconocidos.
Los errores normalmente bloquean la elegibilidad para un determinado tipo de resultado enriquecido; por ejemplo, cuando Product carece de los campos name u offers. Las advertencias no necesariamente bloquean la visualización, pero suelen indicar información incompleta, como la ausencia de campos opcionales de mejora tales como aggregateRating, review o shippingDetails.
En el entorno en línea, también es necesario combinarlo con los informes de mejoras de Google Search Console. Los validadores solo pueden demostrar que el código de la URL actual es legible; Search Console ayuda a confirmar si Google ya ha rastreado la página, cuántos elementos válidos ha detectado y qué páginas siguen generando errores.
Durante las pruebas, deben comprobarse por separado la URL de producción y el DOM renderizado. En los sitios web que generan JSON-LD dinámicamente mediante JavaScript, la ausencia de marcado en el código fuente no necesariamente es un problema, pero debe confirmarse que el rastreador pueda obtener de forma estable los datos completos después del renderizado.
El primer tipo es la incoherencia entre el contenido marcado y el contenido visible de la página. Los campos como precio, descuento, inventario, valoración, autor y fecha de publicación deben contar con información correspondiente en la página que el usuario visita realmente; no se pueden inventar para conseguir visibilidad.
El segundo tipo es la duplicación o el conflicto de entidades. Si una misma página genera varios Product al mismo tiempo, o si plugins, temas y código manual generan repetidamente Organization o BreadcrumbList, los motores de búsqueda pueden no determinar cuál es la entidad principal.
El tercer tipo es el uso de formatos de campo incorrectos. Las URL deben utilizar direcciones absolutas accesibles; se recomienda emplear el formato ISO para las fechas; el precio debe ser un número reconocible; la moneda debe utilizar el código ISO 4217; y los enlaces de imágenes deben poder ser rastreados por los motores de búsqueda.
El cuarto tipo son relaciones de anidación inadecuadas. Por ejemplo, Offer debe pertenecer al Product correspondiente, Review debe referirse al objeto realmente evaluado y el author y publisher de Article deben disponer de una identidad reconocible. Aunque los campos estén completos, unas relaciones incorrectas también reducen la fiabilidad de los datos.
El quinto tipo es la falta de mantenimiento continuo tras la implementación. Después de la retirada de productos, ajustes de precios, migraciones de páginas o renovaciones multilingües, Schema suele conservar datos antiguos. El equipo técnico debe incorporar la comprobación de datos estructurados al proceso de publicación, en lugar de tratarla como un proyecto puntual.
Cuando Rich Results Test indica que todo es válido, pero no hay resultados enriquecidos en las búsquedas, primero compruebe si la página ya está indexada. Puede confirmar la URL canónica, el momento de rastreo, el estado de indexación y el resultado del renderizado mediante la herramienta de inspección de URLs de Search Console.
A continuación, confirme si Google admite la visualización de ese tipo en el país, idioma y contexto de búsqueda actuales. No todos los tipos de Schema generan resultados enriquecidos visibles; algunos marcados se utilizan principalmente para comprender entidades, relacionar grafos de conocimiento o facilitar la clasificación del contenido.
También debe evaluarse la calidad de la propia página. Si el contenido es demasiado escaso, la información no se puede verificar, la experiencia de página es deficiente, el producto no se puede comprar o la fuente de las valoraciones no es fiable, incluso un marcado correcto puede no obtener la visualización esperada o incluso ser ignorado.
Los resultados enriquecidos son una forma mejorada de los resultados de búsqueda, no un sustituto del posicionamiento. Una estrategia más fiable consiste en evaluar Schema junto con una arquitectura rastreable, la calidad del contenido, la configuración de internacionalización, la velocidad de la página y la optimización SEO continua.
Para las páginas nuevas, se puede definir primero la entidad principal de la página y las fuentes de los campos en el entorno de desarrollo, y después dejar que el frontend o el CMS genere automáticamente JSON-LD. Los campos deben proceder de datos reales de productos, artículos o información empresarial; no se recomienda depender de copiar y pegar manualmente.
Antes de publicar, pueden establecerse cuatro criterios de aceptación: ausencia de errores bloqueantes en el validador, coincidencia entre el contenido visible y el marcado, accesibilidad de las URL clave y estabilidad de los resultados de muestreo en páginas del mismo tipo. Esto evita que una prueba de página individual se apruebe mientras las plantillas en lote presentan errores.
Después de la publicación, deben revisarse mensualmente los informes de mejoras de Search Console y realizar nuevas comprobaciones por muestreo tras actualizaciones de plantillas, cambios de plugins, migraciones del sitio y actualizaciones masivas de productos. Las páginas de alto tráfico, las páginas de categorías principales y las páginas de destino multilingües deben supervisarse con prioridad.
Los activos de contenido también pueden incorporarse a una gestión unificada. Por ejemplo, cuando una empresa publica contenido de investigación como Obstáculos de implementación y vías de optimización del cuadro de mando integral en la evaluación presupuestaria de empresas de procesamiento de aluminio, puede utilizar el marcado Article para complementar el título, el autor, la fecha de publicación, la imagen principal y las entidades del texto, mejorando la base para que el contenido se interprete correctamente.
El objetivo principal de comprobar schema no es lograr que todas las luces del validador estén en verde, sino confirmar que los motores de búsqueda han obtenido información estructurada real, completa, sin conflictos y acorde con el propósito de la página.
Durante la evaluación técnica, primero se debe elegir el tipo de Schema adecuado, después confirmarlo de forma cruzada mediante validadores, pruebas de resultados enriquecidos y Search Console, y por último evaluar los resultados combinando la indexación, la calidad del contenido y los datos de negocio. Solo así los resultados enriquecidos pueden convertirse en el resultado de una optimización sostenible, en lugar de una función que aparece por casualidad.
Artículos relacionados
Productos relacionados