Schema.org Product en 2026: qué es obligatorio, qué es recomendado y dónde declarar devoluciones y envíos

La documentación de Google sobre fichas de producto separa dos cosas que muchos artículos mezclan: las propiedades obligatorias para que una página pueda optar a un resultado enriquecido, y las propiedades que enriquecen ese resultado cuando están presentes. La información de devoluciones y de envío pertenece al segundo grupo. Search Central la clasifica explícitamente entre las mejoras de resultado, junto a las valoraciones, la disponibilidad y las bajadas de precio.

Este artículo repasa el marcado Product tal y como está documentado, sección por sección: qué es obligatorio, qué no lo es y dónde colocar cada bloque en PrestaShop 8/9 y WooCommerce.

La base obligatoria son cinco propiedades

En Product:

• name
• image, una o varias URLs rastreables e indexables
• offers

En Offer:

• price, o priceSpecification.price
• priceCurrency, o priceSpecification.priceCurrency

A esto se añaden tres restricciones. Las experiencias de merchant listing exigen un Offer y no un AggregateOffer, porque quien vende es usted. El precio debe ser mayor que cero. Y la página debe tratar de un único producto o de sus variantes, no de una lista ni de una categoría.

Google distingue además dos familias de marcado. El product snippet apunta a páginas donde no se puede comprar directamente, normalmente una reseña editorial, con opciones adicionales sobre las opiniones. El merchant listing apunta a páginas donde el visitante compra en su tienda, con tallas, envío y devoluciones. Cubrir las propiedades obligatorias del merchant listing suele bastar para que la página opte también al product snippet.

Todo lo demás es recomendado

La tabla de propiedades recomendadas de Offer contiene availability, itemCondition, url, priceValidUntil, validFrom, validThrough, hasMerchantReturnPolicy y shippingDetails. En Product: brand.name, sku, mpn, la familia gtin, description, category, color, size, material, pattern, audience, hasCertification, review, aggregateRating, inProductGroupWithID, isVariantOf y subjectOf.

Estas propiedades desbloquean visualizaciones: valoración media, coste de envío y envío gratuito, disponibilidad, información de devolución, bajada de precio. Google precisa que las mejoras se muestran a discreción de cada experiencia y pueden cambiar con el tiempo, y aconseja aportar toda la información de producto disponible en lugar de apuntar a una visualización concreta.

El dato que zanja la discusión: el procedimiento de puesta en producción pide corregir los errores críticos detectados por el Rich Results Test, y añade que los problemas no críticos pueden mejorar la calidad del marcado, pero que corregirlos no es necesario para optar a los resultados enriquecidos. Y «Missing field hasMerchantReturnPolicy» y «Missing field shippingDetails» aparecen precisamente como no críticos en Search Console.

Devoluciones y envíos: el nivel correcto es Organization

Para una política de devolución que cubre todo o casi todo el catálogo, Google pide declararla una sola vez, en la página que describe esa política, en un MerchantReturnPolicy anidado bajo Organization (u OnlineStore) mediante hasMerchantReturnPolicy. No hace falta repetirla en cada página del sitio.

A ese nivel hay dos opciones de marcado mínimo:

• Opción A: applicableCountry y returnPolicyCategory. Si la categoría es MerchantReturnFiniteReturnWindow, entonces merchantReturnDays pasa a ser obligatoria.
• Opción B: merchantReturnLink, la URL de la página que describe la política a los clientes.

El resto es recomendado y permite afinar: returnFees, returnMethod, returnShippingFeesAmount, returnPolicyCountry, refundType, restockingFee, returnLabelSource, itemCondition, las variantes customerRemorse* e itemDefect*, y returnPolicySeasonalOverride para acortar la ventana en campañas navideñas.

{
  "@context": "https://schema.org",
  "@type": "OnlineStore",
  "name": "Mi tienda",
  "url": "https://example.com",
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "@id": "https://example.com/devoluciones#policy",
    "applicableCountry": ["ES", "PT"],
    "returnPolicyCountry": "ES",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 30,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn",
    "refundType": "https://schema.org/FullRefund"
  }
}

El nivel Offer sirve solo para dos casos: excepcionar la política estándar en un producto concreto, o no tener política estándar. Las propiedades admitidas ahí son un subconjunto de las disponibles a nivel de tienda. Para referenciar sin ambigüedad la política global desde una ficha basta con un @id:

"hasMerchantReturnPolicy": { "@id": "https://example.com/devoluciones#policy" }

El envío sigue la misma lógica. La política estándar se declara bajo Organization, con un conjunto de propiedades más amplio que el disponible a nivel de producto, y una ficha puede apuntar a ella mediante hasShippingService:

"shippingDetails": {
  "@type": "OfferShippingDetails",
  "hasShippingService": { "@id": "https://example.com/envios#policy" }
}

