Pourquoi votre prix soldé ne s'affiche pas sur Google Shopping : un diagnostic de flux en huit vérifications

Vous avez ajouté sale_price au flux, le produit est approuvé, et l'acheteur voit pourtant un seul prix ordinaire, sans prix barré ni badge de promotion. La documentation de Google explique pourquoi cela arrive plus souvent que les équipes flux ne l'imaginent : une annotation de prix promotionnel exige une remise supérieure à 5 % et inférieure à 90 %, un prix de base appliqué depuis suffisamment longtemps (dans la plupart des pays où les annonces Shopping sont disponibles, 30 jours au cours des 200 derniers) et une page de destination qui affiche les deux prix. Si une seule condition manque, le produit reste en ligne sans l'annotation. Ce guide s'adresse aux responsables de flux et aux équipes paid media qui lancent des soldes sur Google Shopping. À la fin, vous saurez parcourir huit vérifications dans l'ordre, identifier celle qui échoue et la corriger dans le flux plutôt que dans la boutique.

Ce que signifie réellement « ne s'affiche pas »

Trois défaillances différentes sont signalées sous la formule « le prix soldé ne s'affiche pas », et elles appellent des corrections différentes.

• Le produit est refusé. Merchant Center vous en informe. Le prix soldé enfreint une exigence sur les données, par exemple parce qu'il n'était pas inférieur à price ou qu'il ne correspondait pas à la page de destination.
• Le produit est approuvé, mais l'acheteur voit le prix soldé sans prix barré ni badge. Les données sont valides, mais les règles d'éligibilité à l'annotation ne sont pas remplies.
• Le produit affiche l'ancien prix. Les soldes ne sont jamais parvenus à Google, ont expiré, ou n'ont jamais été programmés correctement.

Google indique clairement que l'affichage des annotations de prix promotionnel n'est pas toujours garanti, même si vous êtes éligible. L'objectif de ce guide est donc de supprimer toutes les causes que vous maîtrisez, et d'être honnête sur l'incertitude qui subsiste.

Le diagnostic en huit vérifications

Effectuez-les dans l'ordre. Les quatre premières sont des contrôles de données que vous pouvez faire à partir du seul flux. Les quatre dernières nécessitent l'historique des prix, la page de destination ou les paramètres du compte.

Vérification 1 : price et sale_price sont dans le bon sens

La règle de Google est simple : sale_price doit être inférieur à price, et cet écart doit être visible dans vos données produits. Un cas d'échec typique est celui d'une plateforme e-commerce qui exporte le montant déjà remisé dans price et laisse sale_price vide ou identique. Google demande aux marchands de renseigner le prix complet, hors promotion, dans price, et de ne mettre le prix soldé dans price que si vous n'utilisez pas du tout sale_price.

Un couple correct ressemble à ceci :

price: 1000.00 TRY
sale_price: 799.00 TRY

Arrondissez à deux décimales dans le flux, car Google arrondit lui-même les chiffres supplémentaires et le résultat peut diverger de celui de la page.

Vérification 2 : le pourcentage de remise

Calculez le pourcentage sur chaque ligne en promotion avant de publier : (price - sale_price) / price. Google exige qu'il soit supérieur à 5 % et inférieur à 90 %. Dans l'exemple ci-dessus, il est de 20,1 %, ce qui est valide. Une remise de 3 % n'aura jamais d'annotation, pas plus qu'une ligne à 92 %, qui est de toute façon généralement une erreur de données.

Vérification 3 : le format de sale_price_effective_date

L'attribut est une plage de dates au format ISO 8601 avec un début et une fin, séparés par une barre oblique. Le modèle documenté par Google est YYYY-MM-DDThh:mm[±hhmm] ou YYYY-MM-DDThh:mmZ, avec une limite de 51 caractères. Une période de Black Friday pour une boutique à Istanbul ressemble à ceci :

sale_price_effective_date: 2026-11-20T00:00+0300/2026-11-30T23:59+0300

Deux valeurs par défaut comptent. Si vous omettez l'heure, la promotion commence à minuit à la date de début et se termine à 23 h 59 à la date de fin. Si vous omettez le fuseau horaire, Google utilise UTC. Une boutique turque qui écrit 2026-11-20T00:00 sans décalage démarre ses soldes avec trois heures de retard pour les acheteurs en Turquie, et une boutique de la région MENA à Dubaï (UTC+4) perd quatre heures. Indiquez toujours le décalage.

Validez aussi les dates : la page d'aide de Google contient elle-même un exemple avec un 29 février d'une année non bissextile, alors testez les exemples avant de les copier.

