Produits refusés dans Merchant Center : trouver la cause

Lorsqu’un produit est refusé dans Google Merchant Center, augmenter le budget publicitaire ne résout pas la cause. Le problème peut venir d’un attribut, d’un écart avec la boutique ou d’une condition affectant le compte. Commencez par identifier ce que Google a signalé et l’offre précise évaluée.

Ce diagnostic concerne PrestaShop, WooCommerce et les autres plateformes transmettant un catalogue. Le principe reste le même : source de données, informations traitées par Merchant Center et expérience d’achat doivent décrire la même offre. Corriger une seule couche peut faire disparaître temporairement l’alerte, puis laisser réapparaître l’erreur à la prochaine mise à jour.

1. Distinguer problème de produit, de destination et de compte

Ouvrez le problème et relevez son intitulé exact, les produits concernés, le pays et la destination, par exemple annonces Shopping ou fiches gratuites. Une restriction pour une destination ne signifie pas nécessairement un refus partout. Les problèmes de compte peuvent demander de revoir les informations commerciales ou les règles, en plus du fichier de produits.

1. Sélectionnez une offre affectée et notez son ID stable, sa variante et l’URL envoyée.
2. Consultez la valeur finale traitée par Merchant Center, pas seulement celle affichée dans le module de la boutique.
3. Identifiez la source et les règles pouvant modifier cette valeur, y compris les sources complémentaires.
4. Conservez l’heure de mise à jour et les éléments du problème pour comparer après correction.

2. Comparer des données observables

Préparez une petite matrice : ID, attribut signalé, valeur à la source, valeur traitée, valeur visible sur la page et valeur dans les données structurées si présentes. Ajoutez disponibilité et prix pendant l’achat. Choisissez une offre par motif d’erreur : promotion, déclinaison, rupture ou marché. L’échantillon aide à identifier une règle commune sans supposer une cause identique pour tous les produits.

Comparez les données à des moments proches. Un prix observé le matin et un fichier généré la veille peuvent révéler un retard de synchronisation. Si deux sources écrivent le même attribut, confirmez leur priorité et l’ID d’association. Renvoyer le catalogue sans comprendre cet ordre peut réappliquer la mauvaise valeur.

3. Prix : vérifier l’offre présentée au visiteur

Google documente plusieurs causes d’écart de prix : promotions désynchronisées, variantes différentes et données structurées incohérentes en sont des exemples. Vérifiez devise, prix normal, prix promotionnel, dates et conditions. Le produit présenté dans l’image et le titre doit correspondre au prix annoncé, y compris personnalisations obligatoires ou quantités minimales si applicables.

Ouvrez l’URL exacte envoyée dans une session vierge et dans le contexte du marché ciblé. Une page présélectionnant la version la moins chère peut ne pas représenter la variante annoncée. Vérifiez aussi si le cache conserve une promotion terminée. Ne créez pas de règle affichant à Google une offre différente de celle accessible aux acheteurs.

4. Disponibilité : stock et possibilité réelle d’acheter

L’attribut availability doit correspondre à la disponibilité sur la page et lors de la commande. Vérifiez stock de la déclinaison, possibilité de commander et restrictions de livraison. Un article visible peut être indisponible dans la variante choisie ou impossible à expédier vers la zone configurée.

Distinguez rupture, précommande et commande d’un produit temporairement indisponible selon les règles de l’attribut. Si ces modalités sont acceptées, la date de disponibilité exigée doit être cohérente et visible. Ne marquez pas tous les articles en rupture pour masquer une maintenance ou une panne : traitez la situation avec les mécanismes adaptés.

5. GTIN : confirmer l’identifiant sans l’inventer

Recherchez l’identifiant correct auprès du fabricant, sur l’emballage ou dans les informations du fournisseur. Vérifiez qu’il correspond au produit et à la déclinaison annoncés ; ne le remplacez pas par une référence interne ou le code d’une variante proche. Une valeur de la bonne longueur peut être incorrecte. Vérifiez également la perte éventuelle de zéros initiaux dans un tableur.

La documentation de l’attribut GTIN déconseille les valeurs devinées. N’utilisez pas identifier_exists=no pour contourner un identifiant manquant : cette indication concerne seulement les produits effectivement sans identifiants attribués dans les conditions prévues. Fabrication propre ou personnalisation ne constituent pas automatiquement une exception.

6. Variantes : chaque offre doit mener au bon choix

Une famille de produits peut partager une page, mais chaque variante annoncée demande une identification cohérente. Vérifiez attributs distinctifs, ID, image, prix, stock et regroupement. Lorsque item_group_id s’applique, les variantes d’un même produit partagent le groupe tout en restant des offres distinctes. Ne réutilisez pas ce groupe pour des produits sans cette relation.

Testez l’URL de la variante sans dépendre d’un choix mémorisé dans les cookies. La page doit présenter l’option annoncée et la conserver dans le parcours d’achat. Un paramètre exporté par le module mais ignoré par le thème est un indice utile : le problème concerne la liaison catalogue-page, pas forcément la validité du prix.

7. Page de destination et exploration : tester accès et contenu

Vérifiez erreurs 404 et 5xx, boucles de redirection, chargement mobile et images inaccessibles. Examinez avec l’hébergeur robots.txt, pare-feu et règles géographiques. Une page accessible sur l’ordinateur de l’équipe peut rester inaccessible au robot. Ne désactivez pas la sécurité globalement : identifiez la règle et vérifiez l’accès de manière contrôlée.

Le visiteur doit trouver l’offre sans authentification, choix géographique inattendu ni écran la masquant. Examinez aussi informations commerciales, contact et conditions exigées par les règles applicables. L’accessibilité technique est nécessaire, mais ne supprime pas les exigences d’éligibilité du produit ou du compte.

8. Corriger la source avant de demander un nouvel examen

Corrigez là où la valeur est produite : catalogue, intégration, règle, thème ou données structurées. Actualisez la source, confirmez le traitement et reprenez la même matrice. Si un examen est nécessaire, suivez la procédure du problème et réunissez les éléments de la modification. Ne promettez pas de délai d’approbation et ne répétez pas les demandes tant que l’écart persiste.

Exemple hypothétique : prix correct, mauvaise variante

Exemple purement illustratif : l’offre porte l’ID/référence CASACO-AZUL-L, taille L. Dans Merchant Center, la valeur traitée est price=79.90 EUR et availability=in_stock. Le GTIN doit être confirmé auprès du fabricant ; aucun code inventé ni exemption présumée n’est présenté ici.

À l’ouverture de l’URL, la page sélectionne M, affiche 69,90 EUR et indique une indisponibilité. Ce n’est pas la même offre. Confirmez d’abord la sélection de L, son prix, sa devise, son stock et son véritable identifiant ; alignez ensuite source, valeur traitée, page et données structurées. Modifier tous les prix du flux ne corrige pas la présélection. Ce scénario ne décrit ni compte ni résultats RedeShop.

Pour demander de l’aide, envoyez l’adresse de la boutique, le message exact et quelques IDs affectés, sans identifiants d’accès. L’équipe RedeShop peut analyser l’origine des données, les intégrations et les pages, puis proposer un plan de correction vérifiable. La décision d’approbation appartient toujours à Google.

Sources et documentation

• Google Merchant Center : écarts de prix
• Google Merchant Center : disponibilité
• Google Merchant Center : GTIN
• Google Merchant Center : identifier_exists
• Google Merchant Center : identifiants incorrects
• Google Merchant Center : regroupement des variantes
• Google Merchant Center : exigences des pages de destination
• Google Merchant Center : problèmes d’exploration des produits