Fetch as Google peut-il vraiment détecter les hacks en cloaking invisibles ?

Pourquoi certains hacks restent-ils invisibles dans un navigateur classique ?

Les pirates utilisent fréquemment des techniques de cloaking pour masquer leurs modifications. Le principe : détecter l'user-agent de Googlebot et lui servir du contenu différent de celui affiché aux visiteurs humains.

Résultat ? Vous consultez votre site via Chrome ou Firefox et tout semble normal. Pendant ce temps, Googlebot indexe des pages bourrées de liens spam, de redirections vers des pharmas ou de contenus dupliqués malveillants. Le hack reste invisible jusqu'à ce que Google pénalise le site pour manipulation.

Qu'est-ce que Fetch as Google et à quoi sert-il vraiment ?

Fetch as Google était l'ancien nom de ce qui s'appelle aujourd'hui l'outil d'inspection d'URL dans la Google Search Console. Il permet de voir exactement ce que Googlebot récupère lorsqu'il crawle une page.

L'outil affiche le code HTML brut renvoyé au bot, le rendu JavaScript, les ressources bloquées et les erreurs éventuelles. C'est votre seul moyen de vérifier si le serveur sert la même version à Google qu'aux utilisateurs normaux. Pour un site compromis, la différence saute aux yeux : balises meta modifiées, scripts injectés, liens cachés en footer.

Dans quel contexte Google recommande-t-il cet outil ?

Eric Kuan mentionne spécifiquement le processus de réexamen, c'est-à-dire après qu'un site ait été pénalisé ou marqué comme compromis. Google demande une demande de réexamen (reconsideration request) une fois le problème corrigé.

Avant de soumettre cette demande, il faut prouver que le hack est bien éradiqué. Vérifier visuellement le site ne suffit pas : un cloaking persistant peut continuer à polluer l'index. Utiliser l'outil d'inspection devient alors une étape critique de validation avant réexamen.

• Cloaking : technique consistant à servir un contenu différent selon l'user-agent du visiteur
• Outil d'inspection d'URL (ex-Fetch as Google) : permet de voir exactement ce que Googlebot récupère côté serveur
• Réexamen de sécurité : processus de levée d'une pénalité après correction d'un hack ou d'une manipulation
• Injection cachée : code malveillant invisible dans le navigateur mais présent dans le HTML servi au bot
• Validation côté serveur : indispensable pour s'assurer que le contenu HTML renvoyé à Google est sain

Cette recommandation est-elle toujours d'actualité avec l'outil actuel ?

Oui, même si Fetch as Google n'existe plus sous ce nom. L'outil d'inspection d'URL dans la Search Console remplit exactement la même fonction, avec une interface améliorée. La logique reste identique : comparer le rendu Googlebot au rendu utilisateur.

La déclaration d'Eric Kuan garde toute sa pertinence. Les hacks par cloaking n'ont pas disparu, ils se sont même sophistiqués. Certains scripts vérifient désormais plusieurs signaux simultanés (IP, user-agent, referer, géolocalisation) pour mieux masquer l'injection. L'outil d'inspection reste la première ligne de défense, mais il faut parfois aller plus loin avec des tests depuis différentes IPs et user-agents.

Quelles limites faut-il garder en tête avec cet outil ?

L'outil d'inspection montre ce que Google voit au moment du test, pas nécessairement ce qui a été crawlé et indexé précédemment. Un hack peut avoir été actif pendant des semaines avant détection, polluant l'index massivement.

Autre limite : certains cloakings avancés détectent les requêtes issues de la Search Console et se mettent en veille temporairement. Rare, mais observé sur des infections persistantes. Dans ces cas, il faut croiser avec des logs serveur bruts, un crawl Screaming Frog avec différents user-agents, ou même un audit forensique si le site a de gros enjeux business. [A verifier] : Google n'a jamais communiqué publiquement sur la capacité des pirates à détecter les requêtes d'inspection GSC, mais des cas anecdotiques existent.

Comment distinguer une fausse alerte d'un vrai problème de cloaking ?

Tous les écarts entre rendu utilisateur et rendu Googlebot ne signalent pas un hack. Les sites avec JavaScript lourd affichent souvent des différences légitimes : contenu chargé en AJAX, lazy loading, animations CSS désactivées côté bot.

Le vrai red flag : présence de contenu textuel inattendu (liens vers des pharmas, mots-clés sans rapport avec votre thématique), redirections 301/302 non configurées par vous, balises meta title/description modifiées à votre insu. Si l'outil révèle des éléments que vous n'avez jamais implémentés, c'est un hack. Si c'est juste une différence de rendu CSS/JS, c'est normal.

Que faut-il faire concrètement après un piratage suspecté ?

Première étape : auditer toutes les pages sensibles avec l'outil d'inspection d'URL. Commence par la homepage, puis les catégories principales, les pages produits à fort trafic. Les pirates injectent souvent leur code sur les templates les plus crawlés pour maximiser l'impact SEO.

Compare systématiquement le code HTML rendu avec le code source de tes templates. Cherche des iframes cachées, des scripts externes non légitimes, des blocs de liens en display:none. Si tu trouves des anomalies, ne te contente pas de les supprimer manuellement : identifie le vecteur d'infection (plugin WordPress obsolète, FTP compromis, injection SQL) sinon le hack revient en 48h.

Comment vérifier qu'un nettoyage est vraiment complet ?

Après correction, attends 24-48h et relance l'outil d'inspection sur un échantillon représentatif de pages. Vérifie aussi les URLs en cache Google (cache:tonsite.com/page) pour détecter d'éventuels résidus indexés.

Consulte les logs serveur pour repérer des requêtes Googlebot anormales : URLs jamais créées, patterns de crawl inhabituel, pics de bande passante inexpliqués. Un hack peut générer des milliers de pages fantômes que tu ne vois pas dans ton CMS mais que Google a indexées. Croise ces données avec un export Site: dans la Search Console pour lister toutes les URLs indexées.

Quelles erreurs éviter lors d'un réexamen de sécurité ?

Erreur classique : soumettre une demande de réexamen trop rapidement, avant d'avoir éradiqué toutes les traces. Google rejette la demande et tu perds du temps. Mieux vaut passer 2-3 jours à vérifier chaque recoin que de bâcler et devoir recommencer.

Autre piège : ne nettoyer que les pages visibles en négligeant les backups, les anciennes versions de fichiers (.php.bak, .old), les répertoires temporaires. Les pirates laissent souvent des backdoors dans ces emplacements. Si tu ne les supprimes pas, le hack se réactive post-réexamen. Enfin, ne jamais oublier de changer tous les mots de passe (FTP, SSH, admin CMS, base de données) après un piratage confirmé.

• Lancer l'outil d'inspection d'URL sur homepage, catégories et top pages trafic
• Comparer le HTML rendu Googlebot avec le code source de tes templates
• Vérifier les logs serveur pour détecter des URLs fantômes crawlées par Google
• Exporter la liste complète des URLs indexées via Site: dans GSC
• Supprimer tous les backups et fichiers temporaires suspects sur le serveur
• Changer l'intégralité des identifiants d'accès (FTP, admin, BDD)