Schema de producto para e-commerce: qué necesita Google y qué olvidan la mayoría de las tiendas

El schema de producto es el bloque oculto de datos estructurados de una página de producto que les dice a las máquinas qué vende esa página: el nombre, el precio, el stock, el código de barras, la marca. Google lo lee para sus resultados de producto, Merchant Center compara tu feed con él y los agentes de compra con IA lo leen cuando visitan tu página. Los compradores nunca lo ven, y precisamente por eso falla sin que nadie se dé cuenta.

Para ver qué ponen de verdad las tiendas, descargué 2.629 páginas de producto de tiendas Shopify consolidadas de seis categorías y leí el marcado del HTML que envía cada página. 182 no tenían schema de producto en JSON-LD, el formato que recomienda Google: 108 no tenían ningún bloque de producto, 36 solo tenían un bloque que no era JSON válido y 38, todas de tres tiendas, usaban en su lugar el formato antiguo de microdatos. Las cifras de abajo corresponden a las 2.447 páginas de 103 tiendas que sí lo tenían. La versión corta: los temas aciertan con lo básico en casi todas las páginas. Los campos que faltan son justo los que hacen que un producto pueda optar a resultados enriquecidos y los que permiten a Google relacionarlo con el mismo producto en otros sitios. Las reglas de Google se aplican a todas las plataformas. Uso Shopify para explicar las correcciones paso a paso, porque es de donde salen mis datos.

¿Qué es el schema de producto y qué exige Google?

El schema de producto son datos estructurados, normalmente escritos en JSON-LD dentro de una etiqueta script del HTML de la página, que describen el producto con el vocabulario de schema.org. Google lo usa para dos tipos de resultados. Los fragmentos de producto son para páginas en las que el comprador no puede comprar el producto directamente, como las páginas de reseñas, y necesitan una valoración, una reseña o una oferta. Las fichas de comerciante son para páginas en las que el comprador sí puede comprarlo, es decir, la página de producto de cualquier tienda.

Para una ficha de comerciante, Google exige:

• name, image y offers en el Product.
• price y priceCurrency en el Offer.

Todo lo demás es recomendado: disponibilidad, marca, descripción, GTIN, MPN, SKU, estado, color, talla, material, valoraciones, reseñas, datos de envío y política de devoluciones. En la práctica, «recomendado» no significa opcional. Son los campos que permiten a Google relacionar tu producto con el mismo producto en otros sitios, mostrar los costes de envío y los plazos de devolución en los resultados y confiar en que la página y tu feed dicen lo mismo. Google lo dice claramente: proporcionar tanto datos estructurados en tus páginas como un feed de Merchant Center maximiza tus posibilidades de aparecer.

Esto es lo que incluían las 2.447 páginas:

Lo que los temas de Shopify ya hacen bien

Los campos obligatorios y los primeros recomendados están en casi todas las páginas. El nombre, la imagen, el precio, la moneda y la disponibilidad aparecían en el 99% de las páginas, y la marca también en el 99%, aunque en Shopify la marca suele ser el campo de proveedor del producto, así que comprueba que tu proveedor sea realmente la marca. En al menos 8 de las tiendas contenía cosas como una temporada, una línea de producto o un texto de relleno. Que un campo esté tampoco significa que diga mucho: el nombre es lo que diga el título de tu producto, y en mi estudio de 1.000 tiendas Shopify, 1 de cada 7 títulos no decía qué era el producto.

En Shopify, algunos temas crean el bloque con el filtro structured_data propio de Shopify, que escribe un Product para un producto sin variantes y un ProductGroup para uno con variantes. En mi muestra, 28 de las 103 tiendas lo usaban, y el resto tenía un marcado escrito por el propio tema o por una app. El 38% de las páginas que leí usaba ProductGroup, y el 40% de los productos con variantes seguían marcados como un único Product.

ProductGroup es la forma en que Google quiere que se describan las variantes de producto: un grupo con un ID de grupo y cada variante como su propio Product dentro de él. De los bloques ProductGroup que encontré, el 84% enumeraba sus variantes y su ID de grupo, pero solo el 36% decía en qué se diferencian las variantes (variesBy, por ejemplo talla o color). Es una propiedad recomendada, y es la que le dice a Google cuál de las variantes es la azul de talla M. El filtro propio de Shopify no la escribe: ninguno de los 381 bloques ProductGroup que generó en mi muestra tenía variesBy. Cuando el marcado lo escribía el tema o una app, el 59% sí la incluía.

Así que, si usas un tema actual de Shopify, probablemente no necesitas crear el schema de producto desde cero. Necesitas completar los huecos del que escribe tu tema, lo que puede implicar un cambio en su código, y asegurarte de que nada más escriba un segundo bloque.

