Vous avez configuré Google Merchant Center, importé votre flux PrestaShop, et voilà que la moitié du catalogue est signalée. Triangles rouges dans l’onglet Produits, avertissement « Compte suspendu » qui n’était pas là la semaine dernière, et articles qui devraient être visibles dans Shopping mais apparaissent comme Refusés. Le plus frustrant, c’est que les refus expliquent rarement toute l’histoire en langage clair : Google nomme un symptôme (« Valeur incohérente : prix ») et vous laisse déterminer quel réglage PrestaShop en est réellement la cause.

Dernière mise à jour : juin 2026.

Ce guide traite précisément du diagnostic et de la résolution des refus : lire l’erreur, la rattacher au réglage PrestaShop ou à l’attribut de flux exact qui l’a déclenchée, puis la corriger pour que le produit soit à nouveau approuvé. C’est le compagnon de dépannage du travail plus large sur les flux : si vos produits sont déjà approuvés et que vous voulez améliorer leurs performances (titres, taxonomie, libellés personnalisés), c’est un autre chantier, traité dans notre guide d’optimisation des flux Merchant Center. Ici, nous restons strictement sur l’essentiel : c’est rouge, pourquoi, et comment le faire passer au vert.

Commencez par bien lire le refus

Avant de toucher au moindre réglage, séparez deux notions que Merchant Center mélange volontairement. Un problème au niveau de l’article refuse un produit ou une poignée de produits : vous corrigez les données et il est réapprouvé lors de la prochaine récupération du flux. Un problème au niveau du compte (déclaration trompeuse, règlement, compte suspendu) peut mettre tous les produits hors ligne d’un coup et exige une autre réponse. Le moyen le plus rapide de les distinguer est la vue Diagnostics, pas l’icône rouge affichée produit par produit.

Dans le Merchant Center actuel, ouvrez Produits → Diagnostics (ou À vérifier dans Merchant Center Next). Cette vue regroupe les refus par problème et indique, pour chacun, s’il relève du niveau Compte, Article ou Flux, combien de produits sont touchés, des exemples d’articles, et, lorsque Google la fournit, l’échéance avant que le problème ne commence à vous coûter. Traitez cette liste de haut en bas selon le nombre de produits concernés : une seule correction au niveau du flux supprime souvent des dizaines d’erreurs à la fois, alors que corriger les produits un par un revient à jouer sans fin au tape-taupe. Concrètement, qu’est-ce que cela vous apporte ? Vous consacrez votre temps à corriger le réglage qui réapprouve quarante produits, au lieu de modifier quarante fiches à la main.

Écart de prix, le refus PrestaShop le plus courant

Erreur : « Valeur incohérente (exploration de la page) : prix [price] » ou « Article refusé en raison d’une infraction au règlement : écart de prix ».

Google explore la page produit en ligne et compare le prix visible avec celui de votre flux. S’ils diffèrent au-delà d’une très faible tolérance, l’article est refusé au motif que l’acheteur verrait un montant différent de celui promis par l’annonce. Sur PrestaShop, cela vient presque toujours de l’une des quatre causes suivantes, qui appellent des corrections différentes : identifiez donc la bonne avant de changer quoi que ce soit.

SymptômeCause racine dans PrestaShopOù le corriger
Le prix du flux est hors TVA, la page affiche le prix TTC (ou l’inverse)Le flux exporte le prix hors taxe ; la boutique affiche le prix taxes incluses (le réglage B2C habituel)Faites exporter au flux des prix tax-incl pour correspondre à la page. En termes PrestaShop natifs, c’est Product::getPriceStatic($id, true, ...) avec le drapeau de taxe activé ; dans un module de flux, c’est l’option « inclure la taxe ».
Prix remisé sur la page, prix plein dans le fluxLe flux envoie seulement price et ignore les prix spécifiques de PrestaShop (le moteur de remise derrière les règles de prix catalogue)Envoyez les deux : price = le prix normal, sale_price = le prix remisé que Google doit comparer à la page explorée.
La devise diffère entre le flux et l’explorationMultiboutique/multidevise : Google explore depuis une locale qui aboutit à une devise de boutique différente de celle déclarée par le fluxFixez le flux sur un pays + une devise par flux Merchant Center ; dans PrestaShop, vérifiez que la boutique/devise sous International → Localisation → Devises se résout de façon cohérente.
Le prix de la page a changé, pas celui du fluxFlux obsolète. Un XML/CSV statique généré il y a des heures ou des joursRégénérez au moins chaque jour (cron), ou passez à un flux qui lit les prix en direct. Voir « Flux obsolète » ci-dessous.

