Comment vérifier que Googlebot crawle vraiment votre site ?

Pourquoi les logs serveur peuvent-ils induire en erreur ?

Les logs serveur enregistrent toutes les requêtes HTTP reçues, y compris le User-Agent déclaré par le client. Le problème ? Ce User-Agent est une simple chaîne de caractères que n'importe quel bot peut modifier à sa guise.

Un scraper malveillant peut parfaitement se déclarer comme Mozilla/5.0 (compatible; Googlebot/2.1) alors qu'il n'a strictement aucun lien avec Google. Vos logs montreront « Googlebot » alors qu'il s'agit d'un tiers qui aspire votre contenu ou teste vos pages pour des raisons qui lui sont propres.

Quelle est la méthode recommandée par Google pour authentifier Googlebot ?

Google documente une procédure en deux étapes pour valider l'authenticité d'un crawl. D'abord, effectuer un reverse DNS lookup sur l'IP source pour obtenir le hostname. Ensuite, résoudre ce hostname en IP et vérifier qu'on retombe bien sur l'IP initiale.

Seules les IP appartenant aux plages googlebot.com et google.com sont légitimes. Cette double vérification garantit qu'un attaquant ne peut pas simplement créer un faux enregistrement DNS pointant vers son IP — il faudrait qu'il contrôle les DNS de Google, ce qui est évidemment impossible.

Quels risques court-on en faisant confiance aveuglément aux User-Agents ?

Trois risques principaux se dessinent. Le premier : fausser vos analyses de crawl budget. Si vous comptabilisez des centaines de hits « Googlebot » qui n'en sont pas, vous surestimérez la fréquence réelle de passage du bot et prendrez de mauvaises décisions d'optimisation.

