julienjimenez.dev/notes/vrai-googlebot.md
Notes techniques
vrai-googlebot.md Markdown|UTF-8|12 min de lecture

Logs serveur

Logs serveur : la méthode de Julien Jimenez pour repérer le vrai Googlebot

Un user-agent se recopie en une ligne. Avant de lire le moindre budget de crawl dans vos logs serveur, il faut prouver que Googlebot est bien Googlebot. Voici la procédure, commandes comprises, que Julien Jimenez applique au début de chaque analyse.

Mains tenant un long relevé imprimé surligné en bleu et vert, symbole des logs serveur où vérifier le vrai Googlebot
relevé de logs · vérifier Googlebot avant d’interpréter le crawl
aperçu : vrai-googlebot.md 9 sections|blocs de code copiables

Comment vérifier que c’est bien Googlebot dans les logs, et non un script qui emprunte son nom ? La question paraît secondaire. Elle conditionne pourtant toute la suite d’une analyse de logs serveur : fréquence de passage par gabarit, part des URL à paramètres explorées, codes renvoyés aux robots. Si une partie des lignes « Googlebot » vient d’un aspirateur de contenu ou d’un scanner de vulnérabilités, chacune de ces lectures est faussée.

Voici une procédure reproductible, de la préparation des logs à l’automatisation. Les lignes montrées sont fictives et les faux robots utilisent des adresses réservées à la documentation ; les commandes fonctionnent telles quelles sur un serveur Linux.

Pourquoi le user-agent ne suffit pas à vérifier que c’est bien Googlebot

Le user-agent est une simple chaîne de texte envoyée par le client. N’importe quel outil la choisit librement, de curl -A au crawler SEO réglé pour « se faire passer pour Googlebot ». Le serveur l’enregistre sans la contrôler. Trois familles de faux Googlebot reviennent :

  • les outils d’audit, internes ou de prestataires, qui empruntent son user-agent pour voir ce qu’il verrait ;
  • les robots d’aspiration, qui copient catalogues et articles en espérant échapper aux limites de débit ;
  • les scanners de vulnérabilités, reconnaissables à leurs cibles : /wp-login.php, /.env, /admin/.

Leur volume varie énormément d’un site à l’autre : on ne l’estime pas, on le mesure. Seule l’adresse IP d’origine permet de trancher, car elle ne se falsifie pas sur une connexion TCP établie.

Erreur fréquente

Tester la simple présence du mot « googlebot » dans le nom d’hôte. Un nom comme googlebot.com.example.net passe ce test. Le contrôle porte sur la fin exacte du nom : .googlebot.com, .google.com ou .googleusercontent.com, selon la famille de robots.

Récupérer des logs exploitables : champs, période et format

Une vérification n’a de valeur que sur des logs complets. Trois points se règlent avec l’équipe d’exploitation avant la première commande.

Les champs indispensables

Le format combined d’Apache et de Nginx suffit souvent : IP, date avec fuseau, méthode, URL complète, protocole, code de statut, taille, référent et user-agent. Ajoutez si possible le temps de réponse ($request_time sous Nginx, %D sous Apache) et le nom d’hôte quand plusieurs domaines partagent le fichier.

Le piège du CDN et du reverse proxy

Derrière un CDN ou un reverse proxy, le champ IP contient souvent l’adresse de l’intermédiaire : toute vérification devient impossible. Journalisez l’adresse transmise dans l’en-tête prévu (X-Forwarded-For ou celui du CDN), ou récupérez les logs du CDN lui-même.

nginx.confNginx
# combined + temps de réponse + hôte
log_format seo '$remote_addr - $remote_user [$time_local] "$request" '
               '$status $body_bytes_sent "$http_referer" '
               '"$http_user_agent" $request_time $host';
access_log /var/log/nginx/access.log seo;
# derrière un proxy : set_real_ip_from + real_ip_header, sinon
# $remote_addr ne changera jamais (et ce ne sera pas Googlebot)

La période et la confidentialité

Couvrez un cycle complet de publication : quelques jours ne montrent que les pages les plus visitées, plusieurs semaines révèlent les gabarits rarement explorés. Les IP des visiteurs humains sont des données personnelles : filtrez ou pseudonymisez avant de transmettre un extrait.

Étape 1 : isoler les lignes qui se déclarent Googlebot

Premier filtre, volontairement large : toutes les lignes dont le user-agent contient « Googlebot », imposteurs compris. On en extrait les adresses uniques, triées par volume de requêtes.

