Google Merchant Center et boutique piratée : ce qui bloque
Merchant Center suspend un flux quand le checkout ment ou que des pages trompeuses répondent encore 200. Corriger le titre d'un produit dans le XML ne suffit pas. On nettoie le tunnel, puis on demande l'examen.
Un checkout détourné ou des pages trompeuses suspendent le flux. Nettoyez le tunnel, puis demandez l'examen. Un titre de produit corrigé ne suffit pas.
Ce que Merchant regarde vraiment
Google Shopping n'achète pas votre XML les yeux fermés. Un robot ouvre la landing, parfois le tunnel, parfois une URL de variante. S'il trouve une redirection vers un domaine de cartes, un kit de phishing, ou un « add to cart » qui mène ailleurs, le compte Merchant prend une suspension « site » ou « mauvaise expérience ».
Le message parle souvent de « destination », « logiciel malveillant » ou « information trompeuse ». Ce n'est pas une faute de virgule dans le titre. C'est le HTML servi à l'utilisateur. Ads et Merchant se parlent : une alerte Safe Browsing sur le domaine suffit à geler le flux.
Avant d'ouvrir un ticket Merchant, testez trois URL : une fiche produit, le panier, la première étape de paiement. Navigation privée, mobile, clic depuis un résultat Shopping s'il existe encore. Le guide Ads site piraté et retrait blacklist sont les deux files voisines.
Le checkout avant le catalogue
Sur une boutique piratée, la home peut être impeccable et le tunnel déjà skimmé. Un JavaScript injecté dans le thème, un extra Stripe « nulled », un snippet dans `wp_options` (WooCommerce) ou un module PrestaShop inconnu : le réviseur qui simule un achat le voit.
Isolez le paiement tout de suite — module désactivé, page de maintenance sur `/checkout` et `/commande` — plutôt que de laisser des cartes passer « le week-end ». Quelques heures sans vente valent mieux qu'un dossier banque. Notez l'URL de redirection frauduleuse : elle dit si le skimmer est dans le thème, un plugin, ou un fichier `uploads`.
Cherchez aussi les webhooks et les clés API (Stripe, PayPal, Woo REST). Un attaquant qui a eu wp-admin a souvent créé une clé `ck_` en lecture commandes. Révoquez. Le détail boutique WordPress est dans WooCommerce piraté.
- HTML du checkout vs HTML de la fiche : les deux doivent être propres.
- Extensions de paiement : officielles uniquement, dates de fichiers.
- Comptes shop manager / employé créés hors horaires.
Pages trompeuses et cloaking Shopping
Certains kits servent le vrai produit à vous, et une page de pharmacies au user-agent Google. Shopping indexe alors un contenu qui n'a rien à voir avec le flux. L'inspection d'URL sur une landing produit le montre. Gardez le HTML.
D'autres kits déposent des fiches HTML dans `wp-content/uploads/products-xx/` ou réécrivent les permaliens. Le flux XML pointe encore vers vos SKU, mais l'URL répond autre chose. Tant que le générateur tourne, resoumettre le flux échoue.
Coupez la source, répondez 410 aux URL pirates, puis seulement demandez l'examen Merchant. Le même ordre que pour pages pharmacies.
Le fichier de flux n'est pas la cause
On voit trop souvent corriger un titre, un GTIN, un prix dans le XML en espérant lever une suspension malware. Merchant relit la page. Si la page ment, le XML a beau être parfait.
En revanche, un flux hébergé sur une URL devenue publique et réécrite (`/feed.xml` remplacé par un PHP) peut servir du spam aux robots. Vérifiez que l'URL du flux dans Merchant renvoie encore votre fichier, pas un `feed.php` déposé à la racine.
Les sitemaps Shopping et le sitemap SEO sont deux fichiers. Un sitemap pirate soumis dans Search Console n'est pas le flux Merchant — mais il empoisonne l'index des mêmes URL. Retirez-le. Voir sitemap pirate.
Preuve à joindre à l'examen
Comme Ads : une page factuelle. Fichiers retirés, date, URL de test qui répondent le catalogue réel. Capture de l'inspection « après ». Si un checkout a été isolé puis rétabli, dites-le : le réviseur qui tombe sur une 403 de maintenance comprend mieux qu'un silence.
Ne déposez pas l'examen le soir du premier passage Wordfence. Attendez que HTTP et HTTPS, www et nu, et une URL produit avec paramètre, servent la même chose. Merchant a plusieurs crawlers.
Si Safe Browsing est encore rouge, l'examen Merchant attend. Traitez la blacklist d'abord.
WooCommerce, Prestashop, même lecture
Le CMS change les chemins, pas la logique. Woo : `wp-content/plugins` de paiement, `mu-plugins`, options `woocommerce_`. Prestashop : modules, `override`, employés. Magento : admin path et cron. Dans les trois cas, le tunnel d'abord, le catalogue ensuite.
Un File Manager WordPress resté en ligne, un `installer.php` Duplicator, un PHP dans `uploads` : ce sont des portes de boutique autant que de blog. Elles se cherchent comme dans le guide WordPress.
Ne pas créer un second Merchant
Ouvrir un autre compte Merchant « propre » avec le même domaine, ou un sous-domaine encore lié au même WordPress, lie les suspensions. Google rapproche les comptes. Vous perdez du temps et parfois le compte historique.
Changer de nom de domaine pour Shopping pendant l'incident perd les avis produits et l'historique. Ce n'est pas une stratégie de sortie. Nettoyez, puis demandez l'examen sur le compte existant.
Remise du flux et surveillance
Une fois l'examen accepté, resoumettez le flux et surveillez les items refusés un par un. Un refus « page introuvable » sur d'anciennes URL spam est normal : elles doivent rester en 410, pas revenir en 200.
Pendant trente jours, une backdoor oubliée peut recréer une landing trompeuse. C'est la fenêtre où Shopping se re-suspend. La chasse aux portes est dans backdoor PHP. Si vous voulez un constat pour Merchant, créez un espace : le prix s'affiche avant tout accès.