¿Qué diferencia hay entre validar el marcado y verificar la publicación?

Si has llegado buscando la diferencia entre validar y verificar, lo más probable es que tengas delante una prueba en verde y una duda: si el marcado es válido, ¿por qué no lo ves en tu ficha, o por qué no hace lo que esperabas? Son dos comprobaciones distintas sobre los datos estructurados de una tienda. Validar pregunta si el código está bien escrito; verificar, si ese código está de verdad en la página que sirve tu tienda y si dice lo mismo que ella. La propia Google las pone en fila en su documentación: la prueba del marcado durante el desarrollo, y el seguimiento de las páginas después de publicarlas.⁠^{[5]Google Search Central. Introduction to structured data markup in Google Search}

Qué pregunta responde cada una

Validar es comprobar el código contra unas reglas, y hay dos juegos de reglas, con una herramienta para cada uno.

El primero es el vocabulario de Schema.org, lo que en el sector se llama schema markup. Lo revisa el validador de schema, el Schema Markup Validator. Cuando Google trasladó esa herramienta a un dominio al servicio de la comunidad de Schema.org, dijo que su propósito principal sería comprobar la sintaxis y la conformidad del marcado con los estándares de Schema.org, y que dejaría de comprobar los tipos de resultado enriquecido de la Búsqueda.⁠^{[6]Google Search Central Blog (15 de diciembre de 2020, con actualizaciones de 2021). An update on the Structured Data Testing Tool} Conviene saber que Schema.org es flexible a propósito: los validadores pueden avisar de datos ambiguos, pero no están obligados a tratar como error una estructura inesperada.⁠^{[7]Schema.org. Data model}

El segundo son los requisitos de Google, los que deciden si una página opta a los resultados enriquecidos. Los revisa la Prueba de resultados enriquecidos (Rich Results Test), que Google presenta como su herramienta oficial para ver qué resultados enriquecidos pueden generar los datos estructurados de una página.⁠^{[2]Google Search Central. Schema Markup Testing Tool} Un ejemplo de esas reglas: para que una ficha de producto opte a las fichas de comerciante, Google exige un nombre, una imagen y una oferta con un precio mayor que cero y su moneda.⁠^{[8]Google Search Central. Merchant listing (Product, Offer) structured data}

Verificar es comprobar la página, no el código. La verificación de publicación lee la página que sirve tu tienda y compara lo que encuentra con lo que guardaste: el dato está, es distinto o no aparece. Y suma una pregunta que ninguna herramienta de validación contesta: si el marcado dice lo mismo que la página. Google pide no marcar contenido que no ve quien lee la página y que el marcado sea una representación fiel de su contenido, y avisa de que estas pautas de calidad no se pueden comprobar con facilidad con una herramienta automática.⁠^{[4]Google Search Central. General structured data guidelines} Para sus funciones de IA lo resume en una línea: que los datos estructurados coincidan con el texto visible de la página.⁠^{[9]Google Search Central. AI features and your website}

Qué lee cada una: el código o la página

La confusión empieza aquí, porque las herramientas de validación también aceptan una URL. La Prueba de resultados enriquecidos admite dos entradas: una URL o un fragmento de código que pegas.⁠^{[1]Ayuda de Search Console. Rich Results Test} Con el fragmento, valida exactamente lo que has pegado, y eso puede no ser lo que sirve tu tienda. Con la URL, entra en la página como Google-InspectionTool, sin sesión iniciada, y enseña el código ya renderizado; si robots.txt la bloquea o la página no es pública, no se puede probar.⁠^{[1]Ayuda de Search Console. Rich Results Test} Si tu marcado se genera con JavaScript, Google recomienda la URL y no el código, porque el modo de código tiene limitaciones con JavaScript.⁠^{[10]Google Search Central. Generate structured data with JavaScript}

Probar la URL se acerca a verificar: confirma que en la página publicada hay un marcado y que Google puede leerlo. Lo que no dice es si los valores son los que guardaste, ni si coinciden con lo que ve el cliente. Un precio en el marcado distinto del que enseña la ficha no es un error de sintaxis, y Google advierte de que sus herramientas detectan la mayoría de los errores técnicos, no los de calidad.⁠^{[4]Google Search Central. General structured data guidelines}

La herramienta que más se acerca a la verificación es la inspección de URLs de Search Console. Distingue dos versiones de tu página: la indexada, que es la última que rastreó Google y no la de hoy, y la prueba en directo, que puede diferir de la indexada si has cambiado algo después. «Ver página probada» enseña una captura de la página renderizada, su HTML y sus cabeceras HTTP.⁠^{[3]Ayuda de Search Console. URL Inspection tool} Tiene dos límites: solo funciona con URL de una propiedad tuya, y una prueba en directo superada no garantiza que la página salga en los resultados de búsqueda.⁠^{[3]Ayuda de Search Console. URL Inspection tool}

Dónde se pierde un marcado válido

Un bloque de JSON-LD puede pasar las dos validaciones y no llegar nunca a la ficha. Entre el código y la página publicada hay una cadena, y cada eslabón lo documenta la propia plataforma:

• Una extensión que no está activa. En Shopify, los bloques de inserción de aplicaciones (app embed) vienen desactivados al instalar la aplicación. Se activan en el editor de temas, en Configuración del tema, y solo entonces se inyectan antes del cierre de </head> o de </body>.⁠^{[11]Shopify.dev. Configure theme app extensions}
• El JavaScript. Google procesa los datos estructurados que están en el DOM cuando renderiza la página,⁠^{[10]Google Search Central. Generate structured data with JavaScript} y usa el HTML renderizado para indexarla, pero puede saltarse el renderizado de JavaScript si la página no responde con un código 200 o si el HTML original lleva un noindex. Como no todos los bots ejecutan JavaScript, Google sigue recomendando el renderizado del lado del servidor o el prerrenderizado.⁠^{[12]Google Search Central. Understand JavaScript SEO basics}
• El marcado de producto generado con JavaScript. Google avisa de que el marcado generado de forma dinámica puede hacer que los rastreos de Shopping sean menos frecuentes y menos fiables, un problema para datos que cambian rápido, como la disponibilidad y el precio, y recomienda ponerlo en el HTML inicial.⁠^{[8]Google Search Central. Merchant listing (Product, Offer) structured data}
• El acceso. Google pide no bloquear a Googlebot las páginas con datos estructurados, ni con robots.txt, ni con noindex, ni con ningún otro control de acceso.⁠^{[4]Google Search Central. General structured data guidelines}
• La caché y el marcado desactualizado. Google Merchant Center enumera, entre las causas de que la disponibilidad de un producto no coincida con la de su página, un marcado desactualizado, información contradictoria en el sitio y los retrasos de caché.⁠^{[13]Ayuda de Google Merchant Center. Inaccurate availability status due to inconsistency between feed and landing page}

En ninguno de estos casos falla la validación del código. Falla la publicación, y solo la ve quien lee la página.

Qué pasa si solo haces una

Solo validar. Te quedas con un código correcto y ninguna certeza sobre la tienda. Google lo deja escrito: no garantiza que tus datos estructurados salgan en los resultados aunque la página esté bien marcada según la Prueba de resultados enriquecidos.⁠^{[4]Google Search Central. General structured data guidelines} Y hay quien compara por su cuenta: Merchant Center contrasta la disponibilidad de tus datos de producto con la de la página de destino, y cuando no coinciden puede mandar avisos a la cuenta o rechazar productos de forma preventiva.⁠^{[13]Ayuda de Google Merchant Center. Inaccurate availability status due to inconsistency between feed and landing page}

Solo verificar. Sabes que el marcado está en la página, pero no si sirve. Search Console llama no válido a un elemento con al menos un problema crítico,⁠^{[14]Ayuda de Search Console. Rich result report overview} y una ficha cuyo marcado no lleva imagen no opta a las fichas de comerciante aunque la foto se vea en la página.⁠^{[8]Google Search Central. Merchant listing (Product, Offer) structured data} Eso lo encuentra la validación, no la lectura de la página.

Los informes de resultados enriquecidos de Search Console parecen cubrir las dos cosas, porque leen tu sitio después de rastrearlo. No del todo: enseñan una muestra de los elementos detectados, no la lista completa, y para una página que no aparece ahí Google remite a la inspección de URLs.⁠^{[14]Ayuda de Search Console. Rich result report overview}

En qué orden, según Google

Google da el orden en su introducción a los datos estructurados: revisar el marcado con la Prueba de resultados enriquecidos durante el desarrollo, y con los informes de estado de los resultados enriquecidos después de publicar, porque las páginas pueden romperse después de publicarse por problemas de plantilla o de servidor.⁠^{[5]Google Search Central. Introduction to structured data markup in Google Search} Su documentación de fichas de comerciante concreta la secuencia: validar con la prueba, publicar primero unas pocas páginas, ver con la inspección de URLs cómo las ve Google y comprobar que ni robots.txt, ni un noindex, ni un inicio de sesión le cierran el paso.⁠^{[8]Google Search Central. Merchant listing (Product, Offer) structured data}

Llevado a una tienda:

1. Valida antes de publicar, con el validador de schema para el vocabulario y la Prueba de resultados enriquecidos para los requisitos de Google.⁠^{[2]Google Search Central. Schema Markup Testing Tool}
2. Publica y prueba la URL, no el código, para que la prueba lea lo que sirve tu tienda.⁠^{[10]Google Search Central. Generate structured data with JavaScript}
3. Compara los valores a mano. Abre la página publicada, busca en el HTML el nombre, el precio y la disponibilidad del marcado, y compáralos con lo que enseña la ficha y con lo que guardaste. Esa comparación no la hace ninguna herramienta automática por ti.⁠^{[4]Google Search Central. General structured data guidelines}
4. Mira la página como Google, con la prueba en directo de la inspección de URLs.⁠^{[3]Ayuda de Search Console. URL Inspection tool}
5. Repite la verificación después de cada cambio de tema, de aplicación o de precio. Lo que se tuerce con el tiempo, sin que nadie toque la ficha, tiene nombre propio: deriva de datos.

Para hacerlo en una ficha concreta, la guía para auditar los datos estructurados de una ficha lo recorre paso a paso.

Elige por dónde empezar

No eliges entre validar y verificar: eliges cuál te falta.

• Valida primero si vas a cambiar la plantilla de producto, instalar una aplicación que escribe marcado o escribirlo a mano. Un error de sintaxis se arregla antes de que llegue a ninguna ficha.
• Verifica primero si el marcado ya está publicado y algo no cuadra: la prueba sale en verde y Google no enseña el resultado enriquecido, Merchant Center avisa de diferencias entre tus datos y la página, o el precio del marcado no es el de la ficha.
• Haz las dos cada vez que cambies algo que toque la ficha.

Verificar una ficha a mano es asumible; verificar un catálogo entero, cada vez que algo cambia, es otro trabajo. Hay herramientas que hacen esa lectura por ti. Clione, por ejemplo, lee la ficha publicada, informa señal por señal de lo que se renderizó frente a lo que se envió, la vuelve a comprobar con regularidad y te avisa cuando una señal verificada desaparece de la página.

Para seguir, la ruta de lectura de medición y verificación ordena los términos de esta comparativa y los que van detrás de ellos.