Un moyen rapide de vérifier si la taxe est en cause : ouvrez le produit refusé dans une fenêtre de navigation privée, notez le prix affiché, puis ouvrez votre fichier de flux et trouvez le <g:price> de ce produit. Si le ratio entre les deux correspond à votre taux de TVA (1.19, 1.21, 1.23…), vous avez une incohérence de mode de taxe, pas un problème de données périmées, et modifier le mode de taxe du flux corrige tout le lot.

À titre de référence, voici à quoi doit ressembler un article remisé dans un flux XML : envoyez le prix normal comme g:price (taxes incluses, pour correspondre à la page B2C explorée par Google) et le prix remisé comme g:sale_price, tous deux dans la devise affichée par la page, jamais uniquement le prix plein alors que la page affiche le prix soldé.

<item>
  <g:id>1234</g:id>
  <g:price>49.99 EUR</g:price>
  <g:sale_price>39.99 EUR</g:sale_price>
  <g:availability>in_stock</g:availability>
  <g:brand>Acme</g:brand>
  <g:gtin>4006381333931</g:gtin>
</item>

Et pour un produit qui n’a légitimement pas de code-barres, fait main, personnalisé, ou vendu sous votre propre marque, dites à Google de ne plus attendre de GTIN plutôt que d’en inventer un, ce qui déclencherait « Identifiant incorrect » :

<item>
  <g:id>5678</g:id>
  <g:brand>Your Label</g:brand>
  <g:identifier_exists>false</g:identifier_exists>
</item>

Données de flux obsolètes, la cause derrière la moitié des refus « aléatoires »

Erreur : écarts intermittents de prix ou de disponibilité qui « se corrigent tout seuls » puis reviennent.

Si votre flux est un fichier généré une fois puis importé, il n’est qu’une photographie de votre catalogue à cet instant. Chaque modification de prix, changement de stock ou promotion créée ensuite désynchronise le flux des pages en ligne que Google explore, et les refus qui suivent semblent aléatoires parce qu’ils suivent votre activité de modification, pas un réglage unique cassé. La solution consiste à régénérer le flux selon un planning.

Dans PrestaShop, la méthode propre consiste à faire appeler votre contrôleur de flux (ou l’URL « générer » de votre module de flux) par une tâche cron planifiée. Le module officiel Cron tasks de PrestaShop (le module cronjobs, gratuit sur PrestaShop Addons et géré sous Modules) peut appeler l’URL chaque jour ; si votre hébergeur vous donne accès à une vraie cron système, pointez-la vers la même URL. Adaptez la fréquence à votre rythme de changement des prix : quotidiennement au minimum, toutes les heures si vous lancez souvent des ventes flash. Et alors ? Les prix et les stocks du flux reflètent toujours la page que Google s’apprête à explorer, ce qui ferme entièrement la boucle de refus récurrents la plus fréquente. (Pour l’architecture plus large de génération des flux, méthode d’export, performance sur de grands catalogues, c’est traité dans le guide d’optimisation des flux.)

Incohérence de disponibilité

Erreur : « Valeur incohérente (exploration de la page) : disponibilité » ou « Produit indisponible ».

Google a lu in stock dans votre flux alors que la page en ligne indiquait épuisé, ou l’inverse. Sur PrestaShop, cela vient presque toujours de l’interaction entre la quantité en stock du produit et son comportement « En cas de rupture de stock » (réglé par produit dans l’onglet Stock, avec le réglage global sous Paramètres de la boutique → Paramètres produit). Si un produit est à quantité zéro mais réglé sur « Autoriser les commandes », la page le vend toujours : votre flux doit donc indiquer in stock, pas out of stock. Assurez-vous que le flux lit à la fois la quantité et la politique de rupture de stock, pas seulement la quantité, sinon les produits commandables en réapprovisionnement seront marqués à tort comme indisponibles.

Images non conformes

