En 2026, les rich results e-commerce ne sont plus un bonus. Ils sont la condition d’éligibilité pour apparaître dans les AI Overviews, les onglets Shopping, les comparateurs de prix natifs, et la majorité des moteurs de réponse. Et Google a profondément remanié les propriétés Schema.org qu’il exige sur les fiches Product depuis 2024.
L’évolution la plus impactante : hasMerchantReturnPolicy et shippingDetails sont devenus quasi-obligatoires pour conserver les rich results Product, et les marchands qui ne les renseignent pas voient leurs résultats enrichis se dégrader silencieusement dans la Search Console. Cet article fait le point complet sur les propriétés qui comptent vraiment en 2026 et leur implémentation correcte sur PrestaShop et WooCommerce.
Ce qui a changé depuis 2024
Google a poussé une vague de mises à jour de sa documentation Search Central concernant les produits, avec trois inflexions majeures :
- Promotion des politiques de retour et de livraison au rang de propriétés structurantes. Plus précisément, hasMerchantReturnPolicy et shippingDetails sont passés du statut « recommandé » à « fortement recommandé », avec un impact direct sur l’éligibilité aux rich results Shopping.
- Renforcement des contrôles de cohérence prix/disponibilité. Si le prix affiché dans le balisage diffère du prix de la page (typiquement après une promotion intra-journée), Google déclasse la fiche.
- Exigences d’identifiants produits (GTIN, MPN, brand) durcies pour figurer dans les Shopping ads et le Shopping organique. La propriété productGroupID est devenue importante pour les déclinaisons.
Concrètement, une fiche PrestaShop 8 qui sortait des rich results en 2023 ne les obtiendra plus en 2026 si elle ne s’est pas mise à niveau.
Le balisage Product minimal viable en 2026
La structure recommandée pour une fiche produit standard se compose de huit blocs de propriétés. Sur PrestaShop, le balisage natif en couvre une partie ; sur WooCommerce, le plugin Yoast SEO ou Rank Math en couvre une autre. Aucun ne couvre l’ensemble par défaut.
1. Identité produit
name, image (au moins trois résolutions différentes), description (entre 50 et 500 mots), sku, mpn, gtin13 ou gtin14, brand (avec @type Brand et name). Le couple GTIN + brand est l’identifiant universel : sans lui, pas de matching dans le Shopping graph de Google.
2. Offer (au cœur du rich result)
price, priceCurrency, availability (avec la valeur exacte parmi InStock, OutOfStock, BackOrder, PreOrder), priceValidUntil (date au format ISO), url canonique, itemCondition (NewCondition par défaut).
Sur PrestaShop, le piège classique est l’oubli de priceValidUntil : sans elle, Google considère que le prix n’est plus valable après quelques jours et déclasse la fiche. Il faut renseigner la date d’expiration de la TVA inscrite au catalogue, soit en général à 1 an glissant.
3. hasMerchantReturnPolicy
C’est la grosse nouveauté 2024-2026. Le balisage attendu pointe vers un objet MerchantReturnPolicy avec : applicableCountry (liste ISO 3166-1 alpha-2), returnPolicyCategory (MerchantReturnFiniteReturnWindow ou autre), merchantReturnDays (durée en jours), returnMethod (ReturnByMail le plus souvent), returnFees (FreeReturn, OriginalShippingFees, RestockingFees…).
Une politique de retour balisée correctement gagne désormais un badge visible dans Google Shopping (« Retour gratuit 30 jours ») qui augmente significativement le taux de clic. Une absence de balisage est interprétée comme une absence de politique — y compris si la politique existe sur le site sous forme textuelle dans une page CGV.
4. shippingDetails
Objet OfferShippingDetails avec : shippingRate (MonetaryAmount avec value et currency), shippingDestination (DefinedRegion par code pays ou code postal), deliveryTime (ShippingDeliveryTime avec handlingTime et transitTime). On peut empiler plusieurs blocs shippingDetails pour décrire plusieurs destinations.
Là encore, le badge « Livraison gratuite » dans Google Shopping organique est conditionné à ce balisage. Sans lui, le coût de livraison apparaît comme « non précisé », ce qui réduit la conversion.
5. AggregateRating et review
aggregateRating (ratingValue, reviewCount), et au moins quelques objets review (author, datePublished, reviewRating, reviewBody). Important : ces données doivent refléter des avis réels, vérifiables, et présents sur la page. Les pénalités pour avis fictifs sont aujourd’hui systématiques et lourdes.
6. Variants et ProductGroup
Pour les produits à déclinaisons (taille, couleur), la structure recommandée a évolué. Plutôt qu’un balisage Product unique avec offers multiples, Google préfère désormais un objet ProductGroup parent (avec productGroupID = id du produit maître) et des objets Product enfants distincts pour chaque déclinaison, liés par hasVariant.
C’est plus de balisage à générer, mais c’est ce qui permet aux comparateurs et aux AI Overviews de comprendre qu’on parle bien d’un même produit décliné et non de produits différents.
7. AdditionalProperty (Energy, sustainability)
Pour les biens soumis à l’étiquetage énergétique (électroménager, ampoules, écrans), un additionalProperty avec name=« energyConsumptionScale » et value (par exemple « A » sur l’échelle EU 2021) est désormais détecté et affiché dans les SERP. Pour la mode et la déco, des propriétés sustainability et material gagnent en visibilité dans les AI Overviews orientés « achat responsable ».
8. Manufacturer et country of origin
manufacturer (avec name et éventuellement countryOfOrigin) et countryOfOrigin sur le Product : utile pour le SEO local (« fabriqué en France ») et pour les comparateurs européens orientés provenance.
Implémentation sur PrestaShop 8 et 9
Le balisage natif Product et Offer est correct sur PrestaShop 8.1+. Mais hasMerchantReturnPolicy, shippingDetails et le passage à ProductGroup pour les déclinaisons ne sont pas implémentés nativement. Trois voies pour compléter :
- Surcharger le template productJsonLd dans le thème personnalisé. Cohérent mais imposera une maintenance à chaque migration.
- Utiliser un module SEO structuré tiers. Plusieurs solutions existent, qualité inégale. Vérifier qu’elles génèrent un JSON-LD valide via le Rich Results Test de Google avant achat.
- Module DataFirefly dfseoai, qui injecte automatiquement les propriétés ajoutées par Google depuis 2024 (hasMerchantReturnPolicy, shippingDetails, ProductGroup, additionalProperty énergétique), et qui rafraîchit le balisage à chaque changement de politique ou de tarif de livraison.
Implémentation sur WooCommerce
WooCommerce natif émet un balisage Product partiel. Yoast SEO et Rank Math complètent. Mais aucun ne couvre hasMerchantReturnPolicy de manière granulaire (avec différents délais selon le pays) ni shippingDetails par destination.
Sur WooCommerce, deux approches viables : étendre Yoast / Rank Math via leurs hooks (graph piece schemas, schema array filter), ou installer un plugin spécialisé qui surcharge le balisage. Côté DataFirefly, le module Schema avancé pour WooCommerce est en feuille de route 2026.
Comment valider que le balisage fonctionne réellement
Quatre outils complémentaires, à utiliser dans cet ordre :
- Schema.org Validator (validator.schema.org) : valide la syntaxe JSON-LD et la cohérence des @type.
- Rich Results Test Google : valide l’éligibilité aux rich results et signale les propriétés manquantes critiques.
- Search Console / rapport État des résultats enrichis : remonte les avertissements en production (typiquement « priceValidUntil non précisé », « returnPolicyCategory manquant »).
- Tests de production AI Overviews et Perplexity : interroger les moteurs avec « meilleur [produit catégorie] avec retour gratuit » et observer si la boutique apparaît dans les sources. C’est la mesure finale en 2026.
Le piège des données structurées surchargées
Une tentation classique : empiler un maximum de propriétés pour « plaire à Google ». C’est contre-productif. Google détecte les balisages génériques (review bots, propriétés copiées-collées qui ne correspondent pas à la page) et déclasse. La règle simple : le balisage doit refléter exactement ce qui est visible sur la page. Un retour gratuit balisé doit être annoncé visiblement. Une note moyenne balisée doit afficher les avis.
De la même manière, ne pas inventer de propriétés (les AggregateOffer sans offer enfant cohérent, par exemple). La cohérence vaut mieux que l’exhaustivité.
Conclusion : la fiche produit comme objet de données
En 2026, la fiche produit est lue par plus de robots et d’agents que de visiteurs humains. La page rendue par le navigateur reste importante pour la conversion finale, mais l’amont — la découverte dans les AI Overviews, le matching dans Shopping, l’inclusion dans une réponse Perplexity — passe désormais entièrement par la qualité du balisage Schema.org.
Mettre à jour son balisage selon les exigences 2024-2026 est probablement l’action SEO/AEO la plus rentable en 2026 sur une boutique e-commerce existante : peu de risque, ROI mesurable dans la Search Console en quelques semaines, et impact direct sur la visibilité dans les agents IA et les comparateurs.