Los campos que omiten la mayoría de las páginas de producto

La moda iba por delante en cuatro de los cinco campos, con un GTIN en más de la mitad de sus páginas y una política de devoluciones en el 24%. Alimentación y bebidas tenía menos GTIN, con un 33%, y hogar menos datos de envío, con un 6%.

GTIN: el código de barras que no llega

Solo el 43% de las páginas incluía un GTIN, y 42 de las 103 tiendas no tenían ninguno en ninguna de las páginas que revisé. En aproximadamente una de cada nueve páginas que sí lo incluían, el valor no era un código de barras real, sino normalmente el SKU. Algunos productos sin GTIN realmente no lo tienen, como las marcas propias y los productos hechos a mano. Pero muchos sí: 36 de las 42 tiendas sin GTIN en su marcado tenían códigos de barras válidos en Shopify en los productos que revisé. Cuando un producto tenía un código de barras válido en Shopify, llegaba al schema solo el 62% de las veces. Los temas que usaban el filtro propio de Shopify lo pasaban casi siempre, en 418 de 419 páginas. En el resto, llegaba en menos de la mitad.

El GTIN es el campo que le permite a Google saber que tu producto es el mismo artículo que venden otras tiendas. También es el campo en el que más se apoya Merchant Center, y expliqué qué pasa cuando falta o es incorrecto en por qué Merchant Center rechaza productos.

Dónde corregirlo. Primero, rellena el código de barras en todas las variantes de tu tienda. Después, comprueba que tu schema lo muestra, como gtin, gtin8, gtin12, gtin13 o gtin14, y que el valor es el propio código de barras, no el SKU. En Shopify, si el código de barras está en la variante pero no en el schema, el tema o la app que escribe el marcado lo está dejando fuera. Busca primero un ajuste en el tema o en la app y, si no lo hay, el desarrollador del tema puede añadir el código de barras de la variante al bloque.

Datos de envío y política de devoluciones

Solo 13 de las 103 tiendas tenían datos de envío en el marcado de alguna de las páginas de producto que revisé, y 18 tenían una política de devoluciones. Solo 3 tenían una política de devoluciones a nivel de tienda en ese marcado. Google sugiere poner la política a nivel de tienda en una sola página, y la configuración de Search Console o Merchant Center no se puede ver desde fuera, así que algunas tiendas pueden haberlo configurado donde yo no podía verlo. Son los campos que hay detrás del coste de envío y del plazo de devolución que Google puede mostrar junto a un producto.

El propio consejo de Google es configurarlos una vez para toda la tienda, no en cada producto. Recomienda una política de devoluciones dentro de tu marcado Organization, con políticas a nivel de oferta solo para los productos que son diferentes, y lo mismo para los envíos. También indica qué prioridad tiene cada fuente. De mayor a menor:

1. Los datos de envío y devolución de tu feed de productos de Merchant Center, y la configuración enviada a Merchant Center a través de su API.
2. La configuración de envío y devolución en Merchant Center o Search Console.
3. El marcado a nivel de producto en la página.
4. El marcado a nivel de tienda.

Así que, si ya configuraste los envíos y las devoluciones en Merchant Center, esos datos ganan y el marcado queda como respaldo. Si no usas Merchant Center, la vía más rápida es la configuración de envíos y devoluciones de Search Console, donde la ofrezca para tu sitio. Si también los quieres en tu marcado, añade una política de devoluciones a nivel de tienda al bloque Organization u OnlineStore que ya escribe tu tema, en una sola página y no en cada producto. Tiene este aspecto:

{
  "@context": "https://schema.org",
  "@type": "OnlineStore",
  "name": "Your Store",
  "url": "https://www.yourstore.com",
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "applicableCountry": "US",
    "returnPolicyCountry": "US",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 30,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn"
  }
}

Google exige el país y el tipo de política, y el número de días cuando el plazo es limitado. En lugar de eso, un enlace a la página de tu política de devoluciones con merchantReturnLink también cumple el requisito.

Valoraciones y reseñas

El 42% de las páginas incluía una valoración (aggregateRating) y solo el 3% incluía reseñas individuales. Alimentación y belleza eran las más altas, con alrededor de la mitad de sus páginas. Es el campo que hay detrás de las estrellas en los resultados de búsqueda. Una advertencia sobre esta cifra: algunas apps de reseñas añaden su marcado con JavaScript después de que cargue la página, y mi recuento solo cubre el HTML que envía la página, así que el porcentaje real de valoraciones puede ser mayor.

Si tus páginas de producto muestran reseñas, comprueba que la app de reseñas también las escribe en el schema. Si la valoración no está en los datos estructurados, las estrellas no pueden aparecer junto a la página en la Búsqueda de Google, por muchas reseñas que muestre la página. Si la app escribe su propio bloque de producto para esto, debería llevar el mismo precio y el mismo stock que el de tu tema.