Vérification 4 : envoyer les deux attributs de promotion

Pour les flux de mise à jour des stocks en ligne, Google indique que sale_price et sale_price_effective_date doivent être fournis ensemble ou pas du tout, et que n'envoyer que le prix signifie que l'article n'a pas été importé. Pour les flux de données produits ordinaires, la date est facultative, mais nous l'envoyons pour chaque promotion programmée afin que la fin soit explicite.

Vérification 5 : l'historique du prix de base

Cette vérification est facile à manquer, et elle peut laisser une ligne de promotion valide sans annotation. Google exige que le prix de base ait été appliqué pendant une durée minimale. Les chiffres ci-dessous sont ceux de la page de Google au moment de la rédaction.

La Turquie n'apparaît pas dans ces listes. Nous ne pouvons pas déduire de la page ce qui s'applique à un compte turc : vérifiez donc le statut de vos propres produits dans Merchant Center plutôt que de supposer que les 30 jours s'appliquent ou non.

La conséquence pratique concerne le séquencement. Un nouveau produit lancé à 1 000 TRY le 1er novembre ne peut pas porter d'annotation de promotion le 10 novembre dans un pays soumis à la règle des 30 jours sur 200. Un produit dont le prix a été relevé pendant une semaine juste avant une campagne peut échouer au même test, car le prix de base n'a pas été appliqué assez longtemps. Si votre calendrier de promotions dépend des annotations, protégez le prix de base pendant les semaines qui précèdent.

Vérification 6 : la page de destination

Google exige que le prix d'origine et le prix soldé soient affichés sur la page de destination, et la valeur de sale_price doit correspondre au prix indiqué sur la page et au moment du paiement. Si la fiche produit n'affiche que le montant remisé et que le prix barré est ajouté plus tard par un script qui ne s'exécute pas pour Googlebot, le flux et la page ne concordent pas. Vérifiez la présence des deux prix dans le HTML rendu. Notre précédent guide sur comment empêcher Google de remplacer les données de prix de votre flux explique ce qui se passe quand la page et le flux divergent.

Vérification 7 : ce qui n'a pas sa place dans sale_price

Google exclut trois choses. Les remises par code promo relèvent des paramètres de remise de la boutique, pas de sale_price. Les prix fidélité et membres vont dans loyalty_program. Et les prix promotionnels envoyés sous forme de promotions Merchant Center ne comptent pas comme des prix soldés pour les annotations. Si votre campagne est « 10 % de plus dans le panier », c'est une promotion, et le prix du flux reste inchangé.

Vérification 8 : Google a-t-il lu la modification ?

Une récupération programmée peut créer un décalage. La page d'intégration Google Merchant Center de Feedance indique que Merchant Center peut relire un flux hébergé toutes les heures, tous les jours, toutes les semaines ou tous les mois, et que les catalogues dont les prix changent rapidement peuvent avoir besoin de mises à jour par API à la place. Après toute modification de promotion, ouvrez le produit dans Merchant Center, confirmez que le prix affiché est le nouveau, et seulement ensuite jugez si l'annotation est absente.

Un exemple concret avec historique de prix

Il s'agit d'une ligne hypothétique, pas de données client. Une veste est listée à 1 000,00 TRY. Le 10 novembre, elle passe à 800,00 TRY pour une semaine, revient à 1 000,00 TRY le 17 novembre, puis est proposée à 700,00 TRY pour le Black Friday le 27 novembre.

price: 1000.00 TRY
sale_price: 700.00 TRY
sale_price_effective_date: 2026-11-27T00:00+0300/2026-11-30T23:59+0300

Le flux passe les vérifications 1 à 4 : la remise est de 30 %, les dates sont valides et le décalage horaire est présent. Pour le test de prix de base de Google, le produit a été facturé 1 000 TRY pendant la majeure partie de la période de référence, il a donc de bonnes chances de passer la vérification 5 dans un pays soumis à la règle des 30 jours sur 200. La règle turque est un test différent, et c'est celui qui épingle cette ligne. Depuis l'amendement publié au Resmi Gazete du 18 février 2022 (numéro 31754), entré en vigueur le 1er mars 2022, le prix avant remise pour une vente avec remise est le prix le plus bas pratiqué dans les 30 jours précédant la remise, d'après le résumé de l'amendement par KPMG. Ici, le prix le plus bas des 30 jours précédents est de 800 TRY : la remise réelle par rapport à cette référence est donc de 12,5 %, et non de 30 %. La charge de la preuve des faits relatifs à la remise incombe au vendeur. Un flux qui barre 1 000 TRY sur la page de destination alors que la semaine à 800 TRY figure dans l'historique des prix pose un problème réglementaire, même si Google affiche l'annotation.

