Rien n'est plus frustrant qu'une boutique pleine dont les produits n'apparaissent pas dans Google Shopping. Dans Google Merchant Center, les articles restent « refusés » ou « en cours d'examen ». Et chaque produit refusé, c'est du chiffre d'affaires visiblement perdu. La bonne nouvelle : les causes sont presque toujours les mêmes, et presque toutes relèvent d'un problème de données, pas d'un problème de produit.
Notre position est claire : nous ne vous construisons pas un énième flux. Nous ramenons vos refus à zéro. La distinction compte : la plupart des apps de flux se contentent de générer un nouveau fichier en espérant que Google l'accepte. Nous examinons pourquoi Google refuse les produits que vous avez déjà, et nous corrigeons exactement cela.
D'abord, comprenez ceci : données de crawl vs. données du flux
Le déclic essentiel : Google connaît votre produit par deux sources, et elles se contredisent souvent. L'une est le flux (le fichier structuré que votre boutique ou une app envoie à Merchant Center) et l'autre le crawl (Google visite votre vraie page produit et la lit). Si une valeur existe dans la boutique mais pas là où la source du flux la lit, elle manque dans Merchant Center, même si elle « existe » dans le backend. C'est précisément cet écart entre crawl et flux qui explique la plupart des avertissements.
1. « Page de destination inaccessible » / « Page produit inaccessible »
L'erreur la plus fréquente et la plus coûteuse. Un produit se trouve dans le canal de vente Google mais n'est pas publié sur l'Online Store : brouillon, masqué ou activé uniquement pour d'autres canaux. Résultat : la page de destination que Google a dans le flux renvoie une erreur 404. Google ne peut pas atteindre la page promise et refuse le produit.
La correction : soit publier le produit sur le canal de vente « Online Store » pour que la page existe, soit retirer le produit du flux s'il n'est délibérément pas à vendre. Un produit ne devrait jamais figurer dans le flux Google sans une page accessible sur l'Online Store. Faites particulièrement attention aux anciens brouillons et aux articles épuisés restés coincés par accident dans le canal.
2. « shipping_weight » manquant
Un cas d'école de conflit crawl-vs-flux : le poids est renseigné dans la boutique (sur la variante), mais la source qui alimente le flux ne le lit pas : elle crawle la vitrine, où le poids n'est pas visible. Google en a besoin pour calculer les frais d'expédition et signale l'attribut manquant.
La correction : mapper proprement le poids du catalogue vers l'attribut de flux `shipping_weight`, ou configurer des réglages d'expédition forfaitaires dans Merchant Center afin que Google n'ait plus besoin d'un poids par produit. Les deux voies sont valables ; l'essentiel est que Google reçoive une information d'expédition fiable.
3. Disponibilité manquante
Sans l'attribut `availability`, Google ignore si l'article est en stock ; dans le doute, il ne le diffuse pas. Certains flux le codent en dur sur « en stock », ce qui déclenche des avertissements dès qu'un produit est réellement épuisé.
La correction : déduire la disponibilité de votre stock réel, en renseignant `instock`, `outof_stock` (ou `preorder`) de façon dynamique selon le niveau de stock, et non comme une valeur fixe. Le flux reste ainsi honnête et Google garde confiance en vos fiches.
4. GTIN manquant ou invalide
Pour de nombreux produits de marque, Google attend un GTIN valide (le code-barres / EAN). S'il est manquant ou invalide, la visibilité chute ou le produit est refusé.
La correction : renseigner le GTIN à partir du vrai code-barres du produit. Un point n'est pas négociable ici : n'inventez jamais un GTIN. Un numéro fabriqué de toutes pièces viole les règles de Google et peut entraîner la suspension de votre compte. Si un produit n'a réellement pas de GTIN (p. ex. fait main), vous définissez alors correctement `identifier_exists = no` à la place ; c'est la voie propre et conforme aux règles.
5. La couche juridique européenne que les apps étrangères ignorent
La raison pour laquelle les apps de flux conçues à l'international échouent par dizaines en Allemagne, en Autriche et en Suisse : elles ne connaissent pas la situation juridique locale. Google répercute ces exigences dans Merchant Center.
- Prix à l'unité (PAngV) : pour les produits vendus à la quantité (ml, g, pièces), le droit allemand sur l'indication des prix impose un prix à l'unité ; son absence entraîne des avertissements et un risque juridique.
- Électronique / mentions WEEE : pour les articles électroniques, le canal comme la loi attendent des déclarations correctes.
- Textes juridiques (mentions légales, retours, confidentialité) : s'ils manquent ou ne sont pas correctement reliés, Google juge la page de destination peu fiable. Des prestataires comme le Händlerbund alimentent automatiquement ces textes dans les bonnes pages de la boutique.
Une app de flux qui ignore cette couche produit un flux techniquement « vert » qui reste néanmoins refusé. C'est exactement là que le métier se sépare de l'automatisation.
Presque chaque refus dans Merchant Center est un problème de données, pas un problème de produit. Comprenez la différence entre données de crawl et données de flux et vous le corrigez à la racine, au lieu d'empiler encore un flux de plus par-dessus.
Comment nous travaillons
- Diagnostiquer : chaque avertissement de Merchant Center est rattaché à sa cause réelle (accessibilité de la page, poids, disponibilité, GTIN, catégorie/titre, juridique).
- Corriger à la source : publier les produits, mapper correctement les attributs, lier la disponibilité au stock, renseigner les GTIN à partir des vrais codes-barres.
- Sécuriser le droit européen : vérifier et alimenter le prix à l'unité, l'étiquetage électronique et les textes juridiques.
- Recontrôler : vérifier à nouveau jusqu'à ce que les refus soient à zéro.
Feed Doctor : diagnostic et réparation au même endroit
C'est précisément pour ce travail que nous avons créé Feed Doctor, notre outil qui diagnostique les refus GMC et en corrige automatiquement beaucoup : catégorie, titre, GTIN, poids, disponibilité et accessibilité de la page. Il fonctionne avec des règles déterministes (traçables, sans boîte noire) et une assistance IA optionnelle pour les cas délicats. Vous pouvez l'essayer en direct sur feeddoctor.gbdesign.art.
Que ce soit avec Feed Doctor ou à la main avec nous : l'objectif est toujours le même : non pas un flux de plus, mais vos refus à zéro et vos produits de retour dans Google Shopping.
Vous gérez une boutique Shopify ? Installez Feed Doctor directement depuis le Shopify App Store, sur apps.shopify.com/feed-doctor-1. Le diagnostic est gratuit à vie : vous voyez d'abord ce qui cloche, vous décidez ensuite.