Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Prix barrés, livraison et disponibilité dans un flux produits

Trois attributs de flux produits concentrent la majorité des rejets et des affichages incorrects que je corrige : le prix soldé (sale_price), les frais et délais de livraison (shipping), et la disponibilité (availability). Ce ne sont pas des attributs annexes : mal renseignés ou désynchronisés du site réel, ils déclenchent une désapprobation ou affichent une information fausse à l’acheteur.

Décrire mon problème Discuter sur WhatsApp

Les situations que je traite

  • Une promotion terminée sur le site mais un prix barré qui continue d’apparaître dans l’annonce
  • Des frais de livraison affichés dans l’annonce différents de ceux appliqués réellement au paiement
  • Un produit en rupture sur le site mais encore annoncé disponible
  • Une date de fin de promotion mal renseignée qui fait disparaître ou réapparaître le prix soldé au mauvais moment
  • Des frais de port qui varient par pays sans que le flux ne le reflète
  • Une désapprobation Merchant Center pointant un de ces trois attributs sans comprendre lequel corriger en premier

Comment je vérifie ces trois attributs

  1. Contrôle du prix soldé et de ses dates

    Je vérifie que sale_price correspond exactement au prix réellement appliqué au paiement, et que sale_price_effective_date encadre bien la période de validité de la promotion. Une date de fin dépassée qui n’est pas retirée du flux fait apparaître un prix soldé qui n’existe plus sur le site. Je vérifie aussi que le décalage horaire est écrit explicitement (+0200 en heure d’été française, +0100 en hiver) : sans lui, Google interprète les dates en UTC et la promotion se termine deux heures trop tôt.

  2. Vérification des frais et délais de livraison

    Je contrôle le sous-champ shipping et ses composantes : le pays de livraison couvert, le service proposé, le prix facturé et le délai annoncé. Un flux qui ne détaille pas ces sous-champs par marché affiche des frais identiques pour toutes les destinations, même quand ce n’est pas le cas.

  3. Alignement de la disponibilité sur le stock réel

    Je vérifie que l’availability reflète l’état réel du produit au moment où Google explore la page : en stock, en rupture, ou en précommande selon le cas, et jamais un état figé lors de la dernière génération du flux.

  4. Confrontation avec la page produit

    Pour chacun des trois attributs, je compare ce que le flux transmet avec ce qui est réellement affiché sur la fiche produit, y compris un éventuel balisage schema.org qui pourrait contredire l’un ou l’autre.

  5. Programmation d’une actualisation régulière

    Je m’assure que ces trois attributs, plus que les autres, sont recalculés à chaque actualisation du flux : ce sont ceux qui changent le plus souvent au fil d’une boutique en activité.

Pourquoi ces trois attributs posent le plus de problèmes

Le prix, la livraison et la disponibilité ont un point commun : ce sont les attributs qui bougent le plus souvent sur une boutique active, parfois plusieurs fois par jour. Un attribut statique comme la description reste correct des mois durant ; ces trois-là se périment vite si le flux n’est pas resynchronisé au même rythme que le site.

Un sale_price mal daté affiche un prix soldé après la fin réelle de l’offre. Un shipping non détaillé par pays donne une estimation de frais incorrecte avant même que l’acheteur n’arrive sur le site. Une availability désynchronisée fait cliquer un acheteur sur une annonce pour un produit qui n’est plus disponible. Dans les trois cas, la conséquence dépasse la désapprobation technique : c’est une expérience d’achat dégradée qui nuit à la confiance.

flux-google.xml
<item>
  <g:id>REF-0001</g:id>
  <g:price>39.90 EUR</g:price>
  <g:sale_price>29.90 EUR</g:sale_price>
  <g:sale_price_effective_date>2026-07-01T00:00+0200/2026-07-31T23:59+0200</g:sale_price_effective_date>
  <g:availability>in_stock</g:availability>
</item>

Pages liées

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Quel outil faut-il connecter ?
L’outil dispose-t-il d’une API documentée ?

Sans API, il reste souvent l’import de fichiers — c’est faisable, mais différent.

Dans quel sens les données doivent-elles circuler ?
À quelle fréquence la synchronisation doit-elle tourner ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Quelle est la différence entre price et sale_price ?
price est le prix normal du produit, sale_price le prix promotionnel effectivement appliqué. Les deux doivent être transmis ensemble pour que Google affiche le prix barré correctement.
Que se passe-t-il si sale_price_effective_date n’est pas mis à jour ?
Le prix soldé peut continuer à s’afficher après la fin réelle de la promotion, ou ne pas apparaître à temps quand elle démarre, selon la date renseignée dans le flux.
Faut-il détailler les frais de livraison par pays ?
Oui dès que les frais ou délais varient réellement selon la destination : le sous-champ shipping permet de préciser pays, service, prix et délai séparément.
Quelles valeurs sont attendues pour availability ?
L’attribut doit refléter l’état réel du produit, typiquement en stock, en rupture ou en précommande, et correspondre au stock affiché sur la page au moment où Google l’explore.
Ces attributs sont-ils les mêmes sur toutes les plateformes de flux ?
Les noms et le principe sont proches d’une plateforme à l’autre, mais chacune a ses propres règles de format ou de valeurs acceptées, comme le montrent les pages consacrées à Pinterest et à Meta.

Pages liées