Si describe el envío directamente en Offer, cuatro propiedades son obligatorias para la mejora: deliveryTime (con handlingTime y transitTime), shippingDestination (con addressCountry en ISO 3166-1 alfa-2), shippingRate.currency y shippingRate.value o shippingRate.maxValue. Una tarifa por bloque OfferShippingDetails: para varias tarifas, varios bloques.

El marcado va el último en el orden de prioridad

Google documenta un orden de precedencia para la información de devolución, de la fuente más fuerte a la más débil:

1. Content API for Shopping, ajustes de devolución
2. Ajustes en Merchant Center o en Search Console
3. Marcado a nivel de ficha de producto
4. Marcado a nivel Organization

Dos consecuencias prácticas. Si sus devoluciones ya están configuradas en Search Console o en Merchant Center, esa configuración es la que se usará y el marcado pasa a ser redundante. Y la ausencia de marcado en una ficha no se traduce como «sin política de devolución»: Google simplemente baja por la cadena hasta encontrar el dato. Para un catálogo cuyos gastos de envío cambian a menudo, la documentación sugiere pasar por Merchant Center en lugar de por el marcado.

priceValidUntil no es una fecha que se renueve cada año

Definición oficial: la fecha y hora a partir de la cual el precio dejará de estar disponible, en formato ISO 8601. La documentación añade una única advertencia, y no es la que se repite por todas partes: la ficha puede no mostrarse si priceValidUntil indica una fecha pasada. El riesgo viene de una fecha caducada, no de una propiedad ausente.

Desde la reescritura de la sección dedicada a la duración de las promociones, el papel de esta propiedad es concreto: delimitar un descuento. El inicio se declara con validFrom y el final con validThrough o con priceValidUntil. Google recomienda aportar ambos límites, comprobar que el inicio es anterior al final e incluir la hora y la zona horaria.

"offers": {
  "@type": "Offer",
  "price": 10.00,
  "priceCurrency": "EUR",
  "validFrom": "2026-11-20T08:00:00+01:00",
  "priceValidUntil": "2026-11-30T23:59:59+01:00",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceType": "https://schema.org/StrikethroughPrice",
    "price": 15.00,
    "priceCurrency": "EUR"
  }
}

Cuidado con la ubicación. En el nodo Offer, priceValidUntil y validThrough son intercambiables. En un nodo PriceSpecification solo funciona validThrough: priceValidUntil no es aplicable ahí.

Si su precio no tiene fecha de fin real, no ponga priceValidUntil. Una fecha móvil a un año, generada automáticamente, no describe nada y equivale a anunciar un fin de promoción inexistente.

Precio tachado, precio de socio, precio por litro

Se reconocen tres tipos de precio, codificados en priceSpecification bajo Offer:

• Precio activo: ni priceType ni validForMemberTier. También puede quedarse a nivel de oferta, en price.
• Precio tachado: priceType con valor https://schema.org/StrikethroughPrice. Es lo que activa la visualización promocional, y el precio activo pasa a ser el precio rebajado.
• Precio de socio: validForMemberTier apuntando a un MemberProgramTier definido en Merchant Center o en un MemberProgram bajo Organization.

Los dos marcadores no se combinan: una especificación de precio que lleve a la vez priceType y validForMemberTier se ignora. Si rellena a la vez offers.price y offers.priceSpecification para el precio activo, Google se queda con offers.price.

Para productos vendidos por volumen, peso o longitud, el precio unitario pasa por referenceQuantity dentro de un UnitPriceSpecification. La documentación señala que este formato importa especialmente en la Unión Europea, Nueva Zelanda y Australia.

Variantes: ProductGroup y dos estructuras posibles

Solo una propiedad es obligatoria en ProductGroup: name. El identificador del grupo se declara con productGroupID en el ProductGroup (el SKU padre) o con inProductGroupWithID en cada variante. Si indica ambos, deben coincidir. variesBy enumera los ejes de variación, con seis valores admitidos: color, size, material, pattern, suggestedAge y suggestedGender.

Hay dos estructuras documentadas. O las variantes se anidan en el ProductGroup mediante hasVariant, o se declaran aparte y apuntan al padre con isVariantOf y un @id. Google recomienda la primera, que describe como la representación más compacta y natural. La segunda suele ser más fácil de generar desde un CMS.

Las restricciones técnicas pesan tanto como el marcado. Cada variante necesita un identificador único (sku o gtin) y una URL propia que la preseleccione, con la imagen, el precio y la disponibilidad correctos, y la posibilidad de añadirla al carrito. En un sitio de página única, una sola URL canónica representa el grupo. En un sitio multipágina, cada página debe llevar un marcado completo y autónomo, con la definición del ProductGroup repetida.

Etiquetado energético: hasCertification

Para electrodomésticos, bombillas o pantallas vendidos en la UE, la propiedad a usar es hasCertification, con un objeto Certification:

• issuedBy.name: EC o European_Commission para las etiquetas energéticas de la UE, ADEME y BMWK para las clases de CO2 de vehículos.
• name: EPREL, Vehicle_CO2_Class o Vehicle_CO2_Class_Discharged_Battery.
• certificationIdentification: el código EPREL, obligatorio para las etiquetas energéticas europeas.
• certificationRating: para los casos sin código EPREL (Noruega, Suiza, Reino Unido) o para las clases de CO2. ratingValue es obligatorio, y para la eficiencia energética también lo son bestRating y worstRating.

Hasta diez certificaciones por producto. La antigua propiedad hasEnergyConsumptionDetails se sigue leyendo, pero la documentación recomienda pasar a hasCertification.

¿Y los AI Overviews?

Ninguna documentación pública de Google condiciona la aparición en los AI Overviews a hasMerchantReturnPolicy, shippingDetails ni a ninguna otra propiedad de Product. Estas propiedades están documentadas para las experiencias de merchant listing: panel de conocimiento de Shopping, Popular products, Google Imágenes, Google Lens y product snippets.

Un marcado limpio ayuda a los sistemas de Google a entender la página, lo que ya es razón suficiente para cuidarlo. Pero mientras ninguna documentación ni estudio reproducible lo establezca, no hay base para asignar presupuesto a una relación de causa y efecto entre estas propiedades y las respuestas generativas.

Implementación en PrestaShop 8 y 9

El tema Classic genera un JSON-LD Product con offers, pero ni las políticas de devolución y envío ni la estructura ProductGroup para las variantes. Son dos tareas distintas que conviene no mezclar.

Lado catálogo. O sobrescribe en su tema hijo la plantilla que emite el JSON-LD, con el mantenimiento que eso implica en cada actualización, o recurre a un módulo. En ambos casos, compruebe que solo se emite un bloque Product por página: dos módulos SEO activos a la vez producen dos marcados en competencia.

Lado tienda. La política de devolución y la de envío se declaran una vez, en las páginas CMS correspondientes, dentro de un bloque Organization. Lo más sencillo es un campo de código personalizado inyectado en el head de esas dos páginas.

El módulo DataFirefly All in One SEO cubre la primera tarea: grafo JSON-LD con Organization, WebSite, BreadcrumbList, Product con offers, priceValidUntil y el AggregateRating tomado de productcomments, más FAQPage y LocalBusiness. También incluye campos de código personalizado en head y fin de body, donde declarar las políticas a nivel de tienda.

Implementación en WooCommerce

WooCommerce emite de forma nativa un Product con offers, modificable mediante el filtro woocommerce_structured_data_product. Yoast SEO y Rank Math construyen cada uno su propio grafo y exponen su propio punto de extensión. Elija una sola de estas tres fuentes: acumularlas significa publicar varios bloques Product en la misma URL.

Para las políticas, la lógica es idéntica a PrestaShop: un bloque Organization en la página de devoluciones y en la de envíos, referenciado desde las fichas por @id si quiere eliminar toda ambigüedad. El plugin llms.txt + AEO Schema WooCommerce se encarga de esa parte de grafo y de la FAQ para agentes.

Comprobar el resultado

1. Rich Results Test. Corrija los errores críticos. Los avisos no críticos quedan a su criterio: decida según las mejoras que quiera obtener.
2. Validador de schema.org. Sintaxis JSON-LD y coherencia de los @type, al margen de las reglas de Google.
3. Search Console, informe Merchant listings. El estado real en producción, una vez rastreadas las páginas. Cuente con varios días tras la publicación.
4. Merchant Center o Search Console, ajustes de devolución. Compruebe que una configuración existente no esté imponiéndose ya sobre su marcado.

Por dónde empezar

1. Verificar que name, image, offers, price y priceCurrency están presentes y son correctos en el 100 % de las fichas. Es el único punto realmente bloqueante.
2. Añadir availability, itemCondition, sku, brand.name y el GTIN cuando exista.
3. Declarar la política de devolución y la de envío una vez, a nivel Organization, en sus páginas dedicadas.
4. Poner priceValidUntil solo en los precios con fecha de fin real, acompañado de validFrom.
5. Tratar las variantes con ProductGroup, después de asegurarse de que cada variante tiene su propia URL.

Una regla está por encima de todo lo anterior: el marcado debe describir lo que la página muestra. Una devolución gratuita marcada debe anunciarse en el sitio, un plazo de 30 días marcado debe ser un plazo de 30 días real. Ese principio, y no el número de propiedades, explica la mayoría de las acciones manuales sobre datos estructurados.

Para seguir leyendo: la guía completa de SEO e-commerce y el FAQ schema y los rich snippets.

Para pasar a la acción: nuestra selección de módulos para optimizar sus fichas de producto.