À 8 h 01, le bandeau « offre rentrée » est en ligne. La fiche affiche 79 € au lieu de 99 €. Pourtant, le code source annonce encore 99 €, une déclinaison remonte à 89 € et le flux marchand conserve les dates de la campagne précédente.
Pour le client, c’est une incohérence. Pour Google, ce sont plusieurs sources qui racontent des histoires différentes.
La mise à jour récente de la documentation Google rend le contrôle plus concret : une période de prix promotionnel peut être décrite avec validFrom, validThrough ou priceValidUntil, avec date, heure et fuseau. Mais ajouter trois propriétés JSON-LD ne répare ni un mauvais prix de référence, ni un cache périmé, ni une déclinaison mal reliée.
Avant une promotion française — soldes, vente privée, Black Friday ou simple remise saisonnière — il faut donc vérifier une chaîne complète : ce que voit l’acheteur, ce que produit le thème, ce qu’envoie le flux et ce que les outils Google arrivent réellement à lire.
Les trois vérités d’un prix promotionnel
Une fiche produit possède rarement une seule source de prix. Le contrôle utile compare trois niveaux.
| Niveau | Question à poser | Preuve à conserver |
|---|---|---|
| Page visible | le client voit-il le bon prix actif, le bon prix antérieur et les conditions de l’offre ? | capture datée sur mobile et ordinateur |
| Données structurées | le Product et son Offer décrivent-ils le même prix, la même devise, la même disponibilité et la bonne période ? | JSON-LD extrait et résultat du test Google |
| Sources marchandes | le flux ou l’API Merchant Center envoie-t-il les mêmes valeurs et dates ? | aperçu de l’article et diagnostic de la source de données |
La règle de base est simple : le prix actif dans les données doit être le prix réellement payable sur la page. La devise doit être EUR pour une offre en euros. La disponibilité ne doit pas annoncer InStock si la variante sélectionnée est épuisée.
Google distingue désormais explicitement le prix actif, le prix barré et le prix membre dans sa documentation des fiches de marchand. Pour une promotion, le prix actif ne reçoit pas de priceType. Le prix antérieur est porté par un UnitPriceSpecification identifié comme https://schema.org/StrikethroughPrice. Si offers.price et un prix actif dans priceSpecification sont tous deux présents, Google indique privilégier offers.price : une duplication contradictoire ne crée donc pas un compromis, elle crée un mauvais signal prioritaire.
En France, le prix barré est aussi une donnée réglementée
Le balisage technique n’autorise pas à choisir librement le chiffre le plus flatteur. La DGCCRF rappelle que, lorsqu’un professionnel annonce une réduction, le prix antérieur à indiquer est en principe le prix le plus bas pratiqué durant les trente jours précédant l’offre. Cette obligation concerne les annonces en ligne comme hors ligne.
Il faut distinguer deux contrôles :
- conformité commerciale : le prix barré correspond-il au bon prix de référence pour cette offre et ce produit ?
- cohérence technique : la page, les données structurées et les sources Google transmettent-elles ce même prix sans ambiguïté ?
Une implémentation JSON-LD peut être syntaxiquement valide tout en reprenant un prix antérieur juridiquement inadapté. À l’inverse, un prix correctement calculé peut être mal compris si le thème l’insère dans le mauvais objet ou si le flux continue d’envoyer une ancienne valeur. En cas de doute sur une situation particulière — réductions successives, produits périssables, prix membre ou offre conditionnelle — faites valider la règle applicable ; un audit SEO ne remplace pas un conseil juridique.
Donner un début et une fin réels à la promotion
Google recommande de fournir le début et la fin de la période, au format ISO 8601, heure et fuseau inclus. Pour une promotion française commençant le 10 septembre à 8 h et finissant le 20 septembre à 23 h 59, les valeurs doivent exprimer le fuseau utilisé, par exemple +02:00 à cette période, et non une date flottante interprétable différemment.
Lorsque le prix promotionnel actif se trouve dans Offer.price, les dates peuvent être placées sur l’Offer :
{
"@type": "Offer",
"price": 79.00,
"priceCurrency": "EUR",
"validFrom": "2026-09-10T08:00:00+02:00",
"priceValidUntil": "2026-09-20T23:59:59+02:00",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": 99.00,
"priceCurrency": "EUR",
"priceType": "https://schema.org/StrikethroughPrice"
}
}Si le prix actif est décrit dans un UnitPriceSpecification, utilisez validFrom et validThrough sur cet objet ; Google précise que priceValidUntil ne s’applique pas au type PriceSpecification.
Ce fragment est un modèle de lecture, pas un bloc à coller aveuglément. L’URL, le stock, le SKU, les variantes et le reste du Product doivent rester adaptés à la fiche. Surtout, la logique qui retire la promotion doit être testée avant son lancement. Une date expirée laissée dans priceValidUntil peut empêcher l’affichage d’un extrait produit, tandis qu’un ancien prix promo encore actif dans le code peut contredire la page.
Les erreurs qui survivent au test visuel
Le thème affiche le bon montant, le JSON-LD lit la base de données brute
Un plugin de remise ou une règle catalogue calcule 79 € dans le HTML, mais le générateur de données structurées interroge le prix standard à 99 €. La fiche semble correcte jusqu’à l’inspection du code rendu.
Le fuseau décale la campagne
Le back-office enregistre l’heure française, le serveur travaille en UTC et le flux omet le fuseau. La promotion peut alors sembler commencer ou finir deux heures trop tôt. Testez les instants de bascule, pas uniquement le milieu de la période.
Le cache sert deux versions de la vérité
La page produit, son JSON-LD, l’API et le flux ne partagent pas toujours le même cache. Une purge partielle peut actualiser le prix visible sans actualiser le script structuré. Vérifiez une URL publique froide après déploiement, puis le rendu mobile et ordinateur.
La déclinaison sélectionnée n’est pas celle balisée
Une chaussure à 79 € en taille 42 ne permet pas d’annoncer ce prix et InStock à toutes les tailles. Pour approfondir l’identification des variantes, la livraison et les retours, consultez notre guide plus large sur les fiches produits et données structurées Google. Ici, la règle promotionnelle reste : chaque offre balisée doit correspondre à une combinaison réellement achetable.
Le flux marchand gagne la course contre le site
Merchant Center accepte un sale_price et une période sale_price_effective_date. Si ces valeurs contredisent la page ou ses données structurées, des mises à jour automatiques peuvent intervenir ou le produit peut rencontrer des problèmes de cohérence. Les annotations de prix soldé ne sont jamais garanties, même lorsque les conditions sont remplies.
Trois fiches, trois contrôles rapides
Produit simple en promotion
- prix actif identique dans la page,
Offeret source marchande ; - prix barré identique à celui affiché et conforme à la règle de référence applicable ;
- devise
EUR, URL canonique et disponibilité exactes ; - début, fin, heure et fuseau renseignés ;
- scénario automatique de retour au prix normal testé.
Produit avec déclinaisons
- offre testée pour une déclinaison soldée et une non soldée ;
- SKU, URL ou paramètre de variante stables ;
- prix et stock mis à jour après changement de taille, couleur ou capacité ;
- aucune fourchette trompeuse ne masque une variante indisponible ;
- canonique et indexation cohérents avec la stratégie de variantes.
Produit soldé puis épuisé
availabilitypasse à la bonne valeur sans conserverInStock;- le bouton d’achat et le prix visible racontent la même situation ;
- le flux marchand est actualisé ;
- la fin de promotion ne restaure pas artificiellement un stock ;
- les données promotionnelles périmées sont supprimées, pas seulement cachées en CSS.
L’audit de vingt minutes avant ouverture
Minutes 0 à 4 — choisir les cas qui peuvent casser. Prenez un produit simple, une déclinaison en promotion, une déclinaison non remisée et un article en stock faible ou épuisé. Ajoutez un produit soumis à une règle spéciale si le catalogue en utilise.
Minutes 5 à 9 — acheter comme un client. Ouvrez chaque fiche dans une session sans cache, sur mobile puis ordinateur. Changez de variante, ajoutez au panier et vérifiez le total. Photographiez le prix actif, le prix antérieur, la disponibilité et les conditions visibles.
Minutes 10 à 13 — lire la machine. Extrayez le JSON-LD rendu, pas seulement le template source. Comparez montant, devise, stock, SKU, URL, validFrom et date de fin. Lancez le test des résultats enrichis. Un test valide confirme la forme du balisage ; il ne garantit ni l’affichage enrichi ni le classement.
Minutes 14 à 17 — ouvrir la source marchande. Contrôlez l’aperçu de l’article, price, sale_price, sale_price_effective_date et les diagnostics. Si une mise à jour automatique de prix est active, ne la considérez pas comme un substitut à une source correcte.
Minutes 18 à 20 — simuler la sortie. Dans une préproduction ou avec une horloge de test, dépassez l’heure de fin. Le prix normal, le balisage, le flux et le cache doivent basculer ensemble. Désignez la personne qui vérifiera un échantillon public au lancement et après clôture.
Corriger une fiche ou reprendre le gabarit ?
Une correction ciblée suffit lorsque l’erreur concerne une règle de campagne isolée, que les sources de prix sont identifiées et que le thème produit déjà un Product propre. Documentez le changement, testez les cas limites et planifiez son retrait.
Il faut envisager une reprise du gabarit lorsque plusieurs extensions émettent des objets Product, que les variantes n’ont pas d’identité stable, que le prix visible et le JSON-LD suivent des calculs différents ou que chaque promotion exige une correction manuelle. Notre accompagnement en création et évolution de site e-commerce à Lyon traite ce type de problème à la source ; un travail d’optimisation SEO à Lyon peut ensuite cadrer la validation et la surveillance.
Toute modification de thème, plugin ou application doit avoir un retour arrière borné : sauvegarde ou commit identifié, liste des fichiers et réglages touchés, procédure de restauration, test du panier après rollback et personne autorisée à décider. On ne découvre pas le bouton « revenir en arrière » à l’ouverture d’une campagne.
La preuve attendue n’est pas une capture verte
Le livrable utile tient dans un petit dossier : quatre URL représentatives, captures avant/après, JSON-LD rendu, résultats des tests Google, aperçu Merchant Center, résultat panier et preuve du test de fin de campagne. Ajoutez les anomalies restantes, leur propriétaire et leur date de correction.
Les données structurées rendent une offre compréhensible par les systèmes ; elles ne promettent pas un résultat enrichi, une annotation de prix soldé, une approbation Shopping ou une meilleure position. Google choisit les présentations qu’il affiche et peut faire évoluer ses traitements.
Vous préparez une opération commerciale et ne savez pas si le thème, les déclinaisons et le flux racontent la même chose ? Demandez un audit borné de vos pages produit : 1Design peut contrôler un échantillon représentatif, documenter les écarts et proposer le plus petit plan de correction vérifiable. Pour cadrer la campagne, contactez 1Design avec votre plateforme, les dates de l’offre et trois URL produit.
Notes de recherche et sources officielles
- Google Search Central, « Merchant listing structured data » : types de prix,
StrikethroughPrice, périodes avecvalidFrom,validThroughetpriceValidUntil, placement des propriétés et absence de garantie d’affichage — consultation le 1er septembre 2026 : https://developers.google.com/search/docs/appearance/structured-data/merchant-listing - Google Search Central, « Product structured data » et « Product snippet structured data » : distinction fiche marchand/extrait produit, sources de données, disponibilité et effet d’une date de validité expirée — consultation le 1er septembre 2026 : https://developers.google.com/search/docs/appearance/structured-data/product et https://developers.google.com/search/docs/appearance/structured-data/product-snippet
- Google Merchant Center, « Prix soldé [sale_price] » et « À propos des annotations sur le prix soldé » :
sale_price_effective_date, cohérence de la page de destination et absence de garantie d’annotation — consultation le 1er septembre 2026 : https://support.google.com/merchants/answer/6324471?hl=fr et https://support.google.com/merchants/answer/9017019?hl=fr - DGCCRF, « Annonces de réduction de prix : ce que vous devez savoir » : prix le plus bas pratiqué durant les trente jours précédents et application aux ventes en ligne — consultation le 1er septembre 2026 : https://www.economie.gouv.fr/dgccrf/les-fiches-pratiques/annonces-de-reduction-de-prix-ce-que-vous-devez-savoir
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?