Erreur : « Image trop petite », « Superposition promotionnelle sur l’image » ou « Image non explorable ».

  • Image trop petite. Le minimum est de 100×100 px (250×250 pour l’habillement), et 800×800+ est une recommandation de qualité pratique qui vaut la peine d’être respectée. PrestaShop génère de nombreuses copies redimensionnées de chaque image (les types d’images nommés sous Design → Réglages des images, home_default, large_default, cart_default et les autres). Votre flux doit référencer l’URL du type large, pas une miniature : un flux qui pointe vers home_default déclenchera « trop petite » sur chaque produit.
  • Superposition promotionnelle. Tout texte, badge, filigrane ou logo intégré dans l’image, « SOLDES », « -30 % », « LIVRAISON GRATUITE », entraîne un refus. Si vous avez incrusté des pastilles promotionnelles dans les photos produits, c’est la cause ; l’image produit doit montrer uniquement le produit sur un fond propre.
  • Non explorable. Googlebot ne peut pas récupérer l’URL. Vérifiez trois choses dans cet ordre : robots.txt ne bloque pas /img/, aucune protection anti-hotlink ni règle WAF ne bloque le user-agent du robot d’images de Google, et l’URL de l’image ne renvoie pas de 404. Collez l’URL exacte <g:image_link> dans une fenêtre de navigation privée : si vous ne pouvez pas la charger sans être connecté, Google ne le peut pas non plus.

Identifiants manquants (GTIN / MPN / marque)

Erreur : « Valeur manquante : GTIN », « Identifiant incorrect » ou « Performances limitées en raison d’identifiants manquants ».

Google associe vos produits à son catalogue à l’aide d’identifiants. Pour la plupart des produits de marque fabriqués industriellement, il veut marque + GTIN (le code-barres EAN/UPC). Le champ code-barres de PrestaShop, libellé GTIN (EAN, JAN, ITF ou UPC/UCC) dans le bloc Références de l’onglet Détails du produit (les déclinaisons ont leur propre code-barres, ce qui compte si vous vendez des variantes), correspond directement à l’attribut gtin de Google. L’attribut Marque provient du Fabricant PrestaShop assigné au produit.

  • Produits de marque avec codes-barres : renseignez le champ code-barres GTIN/EAN-13 dans PrestaShop et assignez un fabricant. C’est aussi la modification isolée la plus efficace pour la visibilité : les produits avec des GTIN valides sont associés à davantage de recherches.
  • Produits qui n’ont légitimement pas de code-barres (faits main, personnalisés, votre propre marque privée) : définissez identifier_exists = false dans le flux afin que Google cesse d’attendre un GTIN. N’inventez pas de code-barres : un mauvais GTIN est pire que l’absence de GTIN et déclenche « Identifiant incorrect ».
  • « Identifiant incorrect » : il s’agit généralement d’un code-barres mal formé ou avec un chiffre de contrôle invalide, saisi dans le champ. Validez l’EAN-13/GTIN plutôt que de deviner.

Livraison non configurée pour le pays cible

Erreur : « Informations de livraison manquantes » ou « Aucun coût de livraison pour [country] ».

Google a besoin d’un coût de livraison qu’il peut afficher avant le paiement. Vous pouvez le fournir produit par produit via l’attribut shipping du flux, mais la voie la plus propre pour une boutique PrestaShop est au niveau du compte : définissez-le une fois dans Merchant Center sous Livraison et retours, en cohérence avec vos tarifs de transporteurs PrestaShop (Livraison → Transporteurs). Deux pièges spécifiques à PrestaShop :

  • La livraison gratuite n’est pas une « absence de livraison ». Si vous proposez la livraison gratuite, configurez explicitement un service de livraison à coût 0. Un champ de livraison vide est interprété par Google comme « livraison indisponible », ce qui fait refuser l’article.
  • Chaque pays ciblé doit avoir un tarif. Si vous ciblez l’Allemagne et la France mais que la livraison Merchant Center ne couvre que la France, les produits allemands sont refusés. Cela reflète vos zones de transporteurs PrestaShop : si un transporteur ne dessert pas une zone vers laquelle vous faites de la publicité, Google voit le manque.

Règles et déclaration trompeuse, les menaces au niveau du compte

Erreur : « Infraction au règlement », « Déclaration trompeuse » ou le redouté « Compte suspendu ».

