Schema.org Product en 2026 : ce qui est obligatoire, ce qui est recommandé, et où déclarer retours et livraison

La documentation Google sur les fiches produit distingue deux choses que beaucoup d’articles mélangent : les propriétés requises pour qu’une page soit éligible à un résultat enrichi, et les propriétés qui enrichissent ce résultat quand elles sont présentes. Les informations de retour et de livraison relèvent de la seconde catégorie. Search Central les range explicitement parmi les enrichissements de résultat, avec les notes, la disponibilité et les baisses de prix.

Cet article reprend le balisage Product tel qu’il est documenté, section par section : ce qui est obligatoire, ce qui ne l’est pas, et où placer chaque bloc sur PrestaShop 8/9 et WooCommerce.

Le socle obligatoire tient en cinq propriétés

Sur Product :

• name
• image, une ou plusieurs URLs crawlables et indexables
• offers

Sur Offer :

• price, ou priceSpecification.price
• priceCurrency, ou priceSpecification.priceCurrency

Trois contraintes s’ajoutent. Les expériences Merchant listing exigent un Offer et non un AggregateOffer, puisque c’est vous qui vendez. Le prix doit être strictement supérieur à zéro. Et la page doit porter sur un produit unique ou ses déclinaisons, pas sur une liste ou une catégorie.

Google distingue par ailleurs deux familles de balisage. Le product snippet vise les pages où l’on ne peut pas acheter directement, typiquement un test éditorial, avec des options supplémentaires côté avis. Le merchant listing vise les pages où le visiteur achète chez vous, avec les tailles, la livraison et les retours. Remplir les propriétés requises du merchant listing rend en général la page éligible aussi au product snippet.

Tout le reste est recommandé

Le tableau des propriétés recommandées de Offer contient availability, itemCondition, url, priceValidUntil, validFrom, validThrough, hasMerchantReturnPolicy et shippingDetails. Côté Product : brand.name, sku, mpn, les gtin, description, category, color, size, material, pattern, audience, hasCertification, review, aggregateRating, inProductGroupWithID, isVariantOf et subjectOf.

Ces propriétés servent à débloquer des affichages : note moyenne, coût de livraison et livraison gratuite, disponibilité, informations de retour, baisse de prix. Google précise que ces enrichissements sont montrés à la discrétion de chaque expérience et peuvent évoluer, et conseille donc de fournir autant d’information produit que possible sans chercher à viser un affichage précis.

Le point qui tranche : la procédure de mise en production demande de corriger les erreurs critiques remontées par le Rich Results Test, puis ajoute que les problèmes non critiques peuvent améliorer la qualité du balisage, mais que les corriger n’est pas nécessaire pour être éligible aux résultats enrichis. Or « Missing field hasMerchantReturnPolicy » et « Missing field shippingDetails » remontent précisément en non critique dans la Search Console.

Retours et livraison : le bon niveau est Organization

Pour une politique de retour qui couvre tout ou presque tout le catalogue, Google demande de la déclarer une seule fois, sur la page qui décrit cette politique, dans un MerchantReturnPolicy imbriqué sous Organization (ou OnlineStore) via hasMerchantReturnPolicy. Inutile de la répéter sur chaque page du site.

À ce niveau, deux options de balisage minimal :

• Option A : applicableCountry et returnPolicyCategory. Si la catégorie vaut MerchantReturnFiniteReturnWindow, alors merchantReturnDays devient obligatoire.
• Option B : merchantReturnLink, l’URL de la page qui décrit la politique aux clients.

Le reste est recommandé et permet d’être précis : returnFees, returnMethod, returnShippingFeesAmount, returnPolicyCountry, refundType, restockingFee, returnLabelSource, itemCondition, les variantes customerRemorse* et itemDefect*, et returnPolicySeasonalOverride pour restreindre la fenêtre pendant les fêtes.

{
  "@context": "https://schema.org",
  "@type": "OnlineStore",
  "name": "Ma boutique",
  "url": "https://example.com",
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "@id": "https://example.com/retours#policy",
    "applicableCountry": ["FR", "BE", "LU"],
    "returnPolicyCountry": "FR",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 30,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn",
    "refundType": "https://schema.org/FullRefund"
  }
}

Le niveau Offer ne sert qu’à deux cas : déroger à la politique standard pour un produit précis, ou n’avoir aucune politique standard. Les propriétés supportées y sont un sous-ensemble de celles disponibles au niveau boutique. Pour référencer sans ambiguïté la politique globale depuis une fiche, un simple @id suffit :

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

La livraison suit la même logique. La politique standard se déclare sous Organization, avec un jeu de propriétés plus large que celui disponible au niveau produit, et une fiche peut y renvoyer via hasShippingService :

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

