Produits de PrestaShop rejetés dans Merchant Center : prix, disponibilité et variantes

Lorsque Merchant Center rejette un produit en raison du prix ou de la disponibilité, comparez la même variante à trois endroits : dans les données traitées par Google, dans le flux public et sur la page de la boutique. Notez également l’heure de lecture. Un fichier XML généré avant une promotion peut être un fichier correct, tout en contenant une offre obsolète. À l’inverse, un flux à jour ne servira à rien si le lien ouvre une autre taille ou si la boutique affiche un prix différent au robot.

Ce guide s’adresse aux personnes qui gèrent des campagnes et administrent le catalogue PrestaShop. Il se concentre sur le prix, la disponibilité et les variantes. Un rejet lié aux règles du compte, à la vérification de l’entreprise ou aux restrictions de vente nécessite une procédure distincte.

1. Commencez par noter le problème précis et l’identifiant de l’offre

Ouvrez les détails de l’offre rejetée dans Merchant Center et notez le contenu du message, l’identifiant, le pays, la langue ainsi que la source de données. Les noms des sections du panneau peuvent changer ; l’essentiel, ce sont les données de l’offre sélectionnée, et non l’emplacement du bouton sur la capture d’écran.

Ne commencez pas par le fichier XML. Vérifiez d’abord ce que Google a réellement traité, et pas seulement ce que contient actuellement le fichier.

La signification des champs et les conditions de leur utilisation sont décrites dans la spécification officielle des données produit. Utilisez-la pour identifier les exigences applicables à votre assortiment, à votre pays et à votre mode de présentation de l’offre.

2. Comparez la variante précise, pas seulement le nom du produit

Exemple de démonstration : la boutique vend un t-shirt en tailles M et L. Le produit a l’ID 812, les combinaisons étant respectivement 41 et 42. La taille M coûte 129 zł et est disponible. La taille L coûte 139 zł et est en rupture de stock. Le flux contient une offre distincte pour chaque combinaison.

Ici, un identifiant de groupe correct ne corrige pas trois autres écarts. Il faut corriger le prix, la disponibilité et le lien. Google exige que la page de destination présente la variante correspondant à l’offre envoyée ; les détails sont décrits dans les exigences relatives aux pages de destination.

3. Prix : promotion, devise et contexte du destinataire

Comparez les prix dans le même contexte : pays, devise et conditions accessibles à l’acheteur. Le prix visible après connexion à un groupe de clients privilégié n’est pas forcément le prix d’un utilisateur anonyme. De même, la valeur hors taxe du panneau d’administration n’est pas le bon point de comparaison si l’offre exige un prix TTC.

En cas de promotion, vérifiez le prix de base price, le prix promotionnel sale_price et, le cas échéant, la période sale_price_effective_date. Assurez-vous que la réduction est bien en vigueur au moment de l’accès à la page et qu’elle ne dépend pas d’une condition que l’offre ne révèle pas. N’inscrivez pas simplement un chiffre plus bas dans le XML si le panier continue à facturer davantage. Règles de prix : Google — attribut price ; règles de promotion : Google — attribut sale_price.

Si la source du problème est le tarif du fournisseur, corrigez les données d’entrée et les règles de leur mise à jour. Le guide existant sur la mise à jour des prix depuis un CSV sera utile. Ensuite seulement, actualisez le flux et vérifiez si la modification est bien parvenue à Google.

4. Disponibilité : zéro stock n’explique pas toute la configuration

Vérifiez le stock de la combinaison précise, la possibilité d’achat en cas d’absence de marchandise et le message affiché sur la page. Ce qui compte, c’est l’offre réelle pour l’acheteur. Un stock positif enregistré dans la base ne suffit pas si le produit est inactif ou s’il ne peut pas être ajouté au panier.

in_stock, out_of_stock, preorder et backorder ont une signification précise. N’utilisez pas la précommande comme moyen de masquer des ruptures. Pour la précommande et les commandes en attente de disponibilité, vérifiez les exigences relatives au délai ainsi que la cohérence des informations sur la page. Les règles actuelles figurent dans la documentation de l’attribut availability.

Si les données de stock proviennent d’une source externe, contrôlez toute la chaîne : mise à jour de la source → importation dans la boutique → génération du flux → récupération par Google. Activer une récupération plus fréquente du flux n’accélérera pas un grossiste qui publie un nouvel état une fois par jour. Voir aussi le guide sur les stocks depuis un CSV.

5. À quoi doit ressembler un extrait XML ?

Ci-dessous figurent deux éléments item de démonstration pour le même modèle. Il s’agit d’un extrait destiné à comparer l’ID, le prix, la disponibilité et la taille, et non d’un flux complet prêt à être envoyé. Les adresses du domaine example.com sont données à titre d’exemple. Dans la boutique, utilisez des liens qui ouvrent réellement les bonnes combinaisons, ainsi que tous les attributs requis pour le produit concerné.

<item xmlns:g="http://base.google.com/ns/1.0">
  <g:id>ps_812-41</g:id>
  <g:item_group_id>812</g:item_group_id>
  <g:title>T-shirt olive, M</g:title>
  <g:link>https://example.com/koszulka?variant=41</g:link>
  <g:price>129.00 PLN</g:price>
  <g:availability>in_stock</g:availability>
  <g:color>olive</g:color>
  <g:size>M</g:size>