Quel que soit le marché, l'élément qui aide pour les deux tests est un relevé quotidien du prix réellement pratiqué pour chaque SKU.

Checklist de pré-lancement pour un flux de promotions

1. Exportez price, sale_price et sale_price_effective_date pour chaque SKU en promotion.
2. Calculez le pourcentage de remise et signalez tout ce qui est inférieur ou égal à 5 %, ou supérieur ou égal à 90 %.
3. Signalez les lignes sans décalage de fuseau horaire.
4. Croisez avec votre historique de prix et signalez les SKU dont le prix de base a été modifié au cours des 30 derniers jours.
5. Affichez dix pages produits en échantillon et confirmez que les deux prix sont visibles sans interaction de l'utilisateur.
6. Confirmez qu'aucun code promo ni prix fidélité n'a été écrit dans sale_price.

Mesurer l'effet de l'annotation

Ne partez pas du principe qu'un prix barré améliore les résultats. Comparez des groupes de produits équivalents sur les mêmes dates, en suivant la méthode de notre guide sur la mesure de l'impact d'une modification de flux sur le ROAS. Si le format des montants en TRY, AED ou SAR est incohérent, corrigez-le d'abord ; consultez notre guide sur les erreurs de TVA, de devise et de décimales.

Les limites de ce guide

Nous nous sommes appuyés sur les pages d'aide de Google telles qu'elles étaient rédigées lors de notre vérification, et Google modifie ces exigences. Nous n'avons pas pu confirmer ce qui s'applique aux comptes turcs, car la Turquie est absente des listes de pays de la page sur les annotations. Nous ne voyons pas l'intérieur de votre compte Merchant Center : l'éligibilité peut donc différer de ce que suggèrent les règles, et Google dit lui-même que les annotations ne sont pas garanties. Nous n'avons pas non plus traité Meta ni les autres canaux, dont les champs de prix promotionnel obéissent à des règles distinctes. La section sur la réglementation turque repose sur un résumé secondaire, et non sur le texte du Resmi Gazete ; elle ne constitue pas un conseil juridique : confirmez auprès d'un avocat. Channable publie sa propre explication des annotations de prix promotionnel, qui mérite d'être lue en parallèle.

Questions fréquentes

Pourquoi mon sale_price est-il approuvé alors qu'il n'y a pas de prix barré ?

L'approbation ne vérifie que la validité des données. L'annotation a des conditions supplémentaires : une remise supérieure à 5 % et inférieure à 90 %, un prix de base valide depuis assez longtemps pour votre pays, et les deux prix visibles sur la page de destination. Commencez par les vérifications 2, 5 et 6.

Ai-je besoin de sale_price_effective_date ?

Pour les flux de données produits ordinaires, il est facultatif. Dans les flux de mise à jour des stocks en ligne, Google indique que les deux attributs de promotion doivent être envoyés ensemble. Nous recommandons de l'envoyer pour chaque promotion programmée afin que la fin de la promotion soit explicite.

Puis-je mettre une remise par code promo dans sale_price ?

Non. Google demande de gérer les remises par code promo dans les paramètres de remise de la boutique. Les prix fidélité et membres vont plutôt dans l'attribut loyalty_program.

Une promotion Merchant Center crée-t-elle une annotation de promotion ?

Non. Google indique que les prix promotionnels envoyés sous forme de promotions ne comptent pas. Utilisez l'attribut sale_price pour les annotations de promotion, et les promotions pour des offres telles que les remises sur le panier.

Depuis combien de temps le prix d'origine doit-il être en ligne ?

Dans la plupart des pays où les annonces Shopping sont disponibles, Google indique 30 jours au cours des 200 derniers. Aux États-Unis, pour les annonces Shopping, c'est 5 jours au cours des 30 derniers ou 15 jours au cours des 200 derniers. Les annonces sur les produits en magasin exigent 60 jours.

Pourquoi la remise que j'affiche diffère-t-elle de celle prévue par la loi turque ?

Google teste le prix de base que vous avez pratiqué. Les règles turques, telles que résumées par KPMG, fixent la référence au prix le plus bas des 30 jours précédant la remise. Une baisse temporaire peut abaisser le prix de référence par rapport auquel vous pouvez légalement communiquer.

Vérifiez votre propre flux

Si vous souhaitez un regard extérieur sur les attributs de prix de votre flux, passez-le dans l'outil gratuit d'audit de flux produits Feedance.