Au niveau Offer, si vous décrivez la livraison en dur, quatre propriétés sont requises pour l’enrichissement : deliveryTime (avec handlingTime et transitTime), shippingDestination (avec addressCountry en ISO 3166-1 alpha-2), shippingRate.currency et shippingRate.value ou shippingRate.maxValue. Un tarif par bloc OfferShippingDetails : pour plusieurs tarifs, plusieurs blocs.

Le balisage arrive en dernier dans l’ordre de priorité

Google documente un ordre de précédence pour les informations de retour, de la source la plus forte à la plus faible :

1. Content API for Shopping, réglages de retour
2. Réglages dans Merchant Center ou dans la Search Console
3. Balisage au niveau de la fiche produit
4. Balisage au niveau Organization

Deux conséquences pratiques. Si vos retours sont déjà configurés dans la Search Console ou dans Merchant Center, c’est cette configuration qui sera utilisée et le balisage devient redondant. Et l’absence de balisage sur une fiche ne se traduit pas par « pas de politique de retour » : Google descend simplement dans la chaîne pour trouver l’information. Pour un catalogue dont les frais de port bougent souvent, la documentation suggère d’ailleurs de passer par Merchant Center plutôt que par le balisage.

priceValidUntil n’est pas une date à renouveler chaque année

Définition officielle : la date et l’heure après lesquelles le prix ne sera plus disponible, au format ISO 8601. La doc ajoute une seule mise en garde, et ce n’est pas celle qu’on lit partout : la fiche peut ne pas s’afficher si priceValidUntil indique une date passée. Le risque vient d’une date périmée, pas d’une propriété absente.

Depuis la refonte de la section consacrée à la durée des promotions, le rôle de cette propriété est précis : borner une remise. Le début se déclare avec validFrom, la fin avec validThrough ou priceValidUntil. Google recommande de fournir les deux bornes, de vérifier que le début précède la fin, et d’inclure l’heure et le fuseau horaire.

"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"
  }
}

Attention au placement. Sur le nœud Offer, priceValidUntil et validThrough sont interchangeables. Sur un nœud PriceSpecification, seul validThrough fonctionne : priceValidUntil n’y est pas applicable.

Si votre prix n’a pas de date de fin réelle, ne mettez pas de priceValidUntil. Une date glissante à un an, générée automatiquement, ne décrit rien et revient à annoncer une fin de promotion qui n’existe pas.

Prix barré, prix membre, prix au litre

Trois types de prix sont reconnus, encodés dans priceSpecification sous Offer :

• Prix actif : ni priceType ni validForMemberTier. Il peut aussi rester au niveau de l’offre, dans price.
• Prix barré : priceType à https://schema.org/StrikethroughPrice. C’est lui qui déclenche l’affichage promotionnel, le prix actif devenant le prix soldé.
• Prix membre : validForMemberTier pointant vers un MemberProgramTier défini dans Merchant Center ou dans un MemberProgram sous Organization.

Les deux marqueurs ne se combinent pas : une spécification de prix portant à la fois priceType et validForMemberTier est ignorée. Si vous renseignez à la fois offers.price et offers.priceSpecification pour le prix actif, Google retient offers.price.

Pour les produits vendus au volume, au poids ou à la longueur, le prix unitaire passe par referenceQuantity dans un UnitPriceSpecification. La documentation signale que ce format compte particulièrement dans l’Union européenne, en Nouvelle-Zélande et en Australie.

Déclinaisons : ProductGroup, deux structures possibles

Une seule propriété est requise sur ProductGroup : name. L’identifiant du groupe se déclare soit par productGroupID sur le ProductGroup (le SKU parent), soit par inProductGroupWithID sur chaque variante. Si vous renseignez les deux, ils doivent correspondre. variesBy liste les axes de variation, avec six valeurs supportées : color, size, material, pattern, suggestedAge et suggestedGender.

Deux structures sont documentées. Soit les variantes sont imbriquées dans le ProductGroup via hasVariant, soit elles sont déclarées à côté et renvoient au parent via isVariantOf et un @id. Google recommande la première, décrite comme la représentation la plus compacte et la plus naturelle. La seconde est souvent plus simple à générer depuis un CMS.

Les contraintes techniques comptent autant que le balisage. Chaque variante a besoin d’un identifiant unique (sku ou gtin) et d’une URL distincte permettant de la présélectionner, avec la bonne image, le bon prix, la bonne disponibilité et la possibilité de l’ajouter au panier. Sur un site où tout se joue sur une page, une seule URL canonique représente le groupe. Sur un site multi-pages, chaque page doit porter un balisage complet et autonome, avec la définition du ProductGroup répétée.

Étiquetage énergétique : hasCertification

Pour l’électroménager, les ampoules ou les écrans vendus dans l’Union européenne, la propriété à utiliser est hasCertification, avec un objet Certification :

