Comment vérifier que Googlebot est vraiment Googlebot et pas un imposteur ?

Pourquoi autant de faux Googlebot polluent-ils les logs serveur ?

Les user-agents sont des chaînes de texte modifiables à volonté. N'importe quel script Python ou outil de scraping peut déclarer « Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) » dans ses en-têtes HTTP. C'est aussi simple que de changer une variable dans une requête.

Les motivations derrière cette usurpation sont variées. Certains scrappeurs cherchent à contourner les limitations de crawl imposées aux agents non identifiés. D'autres exploitent le fait que beaucoup de sites autorisent Googlebot sans restriction dans leur robots.txt ou leur configuration serveur. Résultat : des centaines de requêtes frauduleuses quotidiennes qui saturent les ressources serveur.

Comment distinguer le vrai Googlebot d'un imposteur ?

La méthode la plus fiable repose sur la résolution DNS inversée. Quand une requête arrive, tu récupères son IP source, tu effectues un reverse DNS lookup pour obtenir le nom d'hôte, puis tu vérifies que ce nom se termine bien par .googlebot.com ou .google.com. Enfin, tu résous ce nom d'hôte en IP pour confirmer qu'il correspond bien à l'IP initiale.

Google publie également ses plages IP officielles au format JSON via developers.google.com/search/apis/ipranges/googlebot.json. Cette liste est mise à jour régulièrement et peut être intégrée dans des scripts de vérification automatisés. C'est moins granulaire que la vérification DNS mais beaucoup plus rapide à traiter à grande échelle.

Quels risques concrets si on ne vérifie pas l'authenticité ?

Côté serveur, laisser passer des faux bots signifie accepter une charge qui ne sert ni ton SEO ni ton business. Ces scrapers consomment de la bande passante, du CPU, et peuvent déclencher des limites de rate limiting qui pénalisent ensuite les vrais utilisateurs.

Côté SEO, le danger est double. Si tu bloques par erreur le vrai Googlebot parce que tu n'as pas vérifié correctement, ton crawl budget s'effondre. À l'inverse, si tu autorises tout ce qui prétend être Googlebot sans vérification, tu ouvres la porte à des comportements abusifs qui peuvent fausser tes analytics ou exposer du contenu que tu voulais protéger.

• Vérification DNS inversée : lookup IP → hostname → résolution forward pour confirmer
• Confrontation aux plages IP officielles : JSON publié par Google, mise à jour régulière
• Impact serveur : charge illégitime, risque de rate limiting, saturation des ressources
• Impact SEO : crawl budget gâché si blocage du vrai bot, exposition non contrôlée si autorisation aveugle
• Fréquence des faux bots : plusieurs centaines de requêtes frauduleuses quotidiennes sur les sites à fort trafic

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Totalement. Les logs serveur de n'importe quel site à visibilité moyenne montrent des dizaines d'user-agents Googlebot frauduleux chaque jour. La vérification DNS inversée est une pratique recommandée depuis des années, mais elle reste ignorée par une majorité de webmasters qui se contentent de filtrer sur le user-agent.

Ce qui est moins connu, c'est que Google lui-même ne garantit pas la stabilité absolue de ses plages IP. Elles évoluent avec les infrastructures cloud. Compter uniquement sur une whitelist IP statique sans mise à jour régulière finit par bloquer le vrai bot après quelques mois. [A vérifier] : Google ne communique pas sur la fréquence exacte de modification de ses plages, ce qui rend le timing de mise à jour délicat à calibrer.

Quelles nuances faut-il apporter à cette recommandation ?

La résolution DNS inversée ajoute une latence serveur non négligeable si elle est effectuée de manière synchrone à chaque requête. Sur des sites à fort trafic bot, cela peut devenir un goulot d'étranglement. La solution consiste à mettre en place un cache local des résolutions ou à traiter la vérification de manière asynchrone en parallèle du traitement de la requête.

Par ailleurs, certains CDN et WAF (Cloudflare, Fastly, AWS Shield) proposent des mécanismes de vérification automatique de Googlebot. Ils maintiennent leurs propres listes à jour et effectuent la validation en amont. Si tu passes par ces infrastructures, la vérification manuelle devient redondante — mais encore faut-il vérifier que la config du WAF est bien activée.

Dans quels cas cette vérification peut-elle échouer ou donner de faux positifs ?

Les proxies d'entreprise et certains VPN peuvent modifier les en-têtes de requête de manière imprévisible. Si Googlebot passe par une infrastructure tierce (ce qui n'arrive normalement jamais, mais certaines configurations edge exotiques existent), la résolution DNS peut échouer de manière temporaire.

Un autre cas limite : les bots Google adjacents (Google-InspectionTool, APIs-Google, AdsBot-Google) qui ne suivent pas tous les mêmes conventions de nommage DNS. Ils appartiennent à Google mais ne résolvent pas toujours sur .googlebot.com. Il faut alors croiser avec la liste officielle des user-agents Google pour éviter de bloquer des outils légitimes utilisés par Search Console ou Google Ads.

Que faut-il faire concrètement pour mettre en place cette vérification ?

Première étape : logger systématiquement les requêtes avec user-agent Googlebot en capturant l'IP source, le user-agent complet, et l'URL demandée. Cela te donne une base pour analyser les patterns et détecter les anomalies avant même de bloquer quoi que ce soit.

Ensuite, implémente la vérification DNS inversée via un script serveur (Python, PHP, Node.js selon ta stack). Le processus : récupérer l'IP, faire un reverse DNS lookup, vérifier que le hostname se termine par .googlebot.com ou .google.com, puis résoudre ce hostname en IP et confirmer la correspondance. Si l'une de ces étapes échoue, la requête est suspecte.

Quelles erreurs éviter lors de la mise en œuvre ?

Ne bloque jamais immédiatement après détection d'un faux bot. Mets d'abord en place un mode observation pendant quelques semaines pour identifier les faux positifs éventuels. Un blocage prématuré peut couper l'accès au vrai Googlebot si ta logique de vérification contient un bug.

Évite de faire une vérification DNS synchrone bloquante sur chaque requête. Utilise un cache local avec TTL court (quelques heures) pour stocker les résultats de vérification par IP. Cela réduit drastiquement la charge serveur tout en maintenant une protection efficace contre les imposteurs récurrents.

Comment vérifier que le dispositif fonctionne correctement ?

Surveille tes logs Search Console pour t'assurer que le volume de pages crawlées par jour reste stable après la mise en place de la vérification. Une chute brutale signale un blocage accidentel du vrai bot. Croise avec tes logs serveur pour identifier l'IP bloquée et corriger la config.

Utilise également l'outil Inspection d'URL dans Search Console pour forcer un crawl en temps réel. Si la requête échoue alors qu'elle devrait passer, tu as un faux positif à investiguer. Les logs détaillés de ton script de vérification doivent te permettre de remonter au hostname résolu et à l'étape qui a échoué.

• Mettre en place un logging détaillé des requêtes Googlebot (IP, user-agent, URL, timestamp)
• Implémenter la vérification DNS inversée avec cache local (TTL 2-4h) pour limiter la charge
• Télécharger et intégrer la liste officielle des plages IP Google (mise à jour hebdomadaire recommandée)
• Configurer un mode observation pendant 2-3 semaines avant tout blocage actif
• Monitorer le crawl budget via Search Console après activation pour détecter les régressions
• Logger tous les blocages avec détails pour faciliter le débogage des faux positifs