Le deuxième : exposer du contenu sensible. Certains sites délivrent des versions différentes à Googlebot (par exemple, du contenu derrière un paywall rendu accessible pour l'indexation). Un faux bot récupère alors ce contenu sans restriction.

Le troisième : subir une charge serveur non anticipée. Un scraper agressif déguisé en Googlebot peut générer des milliers de requêtes par heure, dégrader vos performances et même provoquer des timeouts ou des downtimes si votre infra n'est pas dimensionnée pour absorber ce trafic parasite.

• Le User-Agent seul ne garantit rien — il est trivial à falsifier
• La vérification IP via reverse DNS + forward DNS est la seule méthode fiable
• Les faux bots peuvent fausser vos métriques de crawl et exposer du contenu restreint
• Google documente cette procédure dans sa documentation officielle depuis des années
• Des outils comme robots.txt tester ou des scripts serveur peuvent automatiser cette vérification

Cette recommandation est-elle cohérente avec les pratiques terrain observées ?

Absolument, et c'est même un basique souvent négligé. En audit, je vois régulièrement des clients qui analysent leurs logs sans aucune validation d'IP — et découvrent avec surprise que 40 % des hits « Googlebot » proviennent de data centers tiers, de scrapers concurrents ou de services SEO automatisés.

Google n'a jamais varié sur ce point. La documentation officielle mentionne cette procédure depuis au moins 2015, et aucune mise à jour récente n'a changé le process. C'est un conseil stable, non sujet à interprétation. Si tu ne vérifies pas les IP, tu travailles avec des données polluées.

Quelles nuances faut-il apporter à cette déclaration ?

Premier point : la vérification DNS a un coût en ressources. Sur un site recevant 100 000 hits Googlebot par jour, effectuer un reverse DNS puis un forward DNS pour chaque requête en temps réel peut ralentir le serveur. La solution pragmatique consiste à logger les IP, puis traiter les vérifications en batch asynchrone.

Deuxième nuance : Google utilise des centaines de ranges d'IP qui évoluent. Maintenir une whitelist statique est voué à l'échec — certaines IP légitimes seront bloquées, d'autres passeront. Seule la méthode DNS garantit une couverture exhaustive et à jour. [A vérifier] : certains CDN proposent des mécanismes de validation intégrés, mais leur fiabilité dépend de la fréquence de mise à jour de leurs bases IP.

Dans quels cas cette règle ne s'applique-t-elle pas pleinement ?

Si tu passes par un reverse proxy ou un CDN comme Cloudflare, l'IP source vue par ton serveur est celle du proxy, pas celle de Googlebot. Dans ce cas, il faut récupérer l'IP réelle via les headers X-Forwarded-For ou CF-Connecting-IP — et là encore, vérifier que ces headers ne sont pas eux-mêmes falsifiés.

Autre cas limite : les environnements de staging ou de dev bloqués par IP. Si Googlebot accède à ces environnements (ce qui ne devrait jamais arriver), valider son IP ne change rien au problème principal : ces environnements ne doivent tout simplement pas être crawlables. Un robots.txt disallow global ou une authentification HTTP résolvent ça en amont.

Que faut-il faire concrètement pour valider Googlebot dans vos logs ?

La méthode manuelle repose sur deux commandes shell classiques. Pour une IP donnée, lance host [IP] pour obtenir le hostname via reverse DNS. Puis lance host [hostname] pour vérifier que l'IP retournée correspond bien à l'IP initiale.

Exemple concret : host 66.249.66.1 retourne crawl-66-249-66-1.googlebot.com. Puis host crawl-66-249-66-1.googlebot.com retourne 66.249.66.1. Match confirmé, c'est bien Googlebot. Si le hostname ne finit pas par .googlebot.com ou .google.com, c'est un imposteur.

Quelles erreurs éviter lors de l'implémentation ?

Première erreur classique : bloquer des IP légitimes parce que le reverse DNS timeout ou échoue temporairement. Si ta validation échoue, logge l'événement mais ne bloque pas la requête en dur — tu risques de couper l'accès au vrai Googlebot.

Deuxième erreur : se contenter du forward DNS sans faire le reverse. Un attaquant peut créer un enregistrement DNS pointant vers son IP et prétendre être googlebot.com — mais le reverse DNS depuis cette IP ne retournera jamais un hostname Google légitime. Les deux étapes sont indissociables.

Troisième erreur : négliger les autres bots Google. Google dispose de plusieurs User-Agents (Googlebot-Image, Googlebot-Video, Google-InspectionTool, AdsBot-Google, etc.) qui partagent les mêmes ranges d'IP. Ta validation doit couvrir tous ces crawlers, pas seulement le Googlebot classique.

Comment automatiser cette vérification à l'échelle ?

Plusieurs approches sont viables. Tu peux intégrer un script Python ou PHP qui parse tes logs Apache/Nginx, extrait les IP déclarées Googlebot, et effectue les lookups DNS en batch. Des bibliothèques comme dnspython ou gethostbyaddr simplifient l'opération.

Autre option : déléguer cette validation à ton WAF ou firewall applicatif. Certains permettent de créer des règles custom exécutant des reverse DNS en temps réel. C'est plus coûteux en ressources, mais ça bloque les faux bots avant qu'ils ne touchent ton application.

Pour les infrastructures complexes ou les sites à fort trafic, il peut être judicieux de faire appel à une agence SEO spécialisée qui dispose déjà des pipelines d'analyse de logs, des scripts de validation et de l'expertise pour interpréter les résultats sans faux positifs. Ce type de prestation évite de mobiliser vos équipes dev sur des sujets annexes tout en garantissant une vélocité d'implémentation.

• Implémenter un script de validation DNS (reverse + forward) sur vos logs serveur
• Vérifier que les hostnames se terminent par .googlebot.com ou .google.com
• Ne jamais bloquer une requête en dur si la validation DNS échoue — logger l'événement et investiguer
• Étendre la validation à tous les User-Agents Google (AdsBot, InspectionTool, etc.)
• Si vous utilisez un CDN ou reverse proxy, récupérer l'IP réelle via les headers appropriés
• Automatiser la vérification en batch asynchrone pour éviter la surcharge serveur