Ce sont les cas sérieux, parce qu’ils peuvent faire tomber tout le compte, pas un seul produit. Il s’agit rarement d’un problème d’attribut de flux : c’est une question de signaux de confiance de votre boutique, que Google vérifie sur le site en ligne. La checklist spécifique à PrestaShop :

  • Politique de retour/remboursement visible et complète. Créez-la comme page CMS (Design → Pages) et liez-la depuis le pied de page. Une politique enterrée ou absente est un déclencheur fréquent de suspension.
  • Coordonnées joignables. Votre boutique doit afficher un moyen réel de vous contacter. Le contrôleur Contact de PrestaShop et une adresse/un téléphone renseignés sous Paramètres de la boutique → Contact couvrent ce point : ne laissez pas les données de démonstration.
  • HTTPS partout, aucun contenu mixte. Activez Paramètres de la boutique → Général → Activer le SSL afin que HTTPS soit appliqué sur tout le site. Un paiement en HTTPS qui charge une image en http:// compte comme contenu mixte et peut être interprété comme non sécurisé.
  • Des titres qui correspondent à ce que vous vendez réellement. « Coque Samsung Galaxy S24 » est honnête ; « Samsung Galaxy S24 » pour une coque tierce est trompeur. Si vos titres PrestaShop commencent par une marque que vous ne fabriquez pas, corrigez le nom du produit, pas le flux.

Si votre compte est suspendu pour déclaration trompeuse, corrigez tous les points ci-dessus avant de demander un réexamen : Google accorde généralement un nombre limité de demandes, donc une correction partielle qui échoue en consomme une.

Une boucle corriger-vérifier qui vide réellement la file

Les refus ne disparaissent pas à l’instant où vous enregistrez un réglage. Travaillez la boucle méthodiquement :

  • Corrigez à la source, pas dans Merchant Center. Modifiez le réglage PrestaShop ou la logique du flux afin que la prochaine régénération soit correcte : corriger un produit à la main dans Merchant Center sera écrasé lors de la prochaine récupération du flux.
  • Régénérez le flux pour que les données corrigées soient réellement présentes dans le fichier lu par Google. (C’est exactement pourquoi la cron quotidienne ci-dessus compte : sans elle, votre correction reste dans PrestaShop sans jamais parvenir à Google.)
  • Relancez la récupération et attendez l’exploration. La réapprobation d’un article suit le prochain traitement du flux et la prochaine exploration de la page, pas votre bouton Enregistrer. La plupart des cas se résolvent en un ou deux jours ; évitez de tout modifier dans la panique entre-temps.
  • Revérifiez Diagnostics, en commençant par le principal problème. Confirmez que le nombre de produits concernés a baissé avant de passer au problème suivant.

Les garder au vert : surveillance

Liste de flux Google Merchant avec colonnes de statut de synchronisation, pays, langue et priorité par flux pour surveiller la santé des flux
Une liste de flux avec un statut de synchronisation par profil vous permet de repérer tôt un flux cassé ou obsolète, avant qu'une nouvelle vague de refus n'atteigne vos produits.

Une fois la file vidée, le travail devient préventif. Vérifiez Diagnostics chaque semaine, traitez les nouveaux refus en un jour ou deux (des refus prolongés peuvent dégrader l’état du compte jusqu’à un avertissement), et gardez la régénération du flux planifiée pour que prix et stock ne divergent jamais. La plupart des vagues de refus « soudaines » sont un flux obsolète qui rattrape une série de modifications de prix : une cron fiable supprime discrètement toute cette catégorie de problèmes.

Le schéma est le même pour toutes les erreurs ci-dessus : un refus est la façon dont Google vous dit que le flux et la page en ligne ne sont pas d’accord sur quelque chose, prix, stock, image, identifiant, règle. Corrigez le désaccord à sa source dans PrestaShop, régénérez, et le rouge disparaît. Une fois les produits approuvés de manière fiable, le levier suivant consiste à les rendre compétitifs : titres plus précis, bonne taxonomie, libellés personnalisés pour les enchères, c’est le terrain du guide d’optimisation des flux. Et si vous prenez du recul sur la stratégie pour gérer des campagnes Shopping rentables, commencez par Google Merchant pour réussir vos campagnes PPC PrestaShop et n’y investissez pas de budget avant d’avoir lu comment choisir le bon budget Google Ads : un flux propre ne rapporte que si le budget derrière lui est correctement dimensionné.

FAQ sur les refus de flux Merchant Center