• issuedBy.name : EC ou European_Commission pour les étiquettes énergie UE, ADEME et BMWK pour les classes de CO2 des véhicules.
• name : EPREL, Vehicle_CO2_Class ou Vehicle_CO2_Class_Discharged_Battery.
• certificationIdentification : le code EPREL, requis pour les étiquettes énergie européennes.
• certificationRating : à utiliser quand le code EPREL n’existe pas (Norvège, Suisse, Royaume-Uni) ou pour les classes CO2. ratingValue est requis, et pour l’efficacité énergétique bestRating et worstRating le sont aussi.

Jusqu’à dix certifications par produit. L’ancienne propriété hasEnergyConsumptionDetails reste lue, mais la documentation recommande de basculer vers hasCertification.

Et les AI Overviews ?

Aucune documentation publique de Google ne conditionne l’apparition dans les AI Overviews à hasMerchantReturnPolicy, shippingDetails ou une autre propriété de Product. Ces propriétés sont documentées pour les expériences Merchant listing : panneau de connaissances Shopping, Popular products, Google Images, Google Lens, product snippets.

Un balisage propre aide les systèmes de Google à comprendre la page, ce qui reste une bonne raison de le soigner. Mais tant qu’aucune documentation ni étude reproductible ne l’établit, mieux vaut ne pas construire d’arbitrage budgétaire sur un lien de cause à effet entre ces propriétés et les réponses génératives.

Implémentation sur PrestaShop 8 et 9

Le thème Classic produit un JSON-LD Product avec offers, mais ni les politiques de retour et de livraison, ni la structure ProductGroup pour les déclinaisons. Deux chantiers distincts, à ne pas confondre.

Côté catalogue. Soit vous surchargez le template qui émet le JSON-LD dans votre thème enfant, avec la maintenance que cela implique à chaque montée de version, soit vous passez par un module. Dans les deux cas, vérifiez qu’un seul bloc Product est émis par page : deux modules SEO actifs en même temps produisent deux balisages concurrents.

Côté boutique. La politique de retour et la politique de livraison se déclarent une fois, sur les pages CMS correspondantes, dans un bloc Organization. Le plus simple reste un champ de code personnalisé injecté dans le head de ces deux pages.

Le module DataFirefly All in One SEO couvre le premier chantier : graphe JSON-LD avec Organization, WebSite, BreadcrumbList, Product incluant offers, priceValidUntil et l’AggregateRating issue de productcomments, plus FAQPage et LocalBusiness. Il fournit aussi les champs de code personnalisé head et fin de body, dans lesquels déclarer les politiques au niveau boutique.

Implémentation sur WooCommerce

WooCommerce émet nativement un Product avec offers, modifiable via le filtre woocommerce_structured_data_product. Yoast SEO et Rank Math génèrent chacun leur propre graphe et exposent leur propre point d’extension. Choisissez une seule de ces trois sources : cumuler revient à publier plusieurs blocs Product sur la même URL.

Pour les politiques, la logique est identique à PrestaShop : un bloc Organization sur la page de retours et sur la page de livraison, référencé depuis les fiches par @id si vous voulez lever toute ambiguïté. Le plugin llms.txt + AEO Schema WooCommerce gère cette partie graphe et FAQ pour les agents.

Vérifier le résultat

1. Rich Results Test. Corrigez les erreurs critiques. Les avertissements non critiques restent à votre main : arbitrez selon les enrichissements que vous voulez obtenir.
2. Validateur schema.org. Syntaxe JSON-LD et cohérence des @type, indépendamment des règles Google.
3. Search Console, rapport Merchant listings. L’état réel en production, une fois les pages recrawlées. Comptez plusieurs jours après publication.
4. Merchant Center ou Search Console, réglages de retour. Vérifiez qu’une configuration existante ne prend pas déjà le pas sur votre balisage.

Par où commencer

1. Vérifier que name, image, offers, price et priceCurrency sont présents et exacts sur 100 % des fiches. C’est le seul point réellement bloquant.
2. Ajouter availability, itemCondition, sku, brand.name, et le GTIN quand il existe.
3. Déclarer la politique de retour et la politique de livraison une fois, au niveau Organization, sur les pages dédiées.
4. Ne poser priceValidUntil que sur les prix qui ont une date de fin réelle, avec validFrom en face.
5. Traiter les déclinaisons avec ProductGroup, après s’être assuré que chaque déclinaison possède bien une URL propre.

Une règle chapeaute le tout : le balisage doit décrire ce que la page affiche. Un retour gratuit balisé doit être annoncé sur le site, un délai de 30 jours balisé doit être un délai de 30 jours effectif. C’est ce principe, et non le nombre de propriétés, qui explique la plupart des actions manuelles sur données structurées.

À lire aussi : le guide complet du SEO e-commerce et le FAQ schema et les rich snippets.

Pour passer à l’action : notre sélection de modules pour optimiser vos fiches produit.