</item>
<item xmlns:g="http://base.google.com/ns/1.0">
  <g:id>ps_812-42</g:id>
  <g:item_group_id>812</g:item_group_id>
  <g:title>T-shirt olive, L</g:title>
  <g:link>https://example.com/koszulka?variant=42</g:link>
  <g:price>139.00 PLN</g:price>
  <g:availability>out_of_stock</g:availability>
  <g:color>olive</g:color>
  <g:size>L</g:size>
</item>

Les variantes ont des id différents et un item_group_id commun. L’ID de la boutique n’a pas besoin d’être un numéro GTIN. N’indiquez pas un EAN inventé et ne le remplacez pas par l’identifiant de l’offre. Les règles de regroupement sont décrites ici : Google — item_group_id.

6. Vérifiez le résultat après une nouvelle récupération

1. Corrigez les données ou la configuration responsable de l’écart.
2. Générez le flux et lisez-le depuis son adresse publique.
3. Vérifiez que le serveur renvoie bien du XML, et non une page d’erreur, un écran de connexion ou une protection bloquant les robots.
4. Après la récupération de la source dans Merchant Center, vérifiez l’heure de traitement et les valeurs de cette même offre.
5. Ouvrez le lien sans session de client privilégié et contrôlez la variante, le prix et la possibilité d’achat.
6. Revenez au statut du problème. S’il persiste, lisez le message actuel au lieu de supposer qu’il concerne la cause précédente.

Les mises à jour automatiques des produits peuvent limiter certains écarts, mais elles ne remplacent pas le maintien d’une source correcte. Contrôlez également le prix et la disponibilité dans les données structurées de la page : Google — données structurées prises en charge.

7. Test réel : lien de variante dans le flux PrestaDev

Le 27 septembre 2026, nous avons vérifié une copie conservée du fichier public google-merchant_id-1.xml. Le fichier à cette adresse a ensuite été régénéré.

Dans ce test, l’adresse du produit avec id_product_attribute=409 a renvoyé un HTTP 200, a sélectionné l’option de prolongation et a affiché 247 zł à la fois dans le prix visible et dans les métadonnées de prix. L’adresse pour 408 a sélectionné la licence complète et 492 zł. Les valeurs ont été lues à partir du HTML initial ; aucun achat n’a été effectué.

Conclusion du test : un g:id, un g:item_group_id et un prix corrects ne suffisent pas lorsque g:link ne sélectionne pas la variante vendue. Google recommande de présélectionner la bonne variante dans le lien et d’assurer la cohérence du prix visible sur la page de destination avec les données de l’offre. g:canonical_link peut toujours pointer vers l’adresse de base du produit sans sélection de variante.

Résultat après correction le 27.09 : nous avons mis à jour le générateur vers la version 2.11.1 et régénéré ce même flux public. Il a conservé 360 identifiants d’offres, et chacune des 346 variantes dispose désormais de son propre lien avec l’identifiant de combinaison. Une nouvelle lecture anonyme de six offres, dont 60-408 et 60-409, a confirmé l’option sélectionnée ainsi que le prix visible et présent dans les métadonnées de la page ; pour 60-409, il s’agit de 247 zł. L’adresse canonique pointe toujours vers la fiche produit de base. Cela confirme le XML public et les pages vérifiées, mais ne dit pas si Merchant Center a déjà récupéré le nouveau fichier ni si les données de l’offre y ont été acceptées. Vérifiez le statut de ces mêmes ID dans votre compte après le prochain traitement de la source.

Mise à jour du 27.09 après exclusion de la position de commission : le produit hors module 144 (« Commission pour paiement via PayPal ») avec les variantes 144-476 et 144-477 a été supprimé du fichier. Le XML public actuel contient 358 offres et 344 variantes avec un lien distinct. Les chiffres 360/346 ci-dessus décrivent l’état du test avant cette exclusion. La seule lecture du XML ne confirme pas encore la récupération ni l’acceptation de la source dans Merchant Center.

Quand Google Shopping Pro peut-il être utile ?

Google Shopping Pro génère les données produit depuis PrestaShop. Dans le code vérifié de la version 2.11.1, on trouve des chemins d’exportation pour les combinaisons, les identifiants de groupe, les prix et les prix promotionnels. C’est un outil de préparation de la source ; il ne résout pas tous les problèmes du compte Merchant Center et ne garantit pas l’approbation des produits.

Vous avez besoin d’un flux bien structuré ? Découvrez Google Shopping Pro. Si le problème concerne aussi la page, les combinaisons ou les données issues d’une intégration, préparez l’identifiant d’une offre d’exemple, le message exact et les trois valeurs comparées pour une analyse de l’intégration de la boutique.

Vérification de fond : 27 septembre 2026. L’exemple du t-shirt et son XML sont démonstratifs. Test 60-408.

Champ	Ce qu’il faut noter
Offre	ID complet de Merchant Center, variante et adresse de destination.
Avant la modification	Message exact, valeurs dans le flux et sur la page, ainsi que l’heure de récupération de la source.
Modification	Une seule correction apportée et son emplacement : données de la boutique, configuration d’exportation ou page de destination.
Après la modification	Nouvelle récupération, valeurs comparées à nouveau et message actuel.

Un tel récapitulatif permet de distinguer la correction des données de l’attente d’un nouveau traitement. Si le prix ou le stock proviennent d’un CSV, vérifiez l’ordre de fin de l’importation et de la génération de la source. Les guides sur la mise à jour des prix et la mise à jour des stocks vous aideront.