# Validar el marcado vs verificar la publicación > Validar el marcado vs verificar la publicación: qué comprueba cada una, con qué herramienta y por qué un JSON-LD válido puede no estar en tu ficha. URL: https://clione.ai/es/comparativas/validar-vs-verificar/ Lang: es | Criterio | Validar el marcado | Verificar la publicación | | ------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | La pregunta | ¿Está bien escrito y cumple las reglas? | ¿Está en la página publicada y dice lo mismo que ella? | | Qué lee | El código que le das, o el de una URL en ese momento[^rrt-help] | La página que sirve tu tienda, comparada con lo que guardaste | | Con qué | Un validador de vocabulario y la prueba de Google[^google-test-sd] | El código fuente, la página renderizada y la inspección de URLs[^gsc-url-inspection] | | Qué encuentra | Errores de sintaxis, de vocabulario y propiedades obligatorias ausentes | Un dato que no aparece, que es distinto o que no coincide con lo que se ve | | Qué no ve | Si el marcado describe lo que ve quien lee la página[^google-sd-policies] | Si el marcado está bien escrito: eso es validar | | Cuándo | Antes de publicar, y con cada cambio de plantilla | Después de publicar, y con cada cambio en la tienda | | El resultado | Válido, válido con advertencias o no válido | Coincide, es distinto o no aparece | 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](/es/glosario/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.[^google-sd-intro] ## 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](/es/glosario/schema-org/), lo que en el sector se llama [_schema markup_](/es/glosario/schema-markup/). Lo revisa el [validador de schema](/es/glosario/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.[^sdtt-update] 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.[^schemaorg-datamodel] El segundo son los requisitos de Google, los que deciden si una página opta a los [resultados enriquecidos](/es/glosario/resultados-enriquecidos/). Los revisa la [Prueba de resultados enriquecidos](/es/glosario/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.[^google-test-sd] Un ejemplo de esas reglas: para que una [ficha de producto](/es/glosario/ficha-de-producto/) opte a las [fichas de comerciante](/es/glosario/fichas-de-comerciante/), Google exige un nombre, una imagen y una oferta con un precio mayor que cero y su moneda.[^google-merchant-listing] **Verificar es comprobar la página, no el código.** La [verificación de publicación](/es/glosario/verificacion-de-publicacion/) 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**.[^google-sd-policies] Para sus funciones de IA lo resume en una línea: que los datos estructurados coincidan con el texto visible de la página.[^google-ai-features] ## 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.[^rrt-help] 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`](/es/glosario/robots-txt/) la bloquea o la página no es pública, no se puede probar.[^rrt-help] 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.[^google-js-sd] 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.[^google-sd-policies] La herramienta que más se acerca a la verificación es la inspección de URLs de [Search Console](/es/glosario/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.[^gsc-url-inspection] 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.[^gsc-url-inspection] ## Dónde se pierde un marcado válido Un bloque de [JSON-LD](/es/glosario/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_](/es/glosario/app-embed-shopify/)) 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 `` o de ``.[^shopify-app-embeds] - **El JavaScript.** Google procesa los datos estructurados que están en el DOM cuando renderiza la página,[^google-js-sd] y usa el HTML renderizado para indexarla, pero puede saltarse el [renderizado de JavaScript](/es/glosario/renderizado-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](/es/glosario/ssr/) o el prerrenderizado.[^google-js-seo] - **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.[^google-merchant-listing] - **El acceso.** Google pide no bloquear a [Googlebot](/es/glosario/googlebot/) las páginas con datos estructurados, ni con `robots.txt`, ni con `noindex`, ni con ningún otro control de acceso.[^google-sd-policies] - **La caché y el marcado desactualizado.** [Google Merchant Center](/es/glosario/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é.[^mc-availability-mismatch] 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.[^google-sd-policies] 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.[^mc-availability-mismatch] **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,[^gsc-rich-reports] y una ficha cuyo marcado no lleva imagen no opta a las fichas de comerciante aunque la foto se vea en la página.[^google-merchant-listing] 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.[^gsc-rich-reports] **Una prueba en verde con el código pegado no dice que tu ficha lleve ese marcado.** En el modo de fragmento, la prueba valida lo que has pegado, no lo que sirve tu tienda.[^rrt-help] Y al revés: ver el bloque en el código fuente de la ficha no dice que sea válido ni que sus valores sean los de la página. Son dos preguntas, y cada herramienta contesta la suya. ## 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**.[^google-sd-intro] 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.[^google-merchant-listing] 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.[^google-test-sd] 2. **Publica y prueba la URL, no el código**, para que la prueba lea lo que sirve tu tienda.[^google-js-sd] 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.[^google-sd-policies] 4. **Mira la página como Google**, con la prueba en directo de la inspección de URLs.[^gsc-url-inspection] 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](/es/glosario/deriva-de-datos/). Para hacerlo en una ficha concreta, la guía para [auditar los datos estructurados de una ficha](/es/guias/auditar-ficha-de-producto/) 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](/es/aprender/medicion-y-verificacion/) ordena los términos de esta comparativa y los que van detrás de ellos.