Comment vérifier Googlebot par son IP et repérer les faux Googlebots

Le User-Agent est précisément la partie que contrôle un imposteur. Lors d'un test de 14 jours sur un nouveau site, publié par Search Engine Journal, seules 107 des 799 requêtes se présentant comme Googlebot provenaient d'une adresse Google vérifiée. Il s'agit d'un seul petit site : prenez ce chiffre comme un avertissement, pas comme un taux. Voici la vérification manuelle, la vérification automatisée, et une vraie requête comparant côte à côte un vrai et un faux Googlebot.

Pourquoi un User-Agent Googlebot ne prouve rien

Une chaîne User-Agent est une affirmation que le client fait sur lui-même, et n'importe quel client peut envoyer n'importe quelle chaîne. Les scrapers copient celle de Googlebot parce que de nombreux sites la traitent avec bienveillance : pas de limitation de débit, pas de mur de connexion, pas de challenge anti-bot. Ce nom est donc un déguisement qui vaut la peine d'être porté.

Le croire coûte cher dans les deux sens. Laissez passer un faux Googlebot et un scraper récupère votre contenu à la vitesse d'un robot d'exploration (notre guide pour détecter les bots de scraping dans vos logs d'accès montre à quoi cela ressemble). Bloquez un vrai Googlebot par erreur et vos pages disparaissent de l'index de Google. La solution est la même dans les deux cas : vérifier l'adresse. Notre guide plus général pour vérifier les robots d'exploration IA par IP couvre GPTBot, ClaudeBot et les agents signés, et notre comparatif des principaux bots d'OpenAI, GPTBot, OAI-SearchBot et ChatGPT-User indique lesquels bloquer ; cet article ne traite que des robots d'exploration de Google.

Comment vérifier Googlebot manuellement : DNS inverse, puis DNS direct

Google documente une vérification DNS en deux étapes, et les deux comptent. La voici sur une vraie adresse Googlebot, exécutée le 5 octobre 2026 :

Le nom d'hôte se termine par googlebot.com et renvoie vers l'IP d'origine : la requête provient donc de Google. Sauter l'étape 2 est l'erreur la plus courante. Celui qui contrôle une IP contrôle aussi son enregistrement DNS inverse, si bien qu'un scraper peut nommer son propre serveur crawl-fake.googlebot.com. En revanche, il ne peut pas faire pointer ce nom vers son serveur dans le DNS de Google. C'est la recherche directe qui rend la vérification infalsifiable.

Cette méthode fonctionne bien pour une adresse précise sur laquelle vous enquêtez. Elle est lente pour des logs chargés, car chaque nouvelle IP demande deux requêtes DNS, et les échecs DNS se transforment en faux « faux ».

Plages IP de Googlebot : trois types de robots, trois fichiers de plages

Les robots d'exploration de Google se répartissent en trois groupes, chacun avec ses propres noms d'hôte et sa propre liste d'IP publiée. Comparer une IP au bon fichier est la version automatisée de la vérification DNS, et c'est ainsi que se fait la plupart des vérifications à grande échelle.

Deux détails piègent les anciens scripts. D'abord, les fichiers ont changé d'emplacement : l'ancienne URL googlebot.json répond désormais par une redirection 301 vers /static/crawling/ipranges/common-crawlers.json, donc un code qui ne suit pas les redirections ne récupère silencieusement rien. Ensuite, la page de vérification de Google n'annonce aucun calendrier de mise à jour. Les fichiers que nous avons récupérés le 29 octobre 2026 dataient de la veille ; la copie récupérée le 5 octobre 2026 avait été générée le 2 octobre 2026 et listait 317 préfixes, dont 170 en IPv4. Mettez le fichier en cache, mais rafraîchissez-le au moins une fois par jour.

Source du tableau : la page Verify requests from Google crawlers and fetchers de Google.

Un vrai Googlebot et un faux, côte à côte

Le moyen le plus rapide de voir la différence est d'interroger les deux adresses. Nous avons effectué deux requêtes le 5 octobre 2026 (les résultats évoluent à mesure que les plages changent). La première porte sur 66.249.66.1, l'adresse Googlebot citée dans la documentation de Google. La seconde porte sur 104.248.50.21, un serveur DigitalOcean : imaginez que vos logs le montrent envoyant un User-Agent Googlebot.

La première adresse figure dans la liste de plages de Google : threat.crawler.verified vaut donc true, et verification_method indique comment : ip_range_list. Le signal verified_crawler ramène son fraud_score à 0. La seconde est un serveur cloud ordinaire. Ce n'est un robot d'exploration d'aucune sorte, donc une requête provenant de ce serveur avec un User-Agent Googlebot est un faux par définition.

Remarquez ce que le score ne fait pas. Le faux obtient 15, allow, car un serveur cloud n'est pas malveillant en soi. Le verdict « faux Googlebot » vient de la combinaison de deux faits : vos logs disent Googlebot, la requête dit que ce n'est pas Google. L'API voit l'IP, pas vos en-têtes, donc cette comparaison vous revient :

Vous pouvez tester les deux adresses dans l'outil de recherche IP gratuit, sans clé.

Que faire d'un faux Googlebot

Traitez un échec de vérification comme un « bot non vérifié », pas comme une attaque. La requête vient de quelqu'un qui se fait passer pour Google, ce qui vous apprend qu'il veut être traité comme un robot d'exploration. Retirez-lui ce traitement et gérez-le comme n'importe quel autre client automatisé.

• Supprimez les tolérances accordées aux robots d'exploration. Pas de contournement des limites de débit, des paywalls ou des challenges anti-bot pour un nom Googlebot qui n'a pas été vérifié.
• Limitez le débit par réseau, pas par adresse. Les scrapers font tourner leurs IP au sein d'un même fournisseur. Pour les sources IPv6, utilisez le préfixe comme clé, comme dans notre guide pour limiter le débit d'IPv6 par préfixe /64.
• Ne bloquez jamais une adresse Google vérifiée par accident. Exécutez la vérification avant toute règle de liste de blocage, pour qu'un blocage large par hébergeur ou par ASN ne puisse pas attraper le vrai Googlebot.
• Vérifiez la véritable IP du client. Utilisez l'adresse de connexion, ou un en-tête de transfert uniquement lorsque c'est votre propre proxy ou CDN qui le définit. Un client peut écrire n'importe quoi dans X-Forwarded-For, y compris une vraie adresse Googlebot.
• Laissez passer en cas d'erreur DNS. Si la recherche inverse expire, ce n'est pas la preuve d'un faux. Rabattez-vous sur le fichier de plages, ou laissez passer la requête et vérifiez plus tard.
• Conservez les preuves. Journalisez le User-Agent revendiqué, l'IP et le résultat de la vérification, afin de mesurer quelle part du trafic « Googlebot » est authentique.

Le même schéma s'applique au checkout et à l'inscription, où des agents automatisés se font de plus en plus passer pour des bots connus. Notre guide pour bloquer la fraude des agents d'achat IA au checkout montre comment un indicateur de robot d'exploration vérifié ou non vérifié s'intègre dans une décision de paiement. Pour les autres catégories de bots qu'une requête IP peut ou ne peut pas identifier, consultez notre présentation de ce que les données IP révèlent sur un bot.

Les limites de la vérification par IP

La correspondance avec les plages vous dit qu'une adresse appartient aux robots d'exploration de Google. Elle a des limites qu'il vaut mieux connaître avant de s'y fier.

• Nous couvrons tous les fichiers de Google, chacun sous son propre nom. GeoIPHub vérifie les robots d'exploration à partir de 19 flux de plages officiels, dont les cinq fichiers Google du tableau ci-dessus : robots d'exploration courants, robots spéciaux et les trois fichiers déclenchés par l'utilisateur. Le 8 octobre 2026, 107.178.192.1, issue de user-triggered-fetchers.json, a renvoyé verified: true avec name: "GoogleUserTriggeredFetcher", et non Googlebot. Vérifiez threat.crawler.name, pas seulement verified.
• Il peut y avoir un léger décalage. Google n'annonce aucun calendrier de mise à jour pour ses fichiers. Nous les récupérons chaque jour et reconstruisons notre base de recherche chaque jour, donc un tout nouveau préfixe Google peut mettre jusqu'à environ deux jours avant d'être vérifié chez nous. La vérification DNS, elle, n'a aucun décalage.
• Notre enregistrement ne contient pas de DNS inverse pour ces adresses. C'est pourquoi no_ptr_datacenter apparaît sur le vrai Googlebot ci-dessus, alors que dig renvoie crawl-66-249-66-1.googlebot.com. Le verdict vient de la liste de plages, qui est la voie fiable, mais le libellé de la méthode est trompeur. Nous l'avons enregistré comme bug.
• Les requêtes signées arrivent, mais pas encore pour Googlebot. Google teste Web Bot Auth, qui permet à un agent de signer cryptographiquement ses requêtes, avec certains agents IA de son infrastructure. Il ne signe pas toutes les requêtes, et Google recommande de se rabattre sur les vérifications établies ci-dessus. Notre guide de vérification des robots d'exploration IA explique comment vérifier une signature.
• Une vraie adresse Google n'est pas toujours Googlebot. Le réseau de Google, AS15169, transporte aussi des services comme Google Public DNS (8.8.8.8), que notre requête classe comme simple hébergement, pas comme robot d'exploration. Seuls les fichiers de plages des robots d'exploration comptent : n'ajoutez donc jamais AS15169 en entier à une liste d'autorisation.

Commencez par un chiffre tiré de vos propres logs : combien de requêtes se sont présentées comme Googlebot la semaine dernière, et combien de ces IP passent la vérification DNS avec confirmation directe. L'écart entre les deux correspond à votre trafic de faux Googlebots, et il est généralement plus important qu'on ne le pense.

Questions fréquentes

Quelle est l'adresse IP de Googlebot ?

Googlebot n'a pas d'adresse IP unique. Il explore depuis de nombreux préfixes que Google publie dans common-crawlers.json, sans calendrier de mise à jour annoncé ; la copie que nous avons récupérée le 5 octobre 2026 listait 317 préfixes, dont 170 en IPv4. 66.249.66.1, l'exemple donné dans la documentation de Google, en fait partie. Vérifiez toujours une adresse avec le fichier actuel plutôt qu'avec une liste codée en dur.

Comment vérifier qu'une requête provient vraiment de Googlebot ?

Contrôlez l'IP, pas le User-Agent. Lancez une recherche DNS inverse sur l'IP et confirmez que le nom d'hôte se termine par googlebot.com, google.com ou googleusercontent.com, puis lancez une recherche directe sur ce nom d'hôte et confirmez qu'elle renvoie la même IP. À grande échelle, comparez plutôt l'IP aux fichiers de plages publiés par Google, en commençant par common-crawlers.json pour Googlebot.

Où Google publie-t-il les plages IP de Googlebot ?

Dans des fichiers JSON liés depuis la page « Verify requests from Google crawlers and fetchers » de Google. Googlebot et les autres robots d'exploration courants figurent dans common-crawlers.json. L'ancienne adresse googlebot.json renvoie désormais une redirection 301 vers ce fichier. Les robots d'exploration spéciaux comme AdsBot et les fetchers déclenchés par l'utilisateur ont leurs propres fichiers.

Toute IP de Google est-elle une IP de Googlebot ?

Non. Le réseau de Google (AS15169) transporte aussi d'autres services Google, comme Google Public DNS sur 8.8.8.8. Seules les adresses figurant dans les fichiers de plages des robots d'exploration sont des robots Google, donc une liste d'autorisation par ASN est trop large. Lors de notre requête, 66.249.66.1 a été vérifiée comme Googlebot, tandis qu'un serveur DigitalOcean revendiquant le même nom ne l'a pas été.

Dois-je bloquer les requêtes qui se disent Googlebot mais échouent à la vérification ?

Traitez-les comme un client ordinaire non vérifié, pas comme Googlebot. Limitez leur débit ou soumettez-les à un challenge comme n'importe quel autre bot. Ne leur accordez pas les tolérances d'exploration que vous accordez au vrai Googlebot, et vérifiez que vos propres règles ne peuvent jamais bloquer une adresse Google vérifiée.