Duane Forrester vient de publier sur Search Engine Journal une analyse qui mérite qu’on s’y arrête. Sur son nouveau site CitationIQ.com, il a croisé ses logs serveur avec les plages IP publiées par les grands opérateurs. Résultat : 81,8 % des requêtes portant un nom d’agent IA sont des imposteurs, et la situation est encore pire côté Googlebot.
Ce n’est pas un problème réservé aux gros sites. C’est exactement là que ça devient intéressant pour toi.
Ce que tes logs te racontent vraiment
Quand un bot visite ton site, il se présente dans l’en-tête de la requête HTTP avec un nom : ChatGPT-User, ClaudeBot, Googlebot. Ton serveur l’écrit dans le log, ton outil d’analyse le comptabilise, et tu en tires des conclusions.
Le problème : ce nom est auto-déclaré. N’importe qui peut mettre ce qu’il veut dans ce champ. Affirmer être Googlebot ne coûte rien et ne prouve rien.
La vraie vérification repose sur deux éléments conjoints. Le nom annoncé, et l’adresse IP réelle de la requête. Chaque opérateur sérieux publie les plages d’IP que ses bots utilisent. Si l’IP ne figure pas dans la liste officielle, la requête est spoofée, quelle que soit la belle carte de visite affichée.
Voici les fichiers de référence à utiliser :
- ChatGPT-User :
https://openai.com/chatgpt-user.json - Claude (tous les bots) :
https://claude.com/crawling/bots.json - Perplexity-User :
https://www.perplexity.com/perplexity-user.json - Googlebot :
https://developers.google.com/static/crawling/ipranges/common-crawlers.json - CCBot (Common Crawl) :
https://index.commoncrawl.org/ccbot.json
Les chiffres bruts sur un site neuf
Sur 14 jours d’observation, Forrester a reçu 33 requêtes portant le nom d’un agent IA en mode “live fetch” (les bots qui vont chercher une page en temps réel pendant une conversation utilisateur). Parmi elles, seulement 6 venaient d’une IP vérifiée. Les 27 autres, soit 81,8 %, ne correspondaient pas aux plages publiées.
Et ce n’est pas juste du bruit parasite. Les faux agents IA se sont trahis par leurs destinations : ils allaient chercher .env.production, secrets.yaml, config.json. Personne n’a demandé à un assistant IA d’aller lire ses variables d’environnement. C’étaient des scanners de credentials qui empruntaient un nom de confiance pour contourner les filtres.
Côté Googlebot, sur 799 requêtes portant ce nom, seulement 107 venaient d’une adresse IP Google vérifiée. Les 692 restantes, soit environ 87 %, n’étaient pas Google. Googlebot reste le nom le plus usurpé du web depuis deux décennies. Certains faux bots utilisaient même des user-agents liés à des produits Google retirés depuis des années.
La ligne Googlebot dans tes logs ne compte pas les visites de Google. Elle compte les requêtes qui “prétendent être Google”. La différence peut être énorme.
Crawl de récupération vs crawl d’entraînement : deux populations distinctes
Un point que Forrester soulève et qui est souvent mal compris : les agents IA en mode conversation et les crawlers en arrière-plan sont des bots différents avec des noms différents.
ChatGPT-User n’est pas GPTBot. Claude-User n’est pas ClaudeBot.
Les premiers font du retrieval : ils vont chercher ta page en direct pendant qu’un utilisateur pose une question. C’est ta visibilité aujourd’hui.
Les seconds font du training : ils moissonnent ton contenu pour alimenter les poids d’un futur modèle. Quand un crawler d’entraînement prend ta page, tu ne verras jamais de trafic référent en retour. C’est un dépôt dans un corpus utilisé pour construire des modèles qui répondront à des questions pendant des années, sans jamais revenir te chercher. Ce signal est invisible dans GA4.
Sur les 14 jours d’observation, le crawler le plus actif sur le domaine était ClaudeBot (166 crawls vérifiés), devant Googlebot vérifié (107), puis GPTBot d’OpenAI (46). Un seul site neuf et sans promotion, sur deux semaines, mais la composition est intéressante.
La question de comment les IA choisissent leurs sources est directement liée à cette infrastructure de crawl que la plupart des SEOs ignorent.
Le cas CCBot : comment chasser les cas non résolubles
Forrester a rencontré 20 requêtes CCBot (Common Crawl) dans ses logs : 0 vérifiées, 4 spoofées, 16 “non vérifiables”. Ces 16 l’ont forcé à creuser, et la méthode vaut d’être retenue.
Étape 1 : vérifier la liste publiée. Aucune des 20 IPs ne figurait dans les plages officielles de Common Crawl.
Étape 2 : reverse DNS. Les vrais bots CCBot résolvent vers un hostname commoncrawl.org. Quatre des requêtes pointaient ailleurs, les seize restantes n’avaient aucun enregistrement reverse.
Étape 3 : vérifier le corpus public. Common Crawl propose un index public pour savoir si un domaine a été archivé. Aucune trace du domaine dans les trois crawls mensuels récents.
Étape 4 : WHOIS sur les IPs brutes. Toutes pointaient vers des hébergements mutualisés bon marché dans plusieurs pays européens, l’infrastructure typique des scanners.
Quatre angles indépendants, une réponse unique : tous des imposteurs.
Ce travail manuel illustre pourquoi il ne faut pas appeler “faux” ce qu’on ne peut pas confirmer. L’absence de preuve n’est pas une preuve d’absence. C’est ce que la colonne “non vérifiable” est censée signaler.
Le cas Gemini : le trou noir de la mesure
Un acteur qu’on ne peut pas mesurer du tout : Gemini.
OpenAI, Anthropic et Perplexity exposent des signaux distincts et vérifiables. Tu peux séparer leur crawler d’entraînement, leur crawler de récupération et leurs fetches live, et confirmer chacun par IP.
Google ne fonctionne pas ainsi. Il existe un seul Googlebot. Que le contenu collecté alimente Gemini dépend d’un token robots.txt appelé Google-Extended. Ce token n’est pas un crawler : il n’effectue aucune requête. C’est un flag de permission sur un crawl déjà effectué.
Conséquence : il n’y a pas de “Gemini fetcher” dans tes logs, par conception. Tu ne peux pas mesurer la demande Gemini de la même façon que ChatGPT ou Claude.
Forrester y voit un écho à 2011, quand Google a chiffré ses référents de recherche et fait disparaître les données de mots-clés dans “(not provided)”. Là où ses concurrents exposent entraînement, récupération et demand comme des événements séparables, Google les regroupe dans un crawl unique avec un token invisible. C’est, comme dirait Forrester, “not provided” version 2.
Si tu t’intéresses à la mesure de ta visibilité sur les IA ou au suivi de tes citations dans les moteurs IA, cette asymétrie de mesure entre Gemini et les autres est un point de friction majeur à garder en tête.
Comment lancer ton propre audit de logs
La méthode tient en quelques étapes claires :
- Extraire les requêtes bots de tes access logs sur une période représentative (minimum 14 jours, idéalement 30).
- Créer trois colonnes :
verified(IP dans la plage publiée),spoofed(plage chargée, IP absente),unverifiable(plage non chargeable ou enregistrement manquant). - Croiser nom du bot + IP avec les fichiers JSON officiels listés plus haut.
- Pour les cas non vérifiables : reverse DNS, vérification du corpus pour les crawlers d’entraînement, WHOIS sur les IPs brutes.
- Regarder où vont les faux bots : les destinations inhabituelles (fichiers
.env,config.yml, fichiers secrets) trahissent des scanners, pas des bots légitimes.
L’outil de base (environ 15 lignes de Python avec la bibliothèque standard) suffit pour le matching IP/plage. Ce n’est pas un analyseur de logs complet, mais c’est le cœur du mécanisme de vérification.
Pour aller plus loin sur l’écosystème des outils d’audit, la question des outils SEO tiers et de leurs métriques est directement connectée : aucun outil tiers n’a accès à ce niveau de granularité sur le crawl réel de Google.
Ce que la vérification te dit, et ce qu’elle ne te dit pas
Un crawl confirmé signifie qu’un vrai bot a pris ton contenu. Ça ne dit pas ce qui s’est passé ensuite : si ta page a fini dans la réponse visible, si tu as été cité, paraphrasé sans crédit, ou ignoré. Si le modèle qui s’est entraîné sur toi va mentionner ton nom ou t’absorber silencieusement.
La récupération, c’est ta visibilité aujourd’hui. L’entraînement, c’est si le modèle te connaît demain sans avoir à te chercher. La plupart des tableaux de bord mesurent le premier. Le second est plus silencieux, et personne ne le regarde vraiment.
C’est exactement ce décalage entre “être crawlé” et “être utilisé” qui donne tout son sens au travail de vérification dans les logs.
Mon avis : si tu ne regardes jamais tes logs serveur directement, tu pilotes à l’aveugle. GA4 filtre et agrège. Les logs, eux, racontent ce qui s’est vraiment passé, y compris les tentatives hostiles qui se déguisent en bots légitimes. Même sur un petit site, l’exercice est utile une fois par trimestre. Et si tu veux développer cette compétence dans une stratégie SEO plus globale, c’est exactement le type d’audit qu’on pratique chez mon agence AskOptimize.
FAQ
Comment savoir si les Googlebot dans mes logs sont vrais ?
Vérifie si l’IP de chaque requête appartient aux plages publiées par Google sur https://developers.google.com/static/crawling/ipranges/common-crawlers.json. Le nom “Googlebot” dans le user-agent ne prouve rien : c’est auto-déclaré et facilement usurpé.
Pourquoi des bots se font passer pour des agents IA comme ChatGPT ?
Pour contourner les filtres de sécurité. Les noms d’agents IA réputés sont moins bloqués par défaut. Derrière, ce sont souvent des scanners de credentials qui cherchent des fichiers de configuration exposés (.env, config.json, etc.).
Quelle est la différence entre un crawler d’entraînement et un agent IA en mode live ?
Un crawler d’entraînement (GPTBot, ClaudeBot) indexe ton contenu en arrière-plan pour alimenter les futurs modèles. Un agent en mode live (ChatGPT-User, Claude-User) va chercher ta page en temps réel pendant une conversation utilisateur. Ce sont des bots différents, avec des IPs différentes et des impacts différents sur ta visibilité.
Peut-on mesurer les visites de Gemini dans ses logs ?
Non, pas directement. Google n’expose pas de crawler Gemini distinct. Google-Extended est un flag dans robots.txt, pas un bot qui génère des requêtes mesurables. Tu peux vérifier Googlebot par IP, mais tu ne peux pas distinguer ce qui alimente Gemini de ce qui ne l’alimente pas.
Faut-il bloquer les bots non vérifiés via robots.txt ou le pare-feu ?
La décision dépend de ton objectif. Les scanners malveillants méritent un blocage au niveau du pare-feu ou via fail2ban. Les vrais bots IA légitimes peuvent être gérés via robots.txt ou les tokens dédiés (GPTBot, CCBot). Ne bloque pas par défaut sur la base du user-agent seul : vérifie l’IP d’abord.
