¿Lo que guardas en el admin de tu tienda llega a la página publicada?

Guardas un dato en el admin de tu tienda (un metafield, un custom field, una pregunta frecuente, una descripción nueva) y la plataforma te confirma el cambio. Luego no lo ves en Google, ni en una respuesta de IA, ni en la herramienta de Google que comprueba los resultados enriquecidos. La confirmación hablaba del admin, no de la página. Un valor guardado todavía no es un valor publicado: entre los dos están el tema, las apps, el JavaScript, la caché y el tiempo, y cualquiera de ellos puede dejarlo fuera de lo que recibe quien pide la página.

Y la página no tiene un solo lector. La misma URL puede existir en cuatro versiones: la que construye el navegador de un comprador, la que renderiza Google antes de indexarla, la que recibe un rastreador que lee el HTML sin ejecutar JavaScript y la copia que Google guardó la última vez que pasó por ella. Medimos qué campos guardados llegan a cada una de esas versiones en tiendas Shopify y BigCommerce, dónde se pierden los que no llegan y por qué. Y publicamos también lo que sí llegó, porque un fallo que no aparece también es un resultado.

Por qué un dato guardado puede no publicarse

Antes de medir, el mecanismo. Cada una de estas siete vías está documentada por la plataforma o por el estándar que la gobierna; ninguna es todavía una estadística.

El tema no pinta el campo

En Shopify, un metafield no aparece solo en la tienda. Se muestra donde el tema lo referencia: conectado como fuente dinámica a una sección o a un bloque del editor de temas, o escrito en el código de la plantilla.⁠^{[1]Shopify Help Center. Displaying metafields on your online store} En Liquid, el lenguaje de los temas de Shopify, esa referencia tiene la forma {{ product.metafields.namespace.key }}, y .value devuelve su contenido.⁠^{[2]Shopify.dev. Liquid objects: metafield} Un metafield que nadie ha conectado está guardado y no está publicado.

Hay un ajuste que suele cargar con la culpa: el acceso «Storefronts» de la definición del metafield. Shopify explica que ese ajuste controla los permisos de la Storefront API, la que usan las tiendas headless y las personalizadas, y que no afecta a las plantillas Liquid: en Liquid, los metafields son accesibles siempre, con ese ajuste activado o sin él.⁠^{[3]Shopify.dev. About metafields} Si un metafield no sale en la ficha, lo primero es mirar si el tema lo pide.

En BigCommerce hay dos campos que se parecen y no se publican igual. Los custom fields se muestran en la página de producto de la tienda como pares de nombre y valor, y su posición depende del tema.⁠^{[4]BigCommerce Support. Custom Fields} Los metafields, incluso con el permiso que los hace visibles en la tienda, se pueden mostrar en ella a través de la API GraphQL de Storefront.⁠^{[5]BigCommerce Dev Center. Metafields} Esa es la vía que documenta BigCommerce, no el HTML del tema, y por eso tratamos ese metafield como control: si no aparece en el HTML, es lo esperado.

Una app instalada con su app embed apagado

Muchas apps de Shopify añaden su código a la tienda con un app embed: un bloque que Shopify renderiza e inyecta antes del cierre de </head> o de </body>. Después de instalar la app, esos bloques están desactivados por defecto. Se activan desde el editor de temas, en la configuración del tema, o con un enlace directo que ofrezca la propia app.⁠^{[6]Shopify.dev. Configure theme app extensions} Una app de preguntas frecuentes o de marcado puede estar instalada y configurada sin haber escrito una sola línea en la página.

Dos fuentes describen el mismo producto

Un tema de Shopify puede generar su propio JSON-LD con el filtro structured_data de Liquid, que convierte el producto en un Product de schema.org, o en un ProductGroup si tiene variantes, dentro de una etiqueta <script type="application/ld+json">.⁠^{[7]Shopify.dev. Liquid filters: structured_data} Si una app de reseñas o de SEO añade otro bloque, la página describe el mismo producto dos veces.

Eso, por sí solo, no es un error. Google acepta varios elementos de datos estructurados en una página, anidados unos dentro de otros o en bloques separados, y explica que los bloques separados se pueden relacionar con el identificador @id.⁠^{[8]Google Search Central. General structured data guidelines} En JSON-LD, @id sirve para identificar de forma única cada nodo que describe el documento.⁠^{[9]W3C. JSON-LD 1.1} Lo que convierte la duplicación en un defecto es el conflicto: dos valores distintos para la misma propiedad del mismo producto, por ejemplo un precio en el bloque del tema y otro en el de la app. Por eso separamos el duplicado coherente del duplicado en conflicto, y el primero no cuenta como fallo.

