¿Qué datos estructurados publican las tiendas online españolas en sus fichas de producto?

Una tienda online que vende en España tiene dos lectores en cada ficha de producto: el comprador, que mira la foto, el precio y las opiniones, y el programa que lee la página para entender qué vende, a qué precio y si está disponible. Al segundo le hablan los datos estructurados: un bloque que describe el producto en un formato fijo, casi siempre JSON-LD con el vocabulario de Schema.org. La pregunta de este estudio es sencilla y las cifras públicas no la contestan con datos españoles: ¿qué datos estructurados publican de verdad las fichas de producto de las tiendas que venden en España, y cuántos de ellos son correctos?

Correcto quiere decir cuatro cosas a la vez: que el marcado esté, que diga lo que necesita decir, que llegue a quien lee la página aunque no ejecute JavaScript y que coincida con lo que ve el comprador. Medimos las cuatro, ficha a ficha. Y publicamos también lo que salió bien, porque un estudio que solo cuenta fallos exagera el problema.

Por qué importa a una tienda española

Comprar por internet ya es lo normal en España: el 59,6 % de las personas de 16 a 74 años compró en la red en los tres últimos meses, según la encuesta del INE de 2025, y el 37,9 % usó en ese mismo periodo alguna herramienta de inteligencia artificial generativa.⁠^{[1]Instituto Nacional de Estadística. Encuesta sobre Equipamiento y Uso de Tecnologías de Información y Comunicación en los Hogares. Año 2025}

En Google, lo que una máquina puede leer de una ficha tiene reglas escritas. Para que una página aparezca en las fichas de comerciante, las experiencias de Google para páginas que venden un producto, el marcado de Product necesita tres propiedades obligatorias, el nombre, la imagen y una oferta, y la oferta necesita un precio y su moneda.⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data} Solo son aptas las páginas en las que el comprador puede comprar el producto, no las que enlazan a otra tienda que lo vende.⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data} Una página que habla de un producto sin venderlo, una reseña por ejemplo, puede optar a un fragmento de producto, y le basta el nombre más una reseña, una valoración media o una oferta.⁠^{[3]Google Search Central. Product snippet (Product, Review, Offer) structured data}

Lo demás es recomendado: el GTIN y los demás identificadores globales, el MPN, la marca y la valoración media (AggregateRating).⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data} Recomendado no significa decorativo. Según GS1 Spain, el GTIN de 13 dígitos identifica las unidades destinadas al punto de venta, y solo se puede generar a partir de un prefijo de empresa de GS1:⁠^{[4]GS1 Spain. GTIN} es la forma más corta de decir, sin ambigüedad, qué producto exacto es este.

Y hay una regla que pesa más que todas las anteriores: los datos estructurados tienen que ser una representación fiel del contenido de la página, y no se marca contenido que los lectores de la página no ven.⁠^{[5]Google Search Central. General structured data guidelines} Un precio en el marcado que no coincide con el de la ficha no es un detalle técnico: es la página contradiciéndose.

Lo que ya se sabe, y por qué no basta

Hay cifras públicas sobre datos estructurados, y son buenas. El Web Almanac de HTTP Archive analiza cada año millones de sitios web: la edición de 2025 parte de 16.213.084 sitios, tomados del Chrome UX Report y rastreados en julio de 2025.⁠^{[6]HTTP Archive. Web Almanac 2025: Methodology} Su capítulo de SEO cuenta que el 50 % de las páginas de inicio llevaba datos estructurados en 2025, en escritorio y en móvil, y que el 43 % llevaba JSON-LD; entre las páginas interiores, llevaba JSON-LD el 39 % en escritorio y el 37 % en móvil.⁠^{[7]HTTP Archive. Web Almanac 2025: SEO} El mismo capítulo dice que la mayoría de los sitios entrega los datos estructurados en el HTML inicial y que solo en el 2 % de los rastreos los añadía JavaScript.⁠^{[7]HTTP Archive. Web Almanac 2025: SEO}

El capítulo de datos estructurados de 2024 da la medida de un tipo concreto: Product aparecía en JSON-LD en el 0,77 % de las páginas analizadas.⁠^{[8]HTTP Archive. Web Almanac 2024: Structured Data} La base es toda la web, con sus blogs, sus periódicos y sus páginas de empresa, así que la cifra no dice qué parte de las fichas de producto lleva Product.

Tampoco se puede trasladar a España la foto mundial de las plataformas de comercio electrónico. El propio Web Almanac explica que la plataforma que domina cambia de una región a otra, por el idioma, los medios de pago locales, el ecosistema de agencias y la historia de cada proveedor.⁠^{[9]HTTP Archive. Web Almanac 2025: Ecommerce} Y la plataforma y su tema pueden decidir buena parte del marcado de una ficha, como muestra en Shopify y BigCommerce el estudio Del dato guardado al dato publicado. Por eso este estudio lee tiendas españolas y anota la plataforma de cada una.

Cómo lo medimos

Los datos salen del Corpus, el rastreo de tiendas online del equipo que publica esta biblioteca. Ese mismo equipo construye una herramienta que lee los datos estructurados de las tiendas, así que el método está escrito para que cualquiera pueda repetirlo con herramientas públicas: una petición HTTP, un navegador sin interfaz y un analizador de JSON.

La muestra

Una tienda entra en la muestra si vende a compradores en España: precios en euros, envío a España y una versión en español de la ficha. Dentro de ese marco, la muestra se reparte por sector y por plataforma, para que ningún sector ni ninguna plataforma decida solo el resultado. La plataforma de cada tienda se anota tal como la delatan su HTML y sus cabeceras, y la que no se puede identificar se anota como desconocida, no se adivina.

En cada tienda leemos un número fijo de fichas de producto, elegidas al azar entre las URL de producto de su sitemap XML. Una tienda con menos fichas que ese número entra con todas las que tiene. Solo fichas: las páginas de categoría y de inicio quedan fuera, porque son otra pregunta.

Las dos lecturas de cada ficha

1. El HTML sin JavaScript. Una petición GET, sin ejecutar nada: lo que recibe un rastreador que no renderiza. Se guardan el código de estado, la URL final, las cabeceras y el cuerpo.
2. El DOM renderizado. La misma URL en un Chromium sin interfaz, que carga la página y ejecuta su JavaScript, como hace Google en su fase de renderizado.⁠^{[10]Google Search Central. Understand JavaScript SEO basics} Se guardan el DOM, el texto visible y cada bloque application/ld+json.

Comparar las dos lecturas dice de dónde viene el marcado: si ya estaba en el HTML que envía el servidor, el renderizado del lado del servidor, o si solo aparece después del renderizado de JavaScript. La diferencia importa porque Google puede leer un JSON-LD que inyecta un script,⁠^{[11]Google Search Central. Introduction to structured data markup in Google Search} pero avisa de que el marcado de producto generado dinámicamente puede hacer los rastreos de Shopping menos frecuentes y menos fiables, un problema para el precio y la disponibilidad,⁠^{[12]Google Search Central. Generate structured data with JavaScript} y porque no todos los bots pueden ejecutar JavaScript.⁠^{[10]Google Search Central. Understand JavaScript SEO basics} Qué hace cada rastreador de IA con el JavaScript lo cuenta la guía Qué ve un rastreador de IA en tu tienda.

Qué medimos en cada ficha

• Formato. Si hay JSON-LD, microdatos o RDFa, y cuántos bloques de cada uno. Google admite los tres y recomienda JSON-LD, el más fácil de mantener a escala.⁠^{[11]Google Search Central. Introduction to structured data markup in Google Search}
• Product. Si hay un nodo Product y con qué propiedades: nombre, imagen, descripción, marca y oferta. Schema.org define Product como cualquier producto o servicio que se ofrece.⁠^{[13]Schema.org. Product}
• Offer. Si la oferta da precio, moneda y disponibilidad, las tres propiedades con las que Schema.org la describe.⁠^{[14]Schema.org. Offer} En una tienda española, la moneda esperada es el euro.
• AggregateRating. Si el producto declara una valoración media, con su valor y con el número de valoraciones o de reseñas que la sostienen.⁠^{[15]Schema.org. AggregateRating}
• Identificadores. Si hay GTIN en cualquiera de sus formas y MPN.⁠^{[13]Schema.org. Product} Un GTIN se comprueba además por dentro: su último dígito es un dígito de control que se calcula con los anteriores y sirve para detectar errores.⁠^{[16]GS1 Spain. Cálculo de dígito de control GTIN} Un GTIN con el dígito equivocado no es un GTIN válido.
• Validez. Si cada bloque se puede analizar: un documento JSON-LD es siempre un documento JSON válido,⁠^{[17]W3C. JSON-LD 1.1} y un bloque con un error de sintaxis no le dice nada a nadie. Y si el Product tiene las propiedades que Google exige para una ficha de comerciante.⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data}
• Coherencia con la página. Si el precio, la disponibilidad, el nombre y la valoración del marcado son los que ve el comprador en el texto de la ficha.⁠^{[5]Google Search Central. General structured data guidelines} Y si hay dos o más nodos Product para el mismo producto y, en ese caso, si coinciden o se contradicen.

Antes de comparar, cada valor se normaliza igual en el marcado y en la página: espacios agrupados, entidades HTML decodificadas y el precio como número más moneda, para que un precio escrito en la ficha con coma decimal y el símbolo del euro y el mismo número escrito en el marcado con punto decimal y EUR cuenten como el mismo precio.

Cómo clasificamos cada ficha

• Sin marcado: ningún dato estructurado.
• Marcado sin Product: hay datos estructurados, pero ninguno describe el producto.
• Product incompleto: falta alguna propiedad obligatoria para una ficha de comerciante.
• Product completo: tiene nombre, imagen y una oferta con precio y moneda.
• Solo con JavaScript: el Product falta en el HTML y está en el DOM renderizado.
• Inválido: el bloque no se puede analizar como JSON.
• Incoherente: el marcado da un precio, una disponibilidad o una valoración distintos de los visibles.
• Duplicado en conflicto: dos nodos Product dan valores distintos para la misma propiedad.

Una ficha puede estar en más de una clase: un Product completo puede ser, a la vez, solo con JavaScript e incoherente.

Resultados

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

Hay cosas que este método no mide desde el principio:

• Si Google muestra la ficha con resultados enriquecidos. Leer el marcado dice si la ficha es apta, no si Google la mostrará así: los datos estructurados no lo garantizan.⁠^{[11]Google Search Central. Introduction to structured data markup in Google Search}
• Si una IA cita la tienda. Google dice que los datos estructurados no son un requisito para sus funciones de IA generativa y que no hay ningún marcado especial que añadir para ellas.⁠^{[18]Google Search Central. Optimizing your website for generative AI features on Google Search} Este estudio mide lo que la ficha publica, no lo que un asistente hace con ello.
• Lo que lee cada bot. Leemos el HTML con el user agent del rastreo, no con el de cada empresa, y una tienda puede servir otra cosa a otro nombre.
• El resto de la tienda. Categorías, inicio y páginas de contenido quedan fuera.

Qué significa

Hasta que haya resultados, este es el marco para leerlos, regla por regla, con lo que dice la fuente de cada una:

• Una ficha sin Product, o sin oferta con precio y moneda, no es apta para las fichas de comerciante de Google. Son las propiedades obligatorias.⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data}
• Una ficha sin GTIN sigue siendo apta. El GTIN es recomendado, no obligatorio,⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data} y lo que pierde la ficha es la forma inequívoca de decir qué producto vende.
• Un Product que solo existe con JavaScript llega a Google con más riesgo y a algunos bots, no llega. Google avisa de rastreos de Shopping menos frecuentes y menos fiables,⁠^{[12]Google Search Central. Generate structured data with JavaScript} y un bot que no ejecuta JavaScript no lo ve.⁠^{[10]Google Search Central. Understand JavaScript SEO basics}
• Un marcado que contradice la página es el defecto más serio de la lista. Incumple la regla de representar fielmente el contenido,⁠^{[5]Google Search Central. General structured data guidelines} y es el único de la lista que da a quien lee el marcado un dato falso.

Para comprobar todo esto en tu propia ficha, la diferencia entre que el marcado sea válido y que esté publicado la explica la comparativa Validar el marcado vs verificar la publicación, y la herramienta de Google para hacerlo es la Prueba de resultados enriquecidos, con la URL y no con el código, como recomienda Google para el marcado que genera JavaScript.⁠^{[12]Google Search Central. Generate structured data with JavaScript}

Límites

• Una muestra, no un censo. Los porcentajes valen para las fichas y las tiendas medidas, con su reparto por sector y plataforma, no para todo el comercio electrónico español.
• Un rastreo, un momento. Una ficha que hoy está bien puede cambiar mañana con un tema nuevo, una app o una sincronización: es la deriva de datos.
• La lista de partida decide. Las tiendas que no están en la lista de candidatas no pueden entrar en la muestra, y esa lista tiene sus propios sesgos.
• La coherencia se mide con extracción automática. Leer a máquina el precio visible de una ficha puede equivocarse, por ejemplo con descuentos o variantes, así que una submuestra se revisa a mano.
• Leer no es probar. El estudio no cambia nada en ninguna tienda, así que no puede demostrar por qué una ficha está como está; solo puede describirlo.

Los datos

Cada ficha leída es una fila del conjunto de datos, con estas columnas: run_id, datetime_utc, store_id, platform, sector, url, http_status, formats, jsonld_blocks, has_product, product_props, has_offer, price, price_currency, availability, has_aggregaterating, rating_value, rating_count, gtin, gtin_check_ok, mpn, brand, in_raw_html, in_rendered_dom, parse_errors, visible_price, visible_availability, visible_rating, consistent, product_nodes, conflict, classes y notes. Las tiendas se publican con un código, no con su nombre.

El resto de conceptos para describir tu catálogo a una máquina está ordenado en la ruta de lectura de datos estructurados.