Votre trafic « bot » ment-il ? Enquête et plan d’action contre le faux Googlebot 🕵️♂️
Si vous ne consultez vos logs que pour vérifier la santé de votre site, vous passez peut-être à côté d’un phénomène massif : une large part des « visites » de robots que vous voyez ne vient pas de qui elles prétendent. Le cas du faux Googlebot est emblématique. Des acteurs malveillants usurpent l’identité de Googlebot pour scanner vos pages, sonder vos failles, ou biaiser vos tableaux de bord. D’autres imitent des « agents » d’assistants IA (ChatGPT-User, Claude-User, Perplexity-User…) pour obtenir un passe-droit. Résultat : vos chiffres gonflent, vos décisions se faussent, et votre surface d’attaque augmente.
La bonne nouvelle ? Vous pouvez vérifier, prouver et trier le vrai du faux, avec une méthode reproductible qui s’appuie sur des sources publiques et des contrôles techniques simples. Dans cet article, je vous montre comment bâtir votre propre baseline, comment démasquer un faux Googlebot sans ambiguïté, et comment transformer ces vérifications en gains concrets côté SEO, sécurité et pilotage. 🚀
Qu’est-ce qu’un faux Googlebot, et pourquoi ça prolifère ? 🤖
Un « faux Googlebot » est un robot qui se présente dans l’en-tête User-Agent comme Googlebot, mais qui n’est pas opéré par Google. L’usurpation est triviale : l’User-Agent est une simple chaîne qui n’offre aucune preuve en soi. Pendant plus d’une décennie, Googlebot a été l’identité la plus copiée du Web, justement parce que c’est la plus crédible. Si votre pare-feu, votre CDN ou vos équipes accordent un traitement de faveur à Googlebot, un imposteur a tout intérêt à emprunter son nom pour passer.
Pourquoi maintenant en parler de nouveau ? Parce que la vague IA a multiplié les « identités » exploitables. Des noms comme ChatGPT-User ou Claude-User signalent normalement une récupération en direct déclenchée par l’utilisateur. Les attaquants s’en servent pour camoufler des scans d’infrastructure (fichiers .env, secrets, backups, etc.). Les opérations « low effort, high reward » raffolent de ces uniformes faciles à enfiler.
Trois familles de visites IA à ne pas confondre
1) La demande en direct (les agents « -User ») ⚡
Ce sont des requêtes que les assistants effectuent en temps réel pendant une conversation avec un internaute. On les reconnaît à des User-Agents tels que ChatGPT-User, Claude-User ou Perplexity-User. Elles visent des pages publiques et servent à appuyer une réponse instantanée. Ce trafic peut être faible mais très informatif : il mesure une demande « maintenant ».
2) Le crawling de récupération (retrieval) 🔎
Ces robots construisent un index destiné à l’inférence immédiate (bases de connaissances, réponses augmentées de sources). Ils passent de façon planifiée, plus ou moins fréquemment, et impactent votre visibilité à court terme dans les environnements de recherche IA.
3) Le crawling d’entraînement (training) 🧠
Ces bots collectent du contenu pour alimenter les corpus de formation de modèles. L’effet n’est pas visible dans vos analytics, et le « retour » est différé. Pourtant, c’est stratégique : être présent dans ces ensembles peut influencer la compréhension future de votre entité, de votre marque et de votre thématique par les modèles.
Comment prouver qu’un bot est légitime (et démasquer un faux Googlebot)
Étape 1 — Le test par IP, la seule preuve directe ✅
La plupart des grands opérateurs publient des listes officielles des plages d’IP que leurs robots utilisent réellement. Le principe est simple : le nom (User-Agent) est une revendication, l’IP est la preuve. Une requête n’est « vérifiée » que si son IP appartient à ces plages.
Concrètement, OpenAI, Anthropic, Perplexity, Google et Common Crawl diffusent des fichiers (souvent au format JSON ou texte) qui recensent leurs adresses. Votre script de vérification charge ces listes, extrait les sous-réseaux (IPv4/IPv6), et vérifie l’appartenance de l’IP source. C’est un problème résolu côté technique (les librairies réseau standard savent le faire en quelques lignes).
Résultat attendu pour chaque requête marquée « bot » ou « agent » dans vos logs :
– Vérifié : l’IP appartient aux plages publiées du fournisseur associé au User-Agent.
– Faux (spoofé) : les plages se sont bien chargées et l’IP n’en fait pas partie.
– Non vérifiable : les données publiques ne permettent pas de conclure (liste inaccessible, format incohérent, ou fournisseur qui ne publie pas tout).
Étape 2 — Le reverse DNS et la confirmation aller-retour 🔁
Pour Googlebot en particulier, Google documente une méthode robuste comprenant deux volets :
– Résolution inverse (PTR) : l’IP doit se résoudre vers un nom d’hôte se terminant par .googlebot.com ou .google.com.
– Confirmation avant (forward-confirmation) : ce nom d’hôte, résolu à son tour en A/AAAA, doit renvoyer à la même IP d’origine.
Si l’un des deux maillons manque, traitez-le comme suspect. Ce double test est très efficace pour distinguer un vrai Googlebot d’un faux Googlebot qui ne contrôle pas le DNS inverse.
Étape 3 — Quand la preuve manque : le statut « non vérifiable » 🧐
Ne déclarez pas « faux » ce que vous n’avez pas pu vérifier. Classez-le « non vérifiable » et poursuivez l’enquête manuelle. Les pistes utiles :
– WHOIS/RDAP de l’IP (propriétaire, type d’usage, pays, ASN).
– Résolution inverse et directe (au-delà de Googlebot, de nombreux opérateurs sérieux exposent des noms cohérents).
– Présence dans des corpus publics ou index ouverts (par exemple, indices de captures pour certains crawlers d’entraînement).
– Contexte de requête : un « agent » qui demande /config.json ou /.env n’est pas un usage normal d’assistant, c’est un scanner d’informations sensibles déguisé.
Le cas d’école du faux Googlebot 🧪
Parmi toutes les identités usurpées, Googlebot reste la plus commune. Voici des symptômes récurrents d’un faux Googlebot :
Signaux typiques d’usurpation
– Un User-Agent obsolète ou incohérent (référence à des produits Google retirés, fautes, variantes exotiques).
– Des séquences d’URL qui ciblent des fichiers secrets ou d’administration (/.git/, .env, /wp-config.php, sauvegardes, dumps SQL) au lieu de pages publiques.
– Des pointes de trafic depuis des IPs de cloud bon marché, de VPS anonymes ou de régions inhabituelles, sans cohérence DNS.
– Une fréquence irrégulière et agressive, sans respect manifeste du robots.txt.
Checklist rapide pour valider un Googlebot
1) Contrôlez l’IP contre les plages Google documentées pour les crawlers communs.
2) Faites la résolution inverse (PTR) et vérifiez que le nom se termine en .googlebot.com ou .google.com.
3) Faites la confirmation avant : résolvez ce nom et comparez IP = IP.
4) Confrontez le comportement de crawl au robots.txt et au schéma de navigation attendu.
Si 2) ou 3) échoue, vous avez affaire à un faux Googlebot. Bloquez-le sans état d’âme et alertez vos équipes de sécurité. 🚫
Panorama des principaux bots IA à surveiller
OpenAI : ChatGPT-User vs GPTBot 🔷
– ChatGPT-User signale une récupération en direct pendant une session utilisateur. Attendez-vous à des atterrissages sur des pages publiques bien identifiées (articles, fiches, docs).
– GPTBot est un crawler planifié pour l’entraînement ou la constitution d’index. Il doit correspondre aux IPs qu’OpenAI publie. Les divergences appellent enquête.
Anthropic : Claude-User et ClaudeBot 🟣
– Claude-User = demande en direct. Normalement, c’est ponctuel et lisible dans vos journaux d’accès.
– ClaudeBot = crawl planifié. Vérifiez les IPs officielles et la cadence, et surveillez le respect des directives robots.
Perplexity : utile mais parfois ambigu 🟠
Plusieurs observations de terrain montrent des cas où Perplexity interroge depuis des IPs en dehors de ses plages publiées. C’est gênant pour l’attribution : un échec « par IP » peut être un imposteur… ou Perplexity opérant off-list. Classez prudemment et croisez avec le DNS inverse et le comportement.
Common Crawl (CCBot) : très influent pour l’entraînement 🌐
Common Crawl alimente une grande part des corpus ouverts utilisés pour former des modèles. C’est important pour votre « empreinte » sémantique à long terme. Cependant, beaucoup d’imposteurs se revendiquent CCBot sans en avoir les attributs. Quand l’IP n’est pas dans les plages publiées et que le reverse DNS ne mappe pas vers commoncrawl.org, partez du principe que c’est un faux, surtout si les requêtes ciblent des endpoints sensibles.
Gemini et Google-Extended : un design particulier 🧩
Google n’expose pas de fetcher « Gemini » distinct dans vos logs. Le signal « Google-Extended » n’est pas un robot mais un indicateur d’autorisation lié à Googlebot. Conséquence : vous ne pouvez pas « mesurer Gemini » comme vous mesureriez ChatGPT-User. Et si vous voyez un « Google-Extended » se présenter comme user-agent actif, c’est un indice immédiat d’imposture.
Mettez en place votre propre contrôle en 60 minutes ⏱️
Pré-requis
– Accès en lecture à vos logs d’accès (Nginx, Apache, CDN, reverse proxy).
– Un environnement d’analyse (script Python, Node, Go… peu importe, tant que vous pouvez charger des JSON et tester l’appartenance IP à des sous-réseaux).
– Les URLs officielles de publication des plages d’IP des opérateurs qui vous intéressent.
Plan d’action pas à pas
1) Définissez un intervalle de temps (par exemple, 14 jours) et extrayez uniquement les lignes contenant un User-Agent « connu » (Googlebot, GPTBot, ChatGPT-User, Claude-User, Perplexity-User, CCBot…).
2) Standardisez les User-Agents (normalisez la casse, retirez les paramètres superflus) pour mieux regrouper.
3) Mappez chaque famille de bots vers sa ou ses sources « IP ranges » publiques. Prévoyez une tolérance (IPv4 et IPv6, sous-réseaux superposés).
4) Pour Googlebot, ajoutez la procédure DNS inverse + confirmation avant. C’est indispensable pour trancher les cas litigieux.
5) Attribuez un statut par requête : Vérifié / Faux / Non vérifiable. Conservez l’IP, le User-Agent, l’URL demandée, le timestamp, et éventuellement le pays/ASN.
6) Agrégez par bot, puis par statut. Calculez les taux d’imposture (ex. « taux de faux Googlebot »), et isolez les IPs récurrentes d’imposteurs.
7) Pour les « non vérifiables » significatifs, lancez une enquête manuelle (RDAP, DNS, pattern de requêtage, présence dans un index public). Requalifiez si nécessaire.
Conseils pratiques
– Pensez au cache/CDN : l’IP source peut être celle d’un proxy. Travaillez au plus près de l’origine si possible, ou utilisez les en-têtes d’origine (ex. True-Client-IP) s’ils sont fiables et signés.
– IPv6 augmente : vérifiez que votre code gère correctement les notations, y compris les abréviations.
– Limitez le téléchargement des listes d’IP (mettez-les en cache avec une durée de vie raisonnable), et journalisez toute indisponibilité pour ne pas confondre réseau KO et « faux ».
Exploitez vos résultats : SEO, sécurité et pilotage 🎯
Faut-il bloquer un faux Googlebot ?
Oui, s’il s’agit d’un imposteur avéré. Bloquez au niveau WAF/pare-feu (par IP/ASN, signature, rythme) et surveillez les tentatives ultérieures. En revanche, n’appliquez jamais de blocage « large » sur les user-agents ou sur des plages IP officielles sans certitude, sous peine d’exclure de vrais crawls utiles à votre référencement.
Créez des alertes intelligentes
– Alerte en temps réel quand un User-Agent « de confiance » cible des endpoints sensibles (/.env, /config, /admin, sauvegardes…).
– Alerte quand le taux de faux Googlebot dépasse un seuil (ex. >70 % sur 24 h), signe d’une campagne en cours.
– Alerte sur les écarts de rythme (pics anormaux, rafales nocturnes, tentatives en parallèle depuis de multiples ASN low-cost).
Gains SEO et contenu
– Mesurez votre exposition réelle dans les environnements IA : qui récupère votre contenu aujourd’hui (retrieval), qui l’embarque potentiellement pour l’entraînement (training), et quelle part de « demande en direct » vous touche.
– Ajustez votre robots.txt en connaissance de cause, y compris les directives spécifiques aux crawlers IA, et documentez vos choix (politique d’accès, redistribution, citation).
– Mettez en place une stratégie de citation et d’attribution (marqueurs discrets, liens canoniques, signatures sémantiques) afin d’augmenter la probabilité d’être mentionné lorsque les assistants renvoient des sources.
Erreurs fréquentes et pièges à éviter ⚠️
– Croire l’User-Agent sur parole : c’est le point de départ, jamais la preuve.
– Conclure « faux » quand la liste IP est indisponible : c’est « non vérifiable », pas « imposteur ».
– Oublier la confirmation avant sur Googlebot : la seule résolution inverse ne suffit pas.
– Confondre demande « -User » et crawl planifié : ce ne sont pas les mêmes métriques, ni les mêmes objectifs.
– Ignorer IPv6 : beaucoup d’erreurs d’appariement viennent de là.
– Ne pas tenir compte des proxys/CDN : vous risquez d’attribuer à tort une IP de cache à un bot.
Mini étude de cas (synthèse) 🧾
Imaginez un site fraîchement lancé, sans promotion. Sur deux semaines, l’analyse de logs distingue trois signaux :
– Demandes en direct « -User » : un petit volume réel, mais une majorité d’imposteurs tentant d’accéder à des fichiers sensibles sous couvert d’un nom « assistant ». Les rares requêtes légitimes pointent vers des pages publiques et portent des référents plausibles.
– Crawling de récupération : une diversité d’acteurs (y compris Google) visite proprement les contenus principaux, en respect du robots.txt. Le mix par opérateur est instructif, car il révèle qui investit déjà dans la découverte de ce nouveau domaine.
– Crawling d’entraînement : quelques robots d’entraînement passent. Une vérification par IP et DNS élimine les usurpations. Les logs révèlent un intérêt modeste mais réel de certaines plateformes pour intégrer ces contenus à un corpus.
Bilan : sans cette vérification, le tableau de bord « bots » aurait raconté une toute autre histoire, exagérant la place de Google et des assistants, et masquant un bruit d’attaque. Avec le tri, l’équipe priorise la sécurisation des endpoints, ajuste ses règles WAF, et définit une politique claire pour l’accès des crawlers IA utiles.
FAQ express sur le faux Googlebot et les agents IA ❓
Le reverse DNS suffit-il pour Googlebot ?
Non. Il faut toujours faire la confirmation aller-retour : PTR vers .googlebot.com/.google.com, puis résolution du nom vers la même IP. Sans cette étape, des imposteurs peuvent réussir le premier test.
Dois-je bloquer tous les « -User » ?
Non. Beaucoup sont légitimes et reflètent une vraie demande. Bloquez uniquement ce qui est faux ou anormal (ex. agents « -User » qui tentent des chemins de secrets). Pour le reste, choisissez vos règles d’accès selon votre stratégie de visibilité et de droits.
Pourquoi ai-je des « non vérifiables » ?
Listes inaccessibles, opérateurs qui ne publient pas tout, IPs derrière un proxy, IPv6 mal gérée… Classez-les, enquêtez par lots, et documentez vos décisions. Ce statut est une zone d’investigation, pas un échec.
Feuille de route de maturité 🧭
Étape 1 — Observation : mettez en place la classification Vérifié / Faux / Non vérifiable pour les principaux bots, et calculez votre taux de faux Googlebot.
Étape 2 — Réaction : ajoutez des règles WAF ciblées, des alertes en temps réel et des tableaux de bord par bot, par ASN, par endpoint.
Étape 3 — Gouvernance : définissez une politique d’accès claire pour les crawlers IA (qui, quoi, quand), documentez votre robots.txt, et suivez l’évolution mensuelle.
Étape 4 — Influence : travaillez votre présence dans les corpus et les index de retrieval, surveillez les citations et la couverture des assistants, alignez contenu, technique et juridique.
Conclusion : construisez votre baseline, domptez le bruit et gagnez en clarté 🌟
Le faux Googlebot n’est pas une curiosité : c’est une réalité quotidienne, aux conséquences très concrètes sur votre sécurité et vos décisions SEO. La parade ne tient pas du gadget : elle consiste à remplacer la croyance (User-Agent) par la preuve (plages IP officielles, reverse DNS avec confirmation), à accepter l’incertitude (« non vérifiable ») quand les données manquent, et à courir l’enquête jusqu’au bout lorsque l’enjeu le justifie.
Faites l’essai cette semaine. Prenez deux semaines de logs, triez par familles de bots, appliquez la méthode en trois statuts, puis notez deux chiffres simples : votre taux d’imposture global sur les « -User » et votre taux de faux Googlebot. Vous verrez à quelle vitesse le paysage se clarifie. Ensuite, transformez ces enseignements en règles WAF, en alertes, et en une politique d’accès assumée. Vos équipes sécurité respireront mieux, vos rapports SEO redeviendront honnêtes, et vos arbitrages stratégiques (crawlers à autoriser, à limiter, à bloquer) gagneront en précision. 💡
Dernier conseil : relancez l’analyse chaque mois. Les empreintes IP changent, de nouveaux faux Googlebot apparaissent, et vos contenus évoluent. La régularité fait la différence entre un constat ponctuel et une véritable maîtrise de votre exposition « bots ».
À vous de jouer : mesurez, vérifiez, documentez. Le faux Googlebot déteste la lumière des preuves. Vous, vous allez l’adorer. ✨
