Schema de producto que gana fichas

Schema válido y schema elegible son cosas distintas. El marcado de producto solo gana una ficha enriquecida cuando los campos obligatorios están presentes, son coherentes con lo que la página muestra visiblemente y los identificadores resuelven. La mayoría de las implementaciones pasan la validación pero les faltan los campos que realmente activan la mejora, o contradicen la página renderizada de una forma que la suprime en silencio.

El archivo de la habilidad

---
name: product-schema-that-earns-listings
description: Úselo cuando las páginas de producto son válidas en la prueba de resultados enriquecidos pero no muestran precio, valoración ni disponibilidad en la ficha de búsqueda.
---

# Schema de producto que gana fichas

Schema válido y schema elegible son cosas distintas. El marcado de producto solo gana una ficha enriquecida cuando los campos obligatorios están presentes, son coherentes con lo que la página muestra visiblemente y los identificadores resuelven. La mayoría de las implementaciones pasan la validación pero les faltan los campos que realmente activan la mejora, o contradicen la página renderizada de una forma que la suprime en silencio.

## Qué necesitas antes

- el DOM renderizado de una página de producto, no el HTML de origen
- su cobertura de datos de GTIN, MPN y marca en todo el catálogo
- los informes de fichas de comercio y de fragmentos de producto de Search Console

## Método

1. Valide contra la página renderizada, ya que muchas plantillas de ecommerce inyectan precio y stock en el cliente y el rastreador puede ver un valor distinto del que declara su JSON-LD.
2. Publique offers con price, priceCurrency, availability y priceValidUntil. Que falte solo la divisa basta para suprimir el precio en la ficha aun superando la validación.
3. Rellene gtin donde lo tenga, y mpn más brand donde no. La cobertura de identificadores es lo que separa la elegibilidad para fichas de comercio de un simple fragmento de producto.
4. Para productos con variantes use un único product con una offer por cada variante, o aggregateOffer con lowPrice y highPrice. No emita un objeto Product por variante en una misma URL.
5. Marque aggregateRating solo cuando las reseñas estén realmente en esa página y visibles. Agregar valoraciones de todo el sitio en cada producto es la causa más habitual de una acción manual por datos estructurados.
6. Siga semanalmente el informe de fichas de comercio de Search Console en lugar de volver a probar URL sueltas: muestra qué artículos son elegibles a escala y cuáles se están filtrando.

## Qué produce esto

JSON-LD de producto que supera el listón de elegibilidad para fichas de comercio, no solo el validador, verificado contra la página renderizada.

## Dónde falla esto

- que el precio del JSON-LD se desvíe del precio mostrado porque uno está cacheado y el otro no, lo que suprime la mejora en silencio
- reutilizar una única puntuación de reseñas de todo el sitio como aggregateRating en cada página de producto
- omitir priceCurrency o los datos de envío y dar por hecho que un resultado válido en la prueba significa que la ficha se mostrará

---

De la biblioteca de habilidades de QuQi - https://www.quqi.io/es/skills/product-schema-that-earns-listings

Qué necesitas antes

• el DOM renderizado de una página de producto, no el HTML de origen
• su cobertura de datos de GTIN, MPN y marca en todo el catálogo
• los informes de fichas de comercio y de fragmentos de producto de Search Console

Método

1. 01 Valide contra la página renderizada, ya que muchas plantillas de ecommerce inyectan precio y stock en el cliente y el rastreador puede ver un valor distinto del que declara su JSON-LD.
2. 02 Publique offers con price, priceCurrency, availability y priceValidUntil. Que falte solo la divisa basta para suprimir el precio en la ficha aun superando la validación.
3. 03 Rellene gtin donde lo tenga, y mpn más brand donde no. La cobertura de identificadores es lo que separa la elegibilidad para fichas de comercio de un simple fragmento de producto.
4. 04 Para productos con variantes use un único product con una offer por cada variante, o aggregateOffer con lowPrice y highPrice. No emita un objeto Product por variante en una misma URL.
5. 05 Marque aggregateRating solo cuando las reseñas estén realmente en esa página y visibles. Agregar valoraciones de todo el sitio en cada producto es la causa más habitual de una acción manual por datos estructurados.
6. 06 Siga semanalmente el informe de fichas de comercio de Search Console en lugar de volver a probar URL sueltas: muestra qué artículos son elegibles a escala y cuáles se están filtrando.

Qué produce esto

JSON-LD de producto que supera el listón de elegibilidad para fichas de comercio, no solo el validador, verificado contra la página renderizada.

Dónde falla esto

• que el precio del JSON-LD se desvíe del precio mostrado porque uno está cacheado y el otro no, lo que suprime la mejora en silencio
• reutilizar una única puntuación de reseñas de todo el sitio como aggregateRating en cada página de producto
• omitir priceCurrency o los datos de envío y dar por hecho que un resultado válido en la prueba significa que la ficha se mostrará

Usa esta skill en tu propia IA

El archivo es markdown simple, con el nombre y el disparador en su frontmatter. Cuando un asistente sabe cargar skills por su cuenta, es ese frontmatter lo que lee para decidir que esta le aplica.

Más en SEO para ecommerce