Pourquoi Google refuse-t-il les fourchettes de prix dans les données structurées produit ?

Qu'est-ce que Google entend exactement par "valeur spécifique" ?

Google bloque net toute tentative d'utiliser une fourchette de prix (ex: "49,99€ - 99,99€") dans la propriété price de l'objet Offer. Il faut une valeur unique, précise, exprimée en chiffres (ex: "79,99").

Ce changement touche directement les sites qui affichent des produits personnalisables ou à options variables. L'affichage des baisses de prix devient impossible si vous ne proposez pas de prix fixe dans vos structured data.

Pourquoi cette restriction sur les baisses de prix maintenant ?

L'objectif de Google est d'éviter les promesses vagues dans les résultats enrichis. Une baisse de prix affichée en SERP doit être vérifiable immédiatement — impossible si le prix varie selon les options choisies.

Google veut aussi réduire le taux de clics trompeurs. Un utilisateur qui voit "-20%" en snippet s'attend à un prix précis, pas à découvrir "à partir de X" sur la fiche produit.

Quelle différence avec les autres affichages riches produit ?

Les autres enrichissements — notes, disponibilité, image — tolèrent encore certaines flexibilités. Mais l'affichage des baisses de prix est soumis à ce critère strict : offre présente + prix unique.

Sans offre ou avec fourchette, vous gardez potentiellement l'affichage du prix actuel, mais aucune mention de réduction n'apparaîtra en snippet.

• Le prix dans Offer doit être une valeur numérique unique
• Les fourchettes de prix (minPrice / maxPrice) ne qualifient pas pour l'affichage des baisses
• L'objet Offer est obligatoire — pas d'alternative via AggregateOffer seul
• Les baisses ne s'affichent que si Google peut comparer deux valeurs fixes (prix actuel vs ancien prix)

Cette exigence colle-t-elle avec la réalité du e-commerce ?

Soyons honnêtes : beaucoup de catalogues fonctionnent sur des modèles de prix dynamiques. Variantes produit, tarifs personnalisés, grilles tarifaires B2B… Google impose ici une contrainte qui ne correspond pas toujours à la structure commerciale réelle.

Le problème, c'est que pour certains secteurs — imprimerie en ligne, mobilier sur-mesure, services configurables — un prix unique n'a aucun sens. Vous êtes face à un choix : sacrifier la précision de vos données ou renoncer à l'affichage des baisses.

Quels risques si on contourne cette règle ?

Certains sites tentent de simuler un prix fixe en prenant le prix médian ou le prix de la variante la plus vendue. Techniquement, ça passe la validation schema.org, mais Google peut pénaliser la cohérence si l'utilisateur arrive sur une page où le prix réel diffère. [A vérifier] — Google n'a pas publié de seuil de tolérance officiel.

Autre zone grise : les sites qui utilisent AggregateOffer avec plusieurs Offer enfants, chacune ayant un prix spécifique. La doc Google reste évasive sur la gestion de ces cas — difficile de savoir quelle offre sera retenue pour l'affichage.

Cette déclaration est-elle cohérente avec les pratiques observées ?

Sur le terrain, on constate que Google ignore déjà les fourchettes depuis plusieurs mois — la déclaration d'Alan Kent vient simplement officialiser une pratique déjà en place. Rien de révolutionnaire, donc.

En revanche, le manque de guideline claire sur les cas limites — produits avec options obligatoires, prix variant selon la géolocalisation — reste frustrant. Google préfère poser une règle stricte plutôt que de documenter les exceptions.

Que faut-il faire concrètement pour rester éligible ?

Première étape : auditer vos données structurées produit avec Search Console ou un outil de validation schema.org. Vérifiez que chaque Product a bien un objet Offer avec une propriété price contenant une valeur numérique unique.

Si vous avez des produits à variantes, deux options — soit vous créez une page dédiée par variante (chacune avec son propre schema), soit vous choisissez de baliser uniquement la variante par défaut avec son prix spécifique. La seconde solution est plus simple mais limite la couverture.

Quelles erreurs éviter absolument ?

Ne balisez jamais une fourchette avec "price": "50-100" — Google ignore purement et simplement cette syntaxe. Si vous voulez exprimer des prix min/max, utilisez AggregateOffer, mais sachez que ça ne qualifie pas pour l'affichage des baisses.

Autre piège fréquent : oublier de renseigner priceCurrency. Sans cet attribut, même un prix spécifique peut être invalidé. Toujours utiliser le code ISO 4217 (EUR, USD, GBP…).

Comment vérifier que mon implémentation est conforme ?

Utilisez le Rich Results Test de Google sur une URL produit représentative. Si vous voyez un warning ou une erreur sur Offer, c'est que votre structure n'est pas conforme.

Vérifiez ensuite dans Search Console (Améliorations > Produits) le taux de pages éligibles. Une chute soudaine du nombre de pages avec balisage valide signale souvent un problème de fourchette de prix non détectée en dev.

• Vérifier que chaque Product a un objet Offer avec price en valeur numérique unique
• Supprimer toute fourchette de prix dans les structured data produit
• Ajouter priceCurrency systématiquement (ex: "EUR")
• Tester avec Rich Results Test et valider dans Search Console
• Pour les produits à variantes, décider d'une stratégie : page par variante ou balisage de la variante par défaut uniquement
• Surveiller les rapports d'erreurs dans Search Console après déploiement