isoler-googlebot.shBash
grep -i 'googlebot' access.log > declare.log      # tout ce qui se dit Googlebot
awk '{print $1}' declare.log | sort | uniq -c | sort -rn > ips.txt
head -4 ips.txt
#   4210 66.249.66.12
#   3987 66.249.66.40
#   1105 66.249.66.5
#    312 203.0.113.77   <- tiens, tiens

On vérifie ainsi des adresses, pas des lignes : des millions de lignes se résument souvent à quelques centaines d’adresses. Notez aussi la part de Googlebot Smartphone : avec l’indexation mobile généralisée, il doit nettement dominer Googlebot Desktop.

Étape 2 : la double vérification DNS, reverse puis forward

C’est la méthode que Google documente lui-même, en deux requêtes dont la seconde est indispensable.

  1. Résolution inverse (reverse DNS) : l’adresse IP donne un nom d’hôte, qui doit se terminer par googlebot.com, google.com ou, pour certains outils déclenchés par un utilisateur, googleusercontent.com.
  2. Résolution directe (forward DNS) : ce nom d’hôte doit renvoyer l’adresse de départ.

Pourquoi deux temps ? L’enregistrement inverse (PTR) appartient au détenteur du bloc d’adresses, qui peut y inscrire crawl-1-2-3-4.googlebot.com. Il ne peut pas, en revanche, faire répondre la zone googlebot.com, gérée par Google. Seul l’aller-retour concordant prouve l’origine.

verifier-dns.shterminal
$ host 66.249.66.12
12.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-12.googlebot.com.
$ host crawl-66-249-66-12.googlebot.com
crawl-66-249-66-12.googlebot.com has address 66.249.66.12
# aller-retour concordant : Googlebot vérifié
$ host 203.0.113.77
Host 77.113.0.203.in-addr.arpa not found: 3(NXDOMAIN)
# aucun nom : ce « Googlebot » n'en est pas un

dig -x 66.249.66.12 +short donne la même réponse, plus simple à scripter. Le contrôle manuel sert à vérifier un échantillon ; au-delà de quelques dizaines d’adresses, place à l’étape suivante.

Étape 3 : comparer aux plages d’adresses IP publiées par Google, puis automatiser

Google publie les plages d’adresses de ses robots en fichiers JSON, un par famille (robots courants dont Googlebot, robots spéciaux, outils déclenchés par un utilisateur), liés depuis sa page Search Central sur la vérification des robots. Ils évoluent : téléchargez-les depuis cette page et rafraîchissez-les. La comparaison devient un calcul local, en IPv4 comme en IPv6.

verifier_plages.pyPython
import ipaddress, json
data = json.load(open("googlebot.json"))  # robots courants, doc Google
plages = [ipaddress.ip_network(p.get("ipv4Prefix") or p["ipv6Prefix"])
          for p in data["prefixes"]]

for ligne in open("ips.txt"):            # sortie de l'étape 1
    nb, ip = ligne.split()
    a = ipaddress.ip_address(ip)
    ok = any(a in n for n in plages if n.version == a.version)
    print(ip, nb, "verifie" if ok else "a_exclure")

Industrialiser sur un gros volume

Sur un site à fort volume, le contrôle devient une étape de chaque import de logs :

  • un verdict par adresse, mis en cache : seules les nouvelles IP sont comparées ;
  • des plages rafraîchies et datées, pour pouvoir rejouer une analyse ;
  • une colonne de statut (Googlebot vérifié, autre robot Google, robot d’IA déclaré, à exclure) plutôt que des lignes supprimées ;
  • un échantillon contrôlé à la main par double DNS à chaque évolution du traitement.
Quatre façons d’identifier Googlebot, de la plus fragile à la plus robuste
MéthodeFiabilitéCoûtUsage conseillé
User-agent seulnulle face à un imposteurimmédiatpremier filtre, jamais une preuve
Reverse DNS seulinsuffisante, le PTR se falsifieune requête par IPà proscrire seul
Double DNSélevéedeux requêtes par IPéchantillon, audit ponctuel
Plages IP publiéesélevée si les fichiers sont à jourcalcul localtraitement automatique des gros volumes

Si votre analyseur de logs propose une option de vérification des robots, regardez sur quoi elle repose : DNS ou plages d’adresses, jamais le seul user-agent.

Ce que révèle un Googlebot vérifié : premières lectures du crawl

Les lignes fiabilisées, l’analyse du budget de crawl peut commencer, en regard du rapport Statistiques sur l’exploration de la Search Console :

  • la répartition par gabarit : un gabarit stratégique peu visité est un signal fort ;
  • les codes servis aux robots : chaînes de 301, 404 sur des URL encore liées, erreurs 5xx intermittentes invisibles dans un navigateur ;
  • les URL jamais visitées : présentes dans le sitemap XML, absentes des logs, souvent orphelines ;
  • le gaspillage : facettes, tris, paramètres de suivi, calendriers ;
  • le temps de réponse par gabarit, et la part de 304 quand le serveur gère If-Modified-Since.

