Cloaking Googlebot : le site propre pour vous, sale pour Google

Le test qui clôt le débat

Même URL. A : votre navigateur privé, déconnecté. B : Search Console → inspection → tester l'URL en direct → voir le HTML / capture. Si B n'est pas A, vous avez un écart. Point. Les opinions « le site marche » cessent.

Archivez A et B (fichiers). Constat, réexamen, boss. Sans ça, le dossier reste « on n'est pas d'accord ».

Testez `/`, une URL `site:` bizarre, `www` et nu. Le cloak peut ne viser que certains paths. Archivez les deux HTML (A navigateur, B inspection). Sans ces fichiers, le dossier redevient un avis. Avec, vous avez une pièce pour le réexamen, l'assureur, et le développeur qui cherche le `if`. Mobile-first : refaites B en inspection mobile ; certains `if` ne testent que `iPhone` / `Android`.

Signaux que le script utilise

`HTTP_USER_AGENT` contient `Googlebot`, `bingbot`, `AdsBot`. Liste d'IP Google (parfois approximative, des faux positifs). Absence de cookie login. `Accept-Language`. Un paramètre `?amp=1`. L'heure. Le tout combiné.

Un WAF légitime peut aussi varier le HTML (challenge). Le résultat n'est pas un casino. Le contenu de B tranche : pharma vs page d'attente Cloudflare.

Les reverse DNS `googlebot` : les malwares les testent mal. Peu importe : si GSC voit le spam, le test est déjà positif.

• User-agent.
• IP / ASN.
• Cookies / login.
• Paramètres d'URL.

Où lire le `if` (fichiers, prepend, serveur)

Grep `Googlebot`, `HTTP_USER_AGENT`, `66.249.` (plages connues, pas exhaustif) dans racine, mu-plugins, thème, `wp-config` (rare). `.htaccess` `RewriteCond %{HTTP_USER_AGENT}`. Nginx `if ($http_user_agent)`. `.user.ini` prepend vers un PHP qui décide.

Un `index.php` de 200 Ko : souvent le `if` est dedans. poids. Grep `Googlebot`, `HTTP_USER_AGENT`, `66.249.` dans racine, mu-plugins, thème, `.htaccess`, `.user.ini`. Un prepend d'une ligne vers un PHP de 80 Ko, c'est le motif « les fichiers cœur sont officiels et B est quand même un casino ». Suivez le chemin cité, ne vous arrêtez pas au grep vide sur `wp-content/themes`.

Base : moins fréquent pour le cloak (plus pour le contenu stocké). Ça arrive (`eval` dans une option). Cherchez après les fichiers si le grep est vide.

Fetch as Google n'existe plus sous ce nom

L'ancien bouton Webmaster Tools a été remplacé par l'inspection d'URL + test en direct. C'est ça, votre fetch. Pas un outil tiers « simulate Googlebot » uniquement : ils se trompent d'IP. GSC reste le juge, parce que c'est l'IP et le bot de Google.

Les simulateurs aident à debugger un `if` une fois trouvé (rejouer le UA). Ils ne remplacent pas GSC pour la preuve.

L'outil mobile / le rendu : parfois le cloak est dans un JS après paint. Voyez le HTML initial ET le rendu.

VPN, datacenter, et faux négatifs

Vous n'avez pas GSC : un fetch depuis un VPS peut déclencher le cloak (IP datacenter). Un VPN JP, parfois. Un échec (vous voyez FR) ne prouve pas l'absence : le script veut Googlebot, pas un VPS OVH. Ouvrez GSC.

Faux positif : un A/B test légitime, un bandeau geo. Encore une fois, le HTML B casino / CJK tranche.

Cloudflare « Bot fight » : Googlebot devrait passer. Un mauvais réglage montre un challenge à GSC. Ça ressemble à un écart, ce n'est pas du spam. Lisez le HTML B.

Cloaking pub vs cloaking SEO vs admin bypass

SEO : titles / pages pour l'index. Pub : interstitiel pour le visiteur, site clean pour Google (l'inverse, pour durer). Admin bypass : vous voyez clean, le visiteur voit la pub — pas du Googlebot. Trois `if`, trois chasses. pubs.

Ici le sujet est surtout SEO + parfois phishing seulement pour certains UA.

Un bypass admin dans le même fichier que le cloak SEO : fréquent. D'où « moi je vois rien ».

Couper l'écart, pas « expliquer » à Google

Retirez le `if` et le payload. Un message dans le réexamen « nous sommes victimes de cloaking » sans 410 du HTML B : fetch encore sale. Google n'a pas besoin d'un cours ; il a besoin du même HTML que le visiteur honnête.

Les règles SEO légitimes (géotargeting de langue sur un vrai site multilingue) ne servent pas un casino. Ne justifiez pas un kit.

Après retrait : B et A identiques. Puis désindex / SB si besoin.

Après : le même HTML aux deux bouts

Re-testez J+1 (réécriture). Caches. cron.

Les extraits `site:` suivent en semaines. titres.

SB 24-72 h seulement si ressource dangereuse encore vue. Le cloaking SEO seul : pas ce bouton. Re-testez A≡B à J+1 : un cron recolle le `if`. Tant que B redevient casino, désindexer et réexaminer, c'est du théâtre. Le critère de sortie, c'est le même HTML aux deux bouts, stable une nuit, puis l'horloge d'index (semaines) pour les extraits.

Quand ce n'est pas du cloaking

Cache : vous voyez une version, GSC une autre, les deux sont « vous » (vieux menu vs nouveau). Purge, pas un malware. Le HTML B n'est pas un casino.

Soft 404, page login pour le bot, géobloc légal. Encore : contenu de B.

Vous pouvez déclarer. A et B, c'est le dossier. On ne « simule » pas un exploit ; on compare deux HTML que vous avez le droit de fetcher sur votre site.

• Preuve A vs B GSC.
• Grep UA / prepend / index lourd.
• A ≡ B après coupe.
• Puis index / SB selon le reste.