Ce qu'il faut retenir.
- Le user-agent "Googlebot" est une simple déclaration volontaire dans l'en-tête HTTP : n'importe qui peut la falsifier pour contourner les protections anti-bot d'un site.
- Pour vérifier un vrai Googlebot, Google recommande une résolution DNS inversée confirmée par une résolution directe, ou une comparaison avec sa liste d'IP publiées : un WHOIS "Google LLC" ne suffit pas, car il couvre aussi Google Cloud.
- Selon Chris Siebenmann, cité dans l'article source, la vague récente de faux Googlebots viendrait d'une campagne unique menée par un opérateur louant des serveurs chez de nombreux hébergeurs, plutôt que d'une multiplication d'imitateurs isolés.
Résumé généré par IA
Le 26 juillet 2026, l'ingénieur Bobbie Chen (Digital Seams) a publié un billet qui remet en cause une plainte récurrente sur Hacker News : des sites qui s'effondrent sous une vague de trafic attribuée à Googlebot. Sa démonstration est simple et vérifiable : la plupart de ce trafic ne vient pas de Google du tout, mais de bots qui usurpent son identité.
Deux témoignages cités dans son article donnent le ton. Un utilisateur nommé jofzar raconte que Googlebot a mis à terre le système d'un client au hasard, ce qui a presque causé une panne, avant de découvrir que Google utilisait aussi ce trafic pour l'entraînement de ses modèles d'IA. Un autre, 20k, affirme avoir vu des centaines de signalements de sites mis à terre par ce qu'ils croyaient être le robot d'indexation de Google, sans aucun recours possible sinon subir le trafic ou disparaître des résultats de recherche. Rappel utile : Googlebot est le robot que Google utilise pour explorer et indexer le web, réputé pour respecter les règles du fichier robots.txt et des limites de fréquence de crawl.
Le user-agent : une promesse sur l'honneur
Quand une équipe technique dit avoir vu du trafic Googlebot, elle regarde en réalité l'en-tête User-Agent d'une requête HTTP, une chaîne du type Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html). Le problème : cet en-tête est une auto-déclaration purement volontaire. N'importe quel script peut écrire cette chaîne sans que rien ne la vérifie côté client. Bobbie Chen illustre le problème avec une ligne de log bien réelle : une requête affichant le user-agent Googlebot, dont l'adresse IP (78.142.228.252) appartenait en réalité à Virtual Machine Solutions LLC, un hébergeur qui loue des serveurs à qui veut bien les payer. Rien à voir avec Google.
Selon Chris Siebenmann, cité dans l'article, cette recrudescence récente ne serait pas due à une multiplication de petits imitateurs isolés, mais à une campagne à grande échelle menée par un seul crawler abusif, opéré par des personnes qui peuvent se permettre de louer des serveurs chez de nombreux hébergeurs différents. Un acteur unique et industrialisé, qui masque son identité derrière le nom le plus crédible qui existe sur le web, celui de Google.
Comment vérifier qu'un Googlebot est vraiment Googlebot
Google documente officiellement la marche à suivre, en deux méthodes complémentaires. La première consiste à faire une résolution DNS inversée sur l'IP suspecte, pour obtenir un nom d'hôte qui doit se terminer par googlebot.com ou google.com, puis à confirmer ce résultat par une résolution DNS directe sur ce nom d'hôte : si elle ne renvoie pas exactement la même IP de départ, ce n'est pas Googlebot. La seconde méthode, plus rapide à automatiser, consiste à comparer l'IP à la liste officielle des plages d'adresses publiées par Google. La plupart des grands robots d'indexation publient une liste comparable, mais le format varie d'un acteur à l'autre : c'est ce que la proposition JAFAR cherche à standardiser, même si elle est encore en cours d'examen dans le processus de normalisation.
Concrètement, en ligne de commande, la vérification ressemble à ceci :
host IP_SUSPECTE
host NOM_DHOTE_OBTENUSi la seconde commande renvoie bien l'IP de départ, la boucle est fermée et le crawler est authentique.
Le piège du WHOIS "Google LLC"
Un réflexe courant consiste à faire un WHOIS sur l'IP suspecte et à se satisfaire d'un résultat "Google LLC". Mauvaise idée : cette même entité enregistre aussi les adresses IP de Google Cloud, la plateforme d'hébergement de Google. Un serveur Google Cloud loué par n'importe quel client (vous, un concurrent, ou un opérateur de faux crawlers) hérite donc de la même mention WHOIS que le vrai Googlebot. La seule façon fiable de trancher reste la double résolution DNS ou la comparaison avec la liste d'IP publiée, jamais le simple nom du propriétaire enregistré.
Et si c'est vraiment Googlebot qui surcharge le site ?
Il arrive, plus rarement qu'on ne le croit selon l'auteur, que le trafic vérifié soit bien celui du vrai Googlebot, et qu'il devienne malgré tout gênant pour l'infrastructure. Dans ce cas, Google publie sa propre documentation pour réduire la fréquence de crawl de son robot sur un site donné, une démarche entièrement différente de celle qui consiste à bloquer un imposteur.
Vers une authentification plus fiable
Sur le fond, le problème vient du fait qu'un en-tête texte ne prouve rien. L'auteur évoque au passage la proposition Web Bot Auth HTTP Signatures, une piste qui remplacerait la simple déclaration par une signature cryptographique vérifiable. Un chantier encore ouvert, mais qui va dans la bonne direction : transformer un user-agent en preuve plutôt qu'en promesse.
Notre lecture chez CZSyn
Chez CZSyn, on voit régulièrement des clients paniquer devant un pic de trafic "Googlebot" dans leurs logs et vouloir bloquer purement et simplement la chaîne Googlebot au niveau du pare-feu ou du fichier robots.txt. C'est exactement l'erreur à ne pas commettre : si le trafic litigieux vient d'un faux crawler, cette règle ne changera rien puisque l'imposteur peut changer son user-agent à volonté. Et si vous filtrez trop large et bloquez par erreur le vrai Googlebot, vous prenez un risque direct sur votre indexation et votre visibilité dans les résultats de recherche, ce qui est autrement plus coûteux qu'un pic de bande passante ponctuel.
Notre recommandation concrète pour une PME ou un site français qui analyse ses logs serveur : avant toute règle de blocage, faites systématiquement la double vérification DNS sur les IP suspectes, ou automatisez la comparaison avec la liste officielle des plages Google. Cette vérification prend quelques secondes et évite de sanctionner le mauvais acteur. Pour le trafic confirmé comme abusif et non lié à Google, un blocage par IP ou par plage d'hébergeur (souvent la source réelle, comme le montre l'exemple Virtual Machine Solutions LLC) est bien plus efficace qu'un filtre sur un en-tête que n'importe qui peut falsifier.
Vous soupçonnez du faux trafic Googlebot sur votre site ?
Nous auditons vos logs serveur, identifions les faux crawlers et sécurisons votre budget de crawl sans jamais bloquer le vrai Googlebot. Audit technique gratuit sous 24h.
06 64 81 45 03ou programmez votre appel · devis gratuit en ligne
29 avis 5/5 · +200 projets livrés · réponse express
Sources primaires
- Digital Seams, Bobbie Chen, « Most Googlebots are fake », 26 juillet 2026.
- Google Search Central, documentation officielle, « Verifying Googlebot ».
- Google Search Central, documentation officielle, « Reduce Googlebot crawl rate ».