Notez l’écart entre « toutes les lignes Googlebot » et « Googlebot vérifié » : une prétendue exploration massive des pages d’administration disparaît parfois entièrement. Le sujet n’était pas Google, mais un scanner.

Robots IA et faux robots : les classer à part

Les logs de 2026 comptent une catégorie presque absente il y a quelques années : les robots des services d’IA, comme GPTBot, OAI-SearchBot et ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot ou CCBot (Common Crawl). Ils ne sont pas Googlebot et ne se comptent jamais avec lui.

Même prudence : un user-agent déclaré n’est pas une identité. Quand l’éditeur publie ses plages d’adresses, comme OpenAI, on applique la même comparaison ; sinon, la ligne reste « robot d’IA déclaré, non vérifié ». Leur accès se décide dans le robots.txt, pas dans l’analyse du crawl de Google.

Précision utile : Google-Extended n’est pas un robot, mais un jeton du robots.txt qui règle l’usage de vos contenus par certains modèles d’IA de Google. Il n’apparaît pas dans les logs, l’exploration restant faite par les robots habituels, et le bloquer ne change rien à l’indexation.

Check-list avant toute conclusion sur le budget de crawl :

  • Les logs contiennent la vraie IP du client, pas celle du CDN.
  • La période couvre plusieurs semaines et tous les serveurs.
  • Les lignes « Googlebot » sont vérifiées par plages IP, et un échantillon par double DNS.
  • Les fichiers de plages utilisés sont datés et à jour.
  • Robots d’IA et autres robots de Google sont comptés à part.
  • Les imposteurs sont marqués, pas effacés.

Questions fréquentes

Peut-on bloquer les faux Googlebot ?

Oui, à condition de bloquer sur la base de la vérification, jamais sur le seul user-agent : une règle trop large bloquerait aussi le vrai Googlebot. La plupart des CDN et pare-feu applicatifs savent reconnaître les robots vérifiés. Bloquez ou limitez les adresses qui échouent au contrôle, puis surveillez les logs quelques jours pour vérifier qu’aucune requête légitime n’est refusée.

La Search Console ne suffit-elle pas pour suivre l’activité de Googlebot ?

Le rapport Statistiques sur l’exploration ne montre que le vrai Googlebot, mais de façon agrégée, avec des exemples limités : il donne la tendance (volume, codes, temps de réponse moyen). Les logs vérifiés donnent le détail URL par URL, sur la période de votre choix. On croise la tendance de l’un avec la preuve des autres avant de conclure.

À quelle fréquence mettre à jour les plages d’adresses IP de Google ?

Google ne publie pas de calendrier de modification. Téléchargez les fichiers automatiquement, par exemple à chaque import de logs, et conservez la date de la version utilisée. Pour une adresse absente des plages mais présentée comme Googlebot, la double vérification DNS tranche.

Un vrai robot de Google peut-il avoir un nom d’hôte en google.com ?

Oui. Selon la famille de robots, le nom d’hôte se termine par googlebot.com, google.com ou googleusercontent.com : googlebot.com pour les robots courants, les deux autres pour certains robots spéciaux et les outils déclenchés par un utilisateur. Dans tous les cas, la résolution directe doit renvoyer l’adresse de départ.

Conclusion : vérifier d’abord, interpréter ensuite

Vérifier que c’est bien Googlebot dans les logs n’est pas une précaution de puriste : c’est la condition pour que chaque chiffre qui suit décrive Google, et non un scanner. La procédure tient en peu de choses : la vraie adresse IP, un filtre large sur le user-agent, une double vérification DNS sur un échantillon, une comparaison automatique aux plages publiées et une colonne de statut.

Ce socle posé, l’analyse peut commencer pour de bon. La note sur le statut « Explorée, actuellement non indexée » montre ce que l’on fait des pages que Googlebot visite sans les retenir.

Julien Jimenez, expert SEO technique, portrait

Julien Jimenez

expert SEO indépendant · SEO technique

Julien Jimenez est un expert SEO français indépendant. Il pratique le référencement depuis 2009 et l’a appris en autodidacte, en créant ses propres sites et des dizaines de sites de test. Spécialiste de Google Discover, créateur de la formation « Disco », il intervient sur le SEO technique des sites à fort volume de pages : crawl, logs serveur, indexation, rendu JavaScript et données structurées, avec les équipes en place, partout en France et dans l’espace francophone.

Sommaire9 sections
↑ ↓ naviguerEntrée ouvrirÉchap fermer