Comment distinguer un problème au niveau de l’article d’un problème au niveau du compte ? Utilisez Produits → Diagnostics (ou « À vérifier » dans Merchant Center Next), pas l’icône rouge produit par produit. La vue regroupe les refus par problème et marque chacun comme relevant du niveau Compte, Article ou Flux, avec le nombre de produits concernés. Un problème d’article refuse quelques produits et se résout lors de la prochaine récupération du flux ; un problème de compte (déclaration trompeuse, règlement, suspension) peut tout mettre hors ligne d’un coup et demande une autre réponse.

Pourquoi « écart de prix » est-il le refus PrestaShop le plus courant ? Google explore la page en ligne et compare son prix visible avec le prix du flux. La cause habituelle est une incohérence de mode de taxe : le flux exporte des prix hors taxe alors que la boutique B2C affiche des prix TTC. Vérification rapide : ouvrez le produit en navigation privée, trouvez son g:price dans le flux ; si le ratio correspond à votre taux de TVA (1.19, 1.21, 1.23…), passez le flux en taxes incluses et tout le lot se corrige.

Mes refus apparaissent et disparaissent « aléatoirement » : pourquoi ? C’est presque toujours un flux obsolète. Un fichier généré une fois est une photographie de votre catalogue à cet instant ; chaque modification ultérieure de prix ou de stock le désynchronise des pages explorées par Google, donc les refus suivent vos modifications, pas un réglage cassé unique. Régénérez selon un planning, au minimum chaque jour, toutes les heures si vous lancez des ventes flash, via le module Cron tasks de PrestaShop ou une vraie cron système.

Mes images produits sont refusées : qu’est-ce qui ne va pas ? Trois causes fréquentes : le flux pointe vers une miniature (home_default) au lieu du grand type d’image, ce qui déclenche « trop petite » ; un badge promotionnel (« SOLDES », « -30 % ») est incrusté dans la photo, ce qui n’est pas autorisé ; ou l’URL n’est pas explorable (robots.txt bloque /img/, un WAF bloque le robot de Google, ou l’URL renvoie 404). Collez le g:image_link exact dans une fenêtre de navigation privée : si vous ne pouvez pas le charger sans être connecté, Google ne le peut pas non plus.

Combien de temps prend la réapprobation après une correction ? Ce n’est pas instantané. Corrigez à la source dans PrestaShop (modifier un produit à la main dans Merchant Center sera écrasé à la prochaine récupération), régénérez le flux pour que les données corrigées soient dans le fichier lu par Google, puis attendez le prochain traitement et la prochaine exploration : la plupart des cas se résolvent en un ou deux jours. Revérifiez Diagnostics en commençant par le principal problème et confirmez que le nombre concerné a baissé avant de passer à la suite.

À lire aussi

Tags : E-commerce PPC SEO
Partager cet article:
David Miller

David Miller

Fondateur, mypresta.rocks

David Miller est un spécialiste PrestaShop fort de plus de dix ans d'expérience concrète et le fondateur de mypresta.rocks, un studio de développement situé à Tychy, en Pologne. Il conçoit et maintient un catalogue de 152 modules PrestaShop, dont 21 suites « Revolution » couvrant le SEO, le checkout, la sécurité, la performance, le marketing, la recherche, le support et la gestion d'entrepôt, qui améliorent chaque jour de vraies boutiques, testés sur PrestaShop 1.7.8, 8.x et 9.x. Il assure également la maintenance de boutiques en production réalisant plusieurs millions de chiffre d'affaires annuel : son travail se juge donc sur des ventes réelles, pas sur des démos. Son expérience couvre l'ensemble du e-commerce. Performance, sécurité, SEO et marketing, et va au-delà de PrestaShop, jusqu'à WooCommerce, Shopify et les systèmes sur mesure. Sur le blog, il écrit sur la face technique de PrestaShop : ce que la plateforme fait vraiment, ce qui casse en production et quelles solutions tiennent dans la durée.

Commentaires

Aucun commentaire pour le moment. Soyez le premier !
Cet article vous a plu ?

Recevez nos derniers conseils, guides et mises à jour de modules dans votre boîte mail.

Vous pouvez vous désinscrire à tout moment. Vous trouverez pour cela nos informations de contact dans les conditions d'utilisation du site.

Chargement...
Retour en haut