Produits refusés dans Merchant Center : vérifier prix et disponibilité
Découvrez comment comparer une offre refusée dans Merchant Center avec sa vraie fiche produit, son prix, ses variantes et son état de stock.
Un produit refusé dans Google Merchant Center pour un écart de prix ou de disponibilité doit être examiné comme une offre précise. Cette méthode compare l'identifiant de l'article, son flux, la déclinaison ouverte, la fiche visible et les données Product/Offer. Deux exemples fictifs et un tableau de diagnostic aident à choisir l'étape suivante sans modifier inutilement le reste du catalogue.
Que signifie le refus d'un article dans Merchant Center ?
Une fiche produit peut sembler parfaitement normale sur une boutique en ligne et figurer pourtant parmi les articles refusés dans Google Merchant Center. Cette situation devient plus claire lorsqu'on distingue les différentes représentations d'une même offre. Google reçoit un identifiant d'article, une URL de destination, un prix, une devise et un état de disponibilité. La page cible peut, elle, afficher plusieurs déclinaisons, un prix promotionnel ou des informations techniques supplémentaires.
Commencez dans Merchant Center par ouvrir la fiche précise qui nécessite une intervention. Lisez le motif indiqué pour cet article. Un avertissement n'est pas identique à un refus, et un problème limité à une offre se distingue d'une difficulté concernant tout le compte. Un écart de prix exige de vérifier le montant lié à la bonne variante ; une disponibilité inexacte exige de vérifier la possibilité d'acheter la déclinaison annoncée. Les autres messages suivent leur propre logique.
Relevez l'identifiant de l'article, sa source de données, le pays visé et le champ mentionné dans le diagnostic. Travaillez d'abord sur une seule offre. Une réexportation générale du catalogue est peu utile si personne ne sait quel produit ou quel champ présente l'écart. Dans une boutique multilingue, deux fiches visuellement semblables peuvent correspondre à des offres différentes selon le pays, la langue ou la devise.
Posez ensuite une question simple : lorsqu'un visiteur suit exactement ce lien, quelle déclinaison est sélectionnée, quel prix voit-il et peut-il réellement commander ? Ces trois observations sont plus précises qu'un contrôle rapide de l'image ou du titre de produit. Une page présentant la bonne famille de produits ne représente pas nécessairement la taille ou la couleur de l'article transmis à Google.
Les écarts de prix et de disponibilité se traitent séparément. Une variante peut afficher le bon prix tout en étant épuisée, alors que le flux l'annonce disponible. À l'inverse, le stock peut être correct mais le prix promotionnel transmis n'a pas été actualisé. Le résultat utile est donc un constat concret : pour tel identifiant, telle valeur diffère entre la source et la page publique.
Identifier l'offre exacte, sa variante et son pays cible
Un groupe de produits n'est pas toujours une offre unique. Prenons un vêtement décliné en plusieurs tailles : le modèle peut être disponible en M et épuisé en XL. Le simple affichage du libellé « en stock » sur la fiche principale ne suffit pas à établir que la variante XL est commandable. La comparaison doit suivre l'identifiant individuel envoyé au Merchant Center.
Copiez l'URL de destination qui accompagne précisément cet identifiant. Ouvrez-la dans une session visiteur ordinaire, sans connexion administrateur. Regardez la couleur, la taille, le lot ou la caractéristique présélectionnée. Si l'article de la source porte sur XL mais que la page ouvre M, les prix et les stocks observés concernent deux offres différentes. Corrigez d'abord cette correspondance.
Consignez l'identifiant du produit, l'identifiant du groupe lorsqu'il existe, les caractéristiques de la variante, la devise et le pays cible. Lorsque des paramètres d'URL sélectionnent une déclinaison, vérifiez qu'ils fonctionnent à l'ouverture. Si la boutique utilise une page distincte par variante, vérifiez le chemin complet. Ni la photo commune ni le nom commercial ne remplacent cette identification.
Testez ensuite le parcours d'achat visible. Le bouton d'ajout au panier est-il disponible pour l'option affichée ? Une autre taille modifie-t-elle le prix et le message de stock ? La page se charge-t-elle avec la bonne sélection avant toute intervention du visiteur ? Cette dernière question compte particulièrement lorsque le flux pointe vers une variante précise, mais que la boutique remet systématiquement la sélection sur la première option.
Pour un article ciblant la France, comparez la ligne de données visant ce pays avec la version effectivement proposée aux visiteurs concernés. Une autre version nationale peut présenter une devise, un assortiment ou un stock différent. Le diagnostic ne consiste pas à rendre toutes les boutiques nationales identiques ; il consiste à faire correspondre chaque offre transmise à sa véritable page d'arrivée.
Comparer le prix et le stock dans chaque représentation de l'offre
Alignez cinq éléments pour l'offre examinée : la donnée commerciale maintenue dans la boutique, la ligne exportée dans le flux, la variante activée par l'URL, les informations visibles par le visiteur et les éventuelles données structurées Product/Offer. Lorsque ces éléments décrivent une seule et même offre, la comparaison devient vérifiable. Lorsqu'ils divergent, le champ exact oriente la correction.
Pour le prix, vérifiez le montant ordinaire, le prix promotionnel lorsqu'il s'applique, la devise et le moment où l'offre est active. Une promotion peut commencer sur la fiche avant l'actualisation du flux. Inversement, le flux peut encore contenir un ancien tarif réduit après la fin d'une opération. Une fourchette de prix affichée pour tout le groupe ne doit pas masquer le montant de la variante réellement sélectionnée.
Pour le stock, comparez la valeur availability avec la possibilité d'acheter cette variante. Les états in_stock et out_of_stock correspondent à des réalités différentes. Les situations de preorder et de backorder concernent des modes de vente spécifiques, qui doivent également être cohérents avec la présentation sur la page. Le stock d'une autre couleur ne détermine pas celui de l'article concerné.
Examinez aussi les données structurées lorsqu'elles sont présentes. Un bloc Offer peut publier price, priceCurrency et availability dans le HTML. Le prix affiché peut avoir été mis à jour alors que le JSON-LD conserve l'ancienne valeur. Le test des résultats enrichis de Google aide à lire ces données techniques ; il vient compléter la consultation de la page publique et de la ligne de flux, et non les remplacer.
Les horodatages expliquent une partie des différences. Notez la date de modification du prix dans le catalogue, la date de génération de la source et celle de son dernier traitement. Si ces instants diffèrent, vous savez où regarder en premier. Si les valeurs restent opposées après plusieurs synchronisations, il devient utile d'identifier les traitements qui génèrent chaque représentation de l'offre.
Une bonne note de diagnostic comporte l'identifiant, la valeur trouvée dans la source, la valeur visible, la valeur du balisage lorsqu'il existe et le moment de la consultation. La phrase « le prix n'est pas bon » laisse beaucoup de place à l'interprétation. « Cette variante affiche 54 € alors que sa ligne de flux contient 49 € » donne au contraire une action immédiatement vérifiable.
Tableau de diagnostic : symptôme, comparaison et action
| Symptôme | Comparer d'abord | Action suivante | Vérification |
|---|---|---|---|
| Écart de prix | Prix du flux, devise, variante et prix visible | Corriger la source de l'offre concernée | Même variante et même montant sur la page et dans les données |
| Promotion différente | price, sale_price et période active | Aligner la promotion de la boutique et celle du flux | Prix promotionnel cohérent dans les deux représentations |
| Disponibilité différente | Stock de la variante, availability et bouton d'achat | Mettre à jour l'état de cette variante | La disponibilité annoncée correspond à l'achat réel |
| Mauvaise déclinaison ouverte | Identifiant, URL et sélection initiale | Corriger le lien vers l'option exacte | La page ouvre l'option transmise dans le flux |
| Page visuellement correcte | JSON-LD, HTML mis en cache et horaires de mise à jour | Rechercher une représentation technique ancienne | Les données structurées et visibles concordent |
| Autre motif de refus | Message exact de Merchant Center | Vérifier le champ ou la condition réellement signalés | Le statut de cet article est relu après correction |
Utilisez ce tableau sur un article à la fois. Lorsque plusieurs variantes présentent le même message, ne concluez pas immédiatement que toutes souffrent de la même cause. Une URL mal paramétrée peut concerner une seule déclinaison, tandis qu'une synchronisation de promotion peut toucher une catégorie entière. La preuve observée détermine le périmètre utile de l'intervention.
Priorisez les informations qui influencent immédiatement l'achat : l'option ouverte, le prix correspondant et la possibilité de commander. Vérifiez ensuite la synchronisation et le balisage technique. Réimporter un fichier inchangé ne corrige pas une mauvaise URL, et modifier un texte visible ne répare pas un ancien prix conservé dans une autre source.
Exemple 1 : un prix promotionnel absent du flux
Exemple entièrement fictif. Une boutique de luminaires propose une lampe de bureau noire et blanche. Le modèle noir coûte normalement 89 €, mais une promotion en cours le propose à 79 €. La fiche publique affiche bien 79 € avec le noir sélectionné. Le flux, généré avant le début de l'opération, contient toujours 89 € pour cet article. La version blanche reste à 89 €. Ces montants illustrent uniquement la méthode de contrôle.
L'article concerné par la notification Merchant Center est la variante noire. Le responsable relève son identifiant, suit le lien de destination et vérifie que la couleur noire est réellement présélectionnée. Il compare ensuite les champs price et sale_price du flux aux montants présents sur la page. La différence devient précise : la promotion est active sur la boutique, mais les données transmises décrivent encore l'ancien état.
Le bon travail consiste à synchroniser la source commerciale et sa publication. Les dates de début et de fin de l'offre, le prix ordinaire et le prix réduit doivent représenter la même période. Corriger uniquement l'étiquette graphique sans traiter l'export reviendrait à conserver deux valeurs différentes. Il est préférable que les deux canaux dépendent du même état actuel de l'article.
Vérifiez également le lien. Si le flux de la variante noire dirige par erreur vers la lampe blanche, les montants peuvent sembler égaux tout en décrivant un autre produit. La photo et le titre étant semblables, cette erreur peut passer inaperçue. L'identifiant, la sélection initiale, le montant et les éventuelles données Product/Offer doivent tous correspondre à la version noire.
Après la mise à jour, comparez une nouvelle ligne de données, la page publique et le balisage. Relisez ensuite le problème propre à l'article dans Merchant Center. L'importation d'un fichier, son traitement et l'évolution du statut dans l'interface sont des observations distinctes. Gardez une trace simple des valeurs avant et après pour comprendre ce qui a réellement changé.
Cette situation souligne l'intérêt d'une seule source de prix. Une promotion modifiée indépendamment dans le thème et dans un outil d'export multiplie les possibilités de divergence. Une publication coordonnée du catalogue et du flux simplifie la maintenance et les prochains contrôles.
Exemple 2 : une taille épuisée mais annoncée en stock
Deuxième exemple entièrement fictif. Une boutique de chaussures vend une référence en tailles 40, 41 et 42. Les tailles 40 et 41 restent commandables, mais la taille 42 est épuisée. La fiche du modèle indique globalement « disponible », car certaines tailles le sont encore. Dans le flux, la taille 42 apparaît pourtant avec availability in_stock, et son URL présélectionne la taille 41.
Le responsable ouvre la ligne de données correspondant à la taille 42. Il suit son URL et observe que la taille 41 est active. Il sélectionne ensuite 42 et constate que le bouton d'achat devient inactif. La disponibilité du produit réellement annoncé est donc différente de celle déclarée dans les données. La catégorie, l'image et le libellé général du modèle n'apportent pas la réponse au niveau de cette déclinaison.
Une correction précise associe l'état de stock réel de 42 à sa ligne de flux et fait en sorte que le lien ouvre bien cette taille. Si les données structurées indiquent encore InStock alors que l'achat est impossible, le balisage doit également utiliser la même information actuelle. Le résultat recherché est la cohérence de l'offre, aussi bien pour le lecteur de la page que pour son interprétation technique.
Il faut distinguer une rupture temporaire d'une précommande ou d'un réapprovisionnement accepté à la commande. Ces états correspondent à des conditions réelles différentes. Les valeurs de disponibilité et la présentation visible doivent décrire la manière dont le client peut acheter le produit concerné, au lieu d'utiliser indistinctement in_stock pour toutes les références.
Une fois la taille 42 correctement indiquée, vérifiez la taille 41. Elle doit rester commandable si son stock le permet. Déclarer toute la famille out_of_stock serait une nouvelle incohérence. Le contrôle d'une déclinaison voisine permet de s'assurer que l'intervention a été limitée au bon article.
La même méthode convient aux vêtements, aux meubles avec options, aux couleurs d'appareils et aux ensembles de produits. Dès que le catalogue regroupe plusieurs déclinaisons, la correspondance exacte entre identifiant, URL, prix et stock devient indispensable pour examiner un message Merchant Center de façon utile.
Synchronisation, données structurées et vérification finale
Le décalage entre deux systèmes explique de nombreux messages. Une commande peut diminuer le stock dans la boutique immédiatement, tandis que le flux XML n'est régénéré que plus tard. Un tarif promotionnel peut arriver à échéance avant que la source ne soit actualisée. Relevez donc trois moments : la modification du catalogue, la création du flux et son traitement dans Merchant Center. Cette chronologie indique où la différence apparaît.
Le cache et les scripts jouent également un rôle. Une page peut afficher le nouveau montant après un chargement JavaScript tout en conservant une ancienne valeur dans son HTML initial. À l'inverse, le contenu visible peut être actualisé alors que le JSON-LD décrit encore l'offre précédente. Comparez les données réellement publiées et l'affichage destiné au visiteur pour déterminer quelle couche doit être corrigée.
Pour les ventes internationales, conservez le même pays cible tout au long de l'analyse. Une fiche d'une autre région ne constitue pas toujours un point de comparaison pertinent. Les devises, offres et stocks peuvent varier d'un marché à l'autre. Une modification imprévisible selon l'adresse IP ou la session peut aussi rendre le parcours difficile à reproduire. Travaillez avec l'offre réellement transmise pour ce pays.
Une fois la source corrigée, ouvrez à nouveau la rubrique des produits nécessitant une attention particulière dans Merchant Center. Vérifiez le statut de la fiche et l'action proposée pour le motif concerné. Soumettre une nouvelle source et observer le statut après traitement sont deux étapes différentes. Notez l'heure et les valeurs vérifiées : cette petite trace rend la suite beaucoup plus claire.
Les pages officielles de Google expliquent les écarts de prix, les écarts de disponibilité et les problèmes associés aux articles Merchant Center. Pour les déclinaisons, la documentation ProductGroup décrit la relation entre les différentes offres d'une même famille.
Pour examiner les données de votre offre, découvrez la vérification du flux Merchant Center de Kiljano. L'analyse d'un flux fournisseur XML/CSV concerne davantage la structure d'une source, tandis que la vérification des variantes examine les déclinaisons.
Questions fréquentes sur les écarts de prix et de disponibilité
Pourquoi une seule variante est-elle refusée ?
Merchant Center examine une offre identifiée. Une taille ou une couleur peut porter un prix, un lien ou un état de stock différent de ceux affichés sur la famille de produits. Relevez l'identifiant et contrôlez l'URL précise.
L'écart de prix vient-il forcément du flux XML ?
Il faut comparer la source, la variante ouverte, le montant visible et les valeurs Product/Offer. Une promotion non synchronisée, une page qui charge une autre déclinaison ou un balisage ancien peuvent expliquer la différence.
Comment comparer price et sale_price ?
Vérifiez le tarif ordinaire, l'éventuelle promotion active, sa période et le montant affiché pour l'article exact. Comparez la devise et la variante concernée avant d'actualiser la source.
Que faire si seule une taille est épuisée ?
Vérifiez le stock de cette taille, l'état du bouton d'achat et sa ligne availability. Le stock d'une autre taille ne décrit pas la disponibilité de la variante annoncée.
Une URL de mauvaise variante peut-elle créer un refus ?
Oui. Si le flux décrit une couleur mais que la page en ouvre une autre, les prix et les stocks observés peuvent concerner une offre différente. Corrigez la sélection initiale et vérifiez le lien.
Pourquoi examiner aussi les données structurées ?
Les valeurs price, priceCurrency et availability peuvent être publiées dans un bloc Offer. Il faut vérifier qu'elles décrivent la même offre que le visiteur voit et que le flux transmet.
Quelle étape suit la correction ?
Comparez une source actualisée à la page publique exacte, puis relisez le statut de l'article dans Merchant Center. Conservez l'identifiant et les valeurs observées pour une vérification ultérieure.