Solo existe después de ejecutar JavaScript

Google procesa una página en tres fases, rastreo, renderizado e indexación, y en la segunda un Chromium sin interfaz (headless) ejecuta el JavaScript de la página.⁠^{[10]Google Search Central. Understand JavaScript SEO basics} Gracias a ese renderizado de JavaScript, un dato que un script añade después de cargar la página puede llegar al índice de Google. Pero la misma documentación recuerda que no todos los bots pueden ejecutar JavaScript.⁠^{[10]Google Search Central. Understand JavaScript SEO basics} Y para el marcado de producto añade otro aviso: el marcado generado dinámicamente puede hacer que los rastreos de Shopping sean menos frecuentes y menos fiables, un problema para datos que cambian rápido, como el precio y la disponibilidad.⁠^{[11]Google Search Central. Generate structured data with JavaScript} Un valor inyectado con JavaScript puede existir para un lector y no para otro.

Una copia guardada en caché

Entre el servidor de la tienda y quien pide la página puede haber una caché. Mientras una respuesta guardada está fresca, la caché puede servirla sin consultar al servidor de origen, y la cabecera Age indica cuántos segundos han pasado desde que esa respuesta se generó o se validó en el origen.⁠^{[12]IETF. RFC 9111: HTTP Caching} Por eso un cambio recién guardado puede tardar en verse. Aquí no damos tiempos de caché de ninguna plataforma: el método los observa en las cabeceras y en lo que tarda cada valor en converger, y los publica como medidos, no como regla.

Correcto hoy, distinto mañana

Un campo que se publicó bien puede cambiar después sin que nadie lo edite a mano: una sincronización desde el PIM, la actualización de una app o un cambio de tema. Es la deriva de datos y, cuando un sistema pisa lo que escribió otro, la sobrescritura de campos. Una medición hecha un día dice cómo estaba la página ese día. Comprobar la página publicada es un trabajo que se repite, no una casilla que se marca una vez.

Marcado que la página no muestra

Google lo dice sin rodeos: no marques contenido que no ven los lectores de la página; si el JSON-LD describe algo, el cuerpo de la página tiene que describir lo mismo.⁠^{[8]Google Search Central. General structured data guidelines} Una app puede declarar en el marcado una respuesta, una valoración o un precio que el comprador no encuentra en la página. Lo registramos como clase propia, «En el marcado, no visible», porque el dato sí se ha publicado, pero solo para las máquinas.

Cómo lo medimos

Quien ejecuta este estudio forma parte de un equipo que también construye una herramienta que comprueba páginas publicadas. Por eso esa herramienta no interviene en ninguna medición: todas salen de peticiones HTTP, de un navegador sin interfaz y de las herramientas públicas de Google, y el método está escrito para que cualquiera pueda repetirlo.

La muestra

Dos plataformas, Shopify y BigCommerce, y dos clases de tienda:

• Tiendas de prueba, una por plataforma, montadas para el estudio. En Shopify, con un plan de pago: Shopify anunció en 2020 que las tiendas de desarrollo nuevas están protegidas con contraseña y que un partner no puede quitarla salvo que transfiera la tienda a un comerciante o elija un plan.⁠^{[13]Shopify Changelog. Important changes to new development stores} Y la Prueba de resultados enriquecidos necesita que todos los recursos de la página sean accesibles para un usuario anónimo desde internet.⁠^{[14]Ayuda de Search Console. Rich Results Test} Una tienda de desarrollo solo podría medirse en las dos primeras capas, y se diría. Los temas: en Shopify, el tema de referencia de Shopify en su versión vigente y un tema que use algún cliente; en BigCommerce, Cornerstone, un tema Stencil, y otro tema. Nombre y versión de cada uno se anotan el día de la ejecución.
• Tiendas autorizadas, hasta tres por plataforma, de clientes que dan permiso por escrito, tienda por tienda, para leer sus páginas. Se nombran o se anonimizan según ese permiso. Solo lectura: en ellas no se cambia nada.

En cada tienda leemos tres fichas de producto: una simple, una con variantes y, si la tienda tiene alguna, una con una app de reseñas o de preguntas frecuentes activa. Opcionalmente, una página de colección o de categoría.

Qué guardamos

En Shopify: la descripción del producto, el meta title y la meta description, un metafield conectado como fuente dinámica, otro referenciado en Liquid, el JSON-LD del tema con sus propiedades de producto (nombre, descripción, precio, disponibilidad, marca y GTIN, todas de Product y de su oferta en schema.org),⁠^{[15]Schema.org. Product} el JSON-LD de una app a través de su app embed, primero apagado y luego encendido, y las preguntas frecuentes con su FAQPage, si una app las aporta.

En BigCommerce: la descripción, el título de página y la meta description, un custom field, el contenido de un widget de BigCommerce colocado en una región del tema, que según BigCommerce se renderiza como parte del HTML de la tienda,⁠^{[16]BigCommerce Dev Center. Widgets} un bloque JSON-LD inyectado por un script, los datos estructurados del tema si los tiene, y el GTIN, el UPC y el MPN.

Cada plataforma lleva un control: un campo guardado que no está conectado a nada y que, por tanto, no debe aparecer. En Shopify, un metafield sin conectar; en BigCommerce, un metafield con permiso de lectura en la tienda (read_and_sf_access).⁠^{[5]BigCommerce Dev Center. Metafields} Un control ausente es «ausente por diseño» y nunca cuenta como fallo. La tabla de resultados lista cada campo con la vía por la que debía llegar a la página.

Qué cuenta como guardado

El momento cero de cada campo queda registrado tres veces: una captura del admin, una lectura por API guardada como JSON con su fecha de actualización (la Admin GraphQL API en Shopify, la API REST del catálogo en BigCommerce) y la hora en UTC. En las tiendas de prueba, cada valor lleva una cadena única que lo identifica en cualquier capa sin confundirlo con otro texto de la página.

Las cuatro capas que leemos

1. HTML sin JavaScript. Una petición GET, sin ejecutar nada, repetida con tres identidades: el user agent de un navegador de escritorio, el de Googlebot para smartphone y el de OAI-SearchBot. Cambiar el user agent registra lo que el servidor envía a quien se presenta con ese nombre, no lo que hace ese bot de verdad. Se guardan el código de estado, la URL final, las cabeceras (cache-control, age, cache-status) y el cuerpo.
2. DOM renderizado. Un Chromium sin interfaz, con Playwright: carga la página, espera a que la red quede en reposo y una espera fija más. Se serializa el DOM y se extraen el texto visible y todos los bloques application/ld+json.
3. Prueba de resultados enriquecidos, con el agente para smartphone, el que la herramienta usa por defecto: elementos detectados, errores, advertencias y una captura.⁠^{[14]Ayuda de Search Console. Rich Results Test} Google avisa de que no garantiza que la página aparezca como en la vista previa.⁠^{[14]Ayuda de Search Console. Rich Results Test} El resultado enriquecido de preguntas frecuentes no aparece en la Búsqueda de Google desde el 7 de mayo de 2026,⁠^{[17]Google Search Central. Latest documentation updates} así que FAQPage, y cualquier tipo que la prueba no reconozca, se valida con el validador de schema sobre el HTML de las capas 1 y 2.
4. Inspección de URL de Search Console, solo donde tenemos acceso a la propiedad, porque la herramienta solo inspecciona URL de la propiedad abierta.⁠^{[18]Ayuda de Search Console. URL Inspection tool} Leemos la prueba en directo y la versión indexada, que es la más reciente que Google ha indexado, no la que está en vivo, con la fecha de su último rastreo. Su vista de página rastreada da el HTML devuelto y las cabeceras; la captura de la página renderizada solo existe en la prueba en directo.⁠^{[18]Ayuda de Search Console. URL Inspection tool}

Cuándo leemos

Las capas 1 y 2, al minuto, a los 15 minutos, a la hora y a las 24 horas de guardar. Las capas 3 y 4 en directo, a la hora. La versión indexada, cuando Google vuelva a rastrear la URL; si no lo hace dentro de la semana, se dice así. Una lectura a los siete días, opcional.

Cómo comparamos

Antes de comparar, cada valor se normaliza igual en las dos puntas: espacios agrupados, entidades HTML decodificadas, Unicode en forma NFC y el precio como número más moneda. Si una capa recorta el texto, se anota dónde.

Cómo clasificamos cada lectura

• Coincide: el valor guardado está en la capa, igual.
• Ausente: no está.
• Alterado: está, pero recortado, escapado o con un valor anterior.
• Solo con JavaScript: falta en el HTML sin JavaScript y está en el DOM renderizado.
• En caché: primero sale el valor anterior y después converge; se anota cuánto tardó.
• Duplicado coherente: dos o más nodos describen lo mismo con los mismos valores.
• Duplicado en conflicto: dos nodos dan valores distintos para la misma propiedad.
• En el marcado, no visible: está en el JSON-LD y no en el texto que ve el comprador.
• Ausente por diseño: los controles.

Cómo atribuimos la causa

En las tiendas de prueba, la causa se demuestra: se cambia una sola cosa y se vuelve a leer. En las tiendas autorizadas, donde no se toca nada, se infiere, y la tabla la marca como inferida.

Resultados

Lo que no falló y lo que quedó sin medir

Un estudio que solo publica fallos exagera el problema. Lo que salió bien, las hipótesis que no se cumplieron y lo que los instrumentos no dejaron ver pesan aquí lo mismo que los resultados.

Hay cosas que este método no mide desde el principio, y conviene decirlas antes de los resultados:

• Si una página gana un resultado enriquecido. La prueba de Google dice si detecta el marcado, no si la página lo mostrará en la Búsqueda,⁠^{[14]Ayuda de Search Console. Rich Results Test} y el de preguntas frecuentes ya no se muestra.⁠^{[17]Google Search Central. Latest documentation updates}
• Lo que hace un bot de verdad. Leer con el user agent de Googlebot o de OAI-SearchBot registra lo que el servidor entrega a ese nombre, no cómo procesa la página cada empresa.
• La versión indexada de las tiendas sin acceso. Sin la propiedad en Search Console no hay Inspección de URL.⁠^{[18]Ayuda de Search Console. URL Inspection tool}

Qué significa

Cada capa responde a una pregunta distinta, y ninguna responde a todas. Este es el marco para leer los resultados:

Una prueba que pasa no demuestra que el dato esté publicado: valida el marcado que la herramienta encontró en ese momento, y la versión indexada puede ser distinta de la que hay en vivo.⁠^{[18]Ayuda de Search Console. URL Inspection tool} La diferencia entre las dos comprobaciones la desarrolla la comparativa Validar el marcado vs verificar la publicación, y el concepto, la entrada del glosario sobre la verificación de publicación.

Para hacer la comprobación en tu tienda, paso a paso, tienes dos guías: Del metafield a la página publicada (Shopify) y Del widget a la página publicada (BigCommerce). Para leer tus fichas como las lee un bot, Qué ve un rastreador de IA en tu tienda.

Límites

• Pocas tiendas, temas y apps elegidos. Los resultados valen para las tiendas que medimos, no para «las tiendas Shopify» ni para «las tiendas BigCommerce». No hay aquí ninguna afirmación de frecuencia.
• Una semana y un juego de versiones. Un tema o una app que se actualice al mes siguiente puede comportarse de otra manera.
• Cambiar el user agent no es el comportamiento de un bot. Dice qué entrega el servidor a ese nombre.
• La Prueba de resultados enriquecidos y la Inspección de URL solo hablan de Google. Otros motores pueden leer la página de otra manera.
• No controlamos cuándo vuelve a rastrear Google. Una versión indexada antigua es un dato, no un fallo de la tienda.
• Las tiendas de prueba no tienen tráfico real, y eso puede cambiar cómo se comportan sus cachés.
• Las tiendas autorizadas se seleccionan solas: son clientes que aceptan que leamos sus páginas, y entre ellos pesa más BigCommerce.

Los datos

Cada lectura es una fila del conjunto de datos, con estas columnas: run_id, datetime_utc, operator, platform, store_kind, store_id, theme_name, theme_version, relevant_apps, url, page_type, field, saved_where, saved_value_or_hash, saved_at_utc, render_route, layer, user_agent, http_status, cache_headers, found, found_value, node_count, conflict, class, time_to_converge, cause, cause_basis, evidence_file y notes. En las tiendas autorizadas que se anonimicen, store_id es un código y el valor guardado se publica como hash.

El resto de conceptos para medir lo que publicas está ordenado en la ruta de lectura de medición y verificación.