Estado, MPN y el resto

El estado (itemCondition) aparecía en el 34% de las páginas y el MPN en el 32%. El estado importa sobre todo a las tiendas que venden artículos usados o reacondicionados, y el MPN a los productos sin GTIN, donde la marca más el MPN es la forma en que Google los identifica. El color y la talla aparecían en el 17% de las páginas. En un ProductGroup, son lo que distingue unas variantes de otras.

Los errores que rompen el schema de producto

Los campos que faltan te cuestan posibilidades de aparecer. Algunos errores hacen algo peor: provocan que la página se contradiga a sí misma.

• Dos bloques de producto. El 24% de las páginas con schema de producto tenía más de un bloque, en 32 de las tiendas. Pasa cuando el tema escribe uno y una app escribe otro, a menudo una app de reseñas o de SEO. En 17 páginas, de 4 tiendas, los dos bloques daban precios distintos para la misma variante.
• JSON roto. En 43 páginas de producto, de 6 tiendas, un bloque de datos estructurados ni siquiera era JSON válido, por ejemplo por una coma final o por un código de barras escrito como número con un cero inicial. En 36 de ellas era el único marcado de producto de la página, así que Google no tenía ningún schema de producto que leer.
• Una coma decimal. Una tienda escribía su precio como «69,99». Schema.org pide un punto decimal, así que un analizador puede leer ese precio como 6.999.
• Un valor de stock no válido. Otra escribía su disponibilidad como «schema.org/ InStock», con un espacio en medio, lo que no es un valor válido.
• Datos que no coinciden con la página. El schema dice un precio o un estado de stock y la página dice otro. Este es el que hace que Merchant Center rechace productos.

Dónde corregirlo. El objetivo es un bloque por producto. Si mantienes un segundo bloque porque lleva tus valoraciones con estrellas, asegúrate de que ambos dicen el mismo precio y el mismo stock. Si escribes el marcado a mano, un generador de schema de producto acierta con el formato: el tipo de GTIN correcto según la longitud del código de barras, un punto decimal en el precio y un valor de stock válido. Usa lo que genera para corregir el bloque de tu tema, no para añadir otro: un bloque pegado conserva el precio y el stock que escribiste, así que se queda desfasado en cuanto cambia cualquiera de los dos.

Cómo revisar tu schema de producto

Tres comprobaciones detectan casi todo:

1. La prueba de resultados enriquecidos de Google. Pega la URL de un producto. Te muestra si la página puede optar a fichas de comerciante y fragmentos de producto, qué campos faltan y cuántos elementos de producto ha encontrado. Si muestra el mismo producto dos veces, normalmente la página tiene dos bloques.
2. Search Console. El informe de fichas de comerciante muestra errores y advertencias de una muestra de las páginas de producto que Google ha rastreado, así que ves problemas de plantilla, no solo los de una página.
3. Lo que ve una máquina en la página. El comprobador gratuito de datos de producto muestra lo que lee un comprador automatizado en tu página: los datos estructurados, la descripción, las imágenes y si los rastreadores pueden entrar.

Revisa un producto de cada tipo que vendas: uno con variantes, otro sin ellas y otro en oferta. Los temas y las apps suelen tratar cada caso de forma distinta.

Si tus productos no aparecen en absoluto en Google, el schema rara vez es la causa. Empieza por la indexación; expliqué el orden a seguir en por qué los productos de Shopify no aparecen en Google.

El schema de producto y las compras con IA

Los agentes de compra con IA leen las páginas de producto, y eso hace que el schema parezca la clave para que te recomienden. No es tan sencillo. En mi informe sobre el escaparate de la IA, ChatGPT y Google AI Mode recomendaron productos cuyas páginas no tenían ningún dato estructurado, y todos ellos aparecían en Google Shopping. En ese estudio, el feed era con diferencia la señal más fuerte para entrar en la lista de candidatos.

Donde el schema importa es en lo que pasa después. Un agente que abre tu página y encuentra un precio, un estado de stock y una descripción que coinciden con el feed no tiene motivos para desconfiar. Uno que encuentra dos bloques con precios distintos, o un «agotado» que la página contradice, tiene todos los motivos. Así que trata el schema como la forma en que la página confirma el feed, no como su sustituto. La descripción también cuenta aquí: el 92% de las páginas tenía una en el schema, y es uno de los sitios que lee un agente para entender para qué sirve el producto, así que escribe descripciones que digan qué es realmente un producto.

Cómo revisa BrandyBee el schema de producto

BrandyBee lee los datos estructurados, el código de barras y el stock de cada página de producto, y pone el resultado en la misma lista de correcciones que las incidencias que Google señala en Merchant Center. Escribe un código de barras que falta y BrandyBee comprueba su dígito de control, o elige una categoría o completa los atributos de Shopping. Cuando lo confirmas, se escriben directamente en tu producto de Shopify, y tu feed de Google los recoge en la siguiente sincronización. Puedes ver la lista de correcciones en la página del feed de Merchant Center.

Qué corregir primero

Empieza por lo que hace que la página se contradiga: un segundo bloque de producto con otro precio, JSON roto, un valor de precio o de stock no válido. Después, completa los huecos que te cuestan la identificación y las posibilidades de aparecer: el GTIN siempre que el producto lo tenga, y una política de envíos y devoluciones para toda la tienda en Search Console, Merchant Center o tu marcado. El resto, como el estado, el MPN y variesBy, lo tiene que escribir el marcado del tema. Si tu tema usa el filtro structured_data de Shopify, que no escribe ni el estado ni variesBy, eso implica un cambio en el código del tema. Tienes más sobre cómo hacer que te encuentren en SEO y GEO.

Estadísticas del schema de producto

Las cifras principales de este estudio, en un solo lugar:

• De 2.447 páginas de producto de Shopify con schema de producto, de 103 tiendas, el 98% tenía los tres campos que Google exige para una ficha de comerciante: un nombre, una imagen y una oferta con precio y moneda.
• 182 de las 2.629 páginas de producto que descargué no tenían schema de producto en JSON-LD.
• Solo el 43% de las páginas de producto incluía un GTIN en su schema de producto, y 42 de las 103 tiendas no tenían ninguno en ninguna de las páginas que revisé.
• Cuando un producto tenía un código de barras válido en Shopify, el código llegaba al schema de producto solo el 62% de las veces. Los temas que usaban el filtro structured_data de Shopify lo pasaban en 418 de 419 páginas.
• El 24% de las páginas de producto, en 32 tiendas, tenía más de un bloque de producto, y en 17 páginas de 4 tiendas los bloques daban precios distintos para la misma variante.
• Solo 13 de las 103 tiendas tenían datos de envío en su marcado de producto y 18 tenían una política de devoluciones. 3 tenían una política de devoluciones a nivel de tienda.
• El 42% de las páginas de producto tenía una valoración agregada en su schema y el 3% tenía reseñas individuales.
• El 38% de las páginas de producto usaba ProductGroup, pero solo el 36% de los bloques ProductGroup decía en qué se diferencian las variantes (variesBy), y el 40% de los productos con variantes seguían marcados como un único Product.

Preguntas frecuentes sobre el schema de producto

¿Qué es el marcado schema de producto?

Son datos estructurados en una página de producto, normalmente en JSON-LD, que describen el producto para las máquinas: su nombre, imagen, precio, moneda, stock, marca, código de barras y más, con el vocabulario de schema.org. Google los usa para los resultados de producto y las fichas de comerciante, y los agentes de compra con IA los leen cuando visitan la página.

¿Shopify añade el schema de producto automáticamente?

La mayoría de los temas actuales lo hacen, pero lo que escriben varía. Los temas que usan el filtro structured_data de Shopify escriben un Product para un producto sin variantes y un ProductGroup para uno con variantes; en mi muestra, el 40% de los productos con variantes seguían marcados como un único Product. Comprueba si el tuyo incluye el código de barras como GTIN y si alguna app añade un segundo bloque.

¿El schema de producto es un factor de posicionamiento?

Google usa los datos estructurados para entender una página y para que pueda optar a resultados como las fichas de comerciante y los fragmentos de producto. Poder optar no garantiza que el resultado aparezca, y el schema no sustituye a lo básico: una página indexada, una buena página de producto y un feed limpio.

¿Necesito un GTIN en mi schema de producto?

Google lo considera recomendado. Si el producto tiene GTIN, ponlo en el schema y asegúrate de que es el mismo que el de tu feed. Si no tiene, como una marca propia o un artículo hecho a mano, envía en su lugar la marca y un MPN.

¿Las políticas de envío y devolución deben ir en el schema de producto?

Google recomienda una única política para toda la tienda, configurada en Search Console o Merchant Center o escrita una sola vez en tu marcado Organization. Las políticas a nivel de producto son para los productos que son diferentes. La configuración de Merchant Center y Search Console tiene prioridad sobre el marcado.

¿Qué diferencia hay entre Product y ProductGroup?

Product describe un único artículo. ProductGroup describe un producto que tiene variantes, como tallas o colores, con cada variante como su propio Product dentro de él. Google recomienda un ID de grupo (productGroupID), la lista de variantes y variesBy para indicar en qué se diferencian, y cada variante necesita su propio ID único.