Détecter les crawlers IA dans vos logs serveur : la méthode complète

En bref — Les crawlers IA n'exécutent pas JavaScript : ils sont donc totalement absents de Google Analytics et de tout outil à balise. Vos logs serveur sont la seule source qui les enregistre. Les repérer se fait en deux temps : identifier la chaîne de user-agent (GPTBot, ClaudeBot, OAI-SearchBot, PerplexityBot…), puis vérifier que l'adresse IP appartient bien aux plages officielles de l'opérateur — le user-agent seul se falsifie en une ligne de commande. OpenAI, Google, Perplexity et Apple publient leurs plages dans des fichiers JSON ; Anthropic n'en publie pas, ce qui rend ses robots invérifiables par cette méthode. Sur nos propres logs, huit jours d'observation ont suffi à montrer que trois robots présentés comme équivalents se comportent très différemment.

Un responsable SEO qui consulte son outil d'analyse d'audience et n'y voit aucun robot IA en conclut souvent que son site n'intéresse pas ces moteurs. La conclusion est erronée, et l'erreur est structurelle : les crawlers IA ne déclenchent aucune balise JavaScript, donc aucun outil fondé sur ce mécanisme ne peut les voir. Ils passent, ils lisent, ils repartent, et le tableau de bord reste vide.

Cet article décrit la méthode complète pour les détecter à la source, dans le journal des requêtes de votre serveur : quels champs regarder, comment reconnaître chaque robot, et surtout comment distinguer un robot authentique d'un scraper qui usurpe son identité. Nous illustrons chaque point avec des chiffres tirés de nos propres logs.

Pourquoi les crawlers IA sont invisibles dans Google Analytics

Les outils d'analyse d'audience grand public fonctionnent par balise : un fragment de JavaScript s'exécute dans le navigateur du visiteur et envoie un signal. Ce mécanisme suppose un client qui exécute du code. Or la quasi-totalité des crawlers d'entraînement se contentent de récupérer le HTML brut sans jamais l'interpréter.

La conséquence est nette : un site peut recevoir plusieurs centaines de visites de robots IA par semaine sans qu'aucune n'apparaisse dans son rapport d'audience. À l'inverse, un journal de serveur enregistre chaque requête reçue, qu'elle vienne d'un humain, d'un moteur ou d'un script. C'est une différence de nature, pas de précision.

Cette invisibilité a une conséquence pratique souvent sous-estimée : elle rend impossible tout arbitrage éclairé sur le blocage des robots IA. Décider d'autoriser ou de refuser un crawler sans savoir ce qu'il consomme réellement revient à légiférer à l'aveugle.

Où regarder : les champs utiles d'une ligne de log

Une ligne de journal au format combiné, le plus répandu sur Apache et Nginx, contient tout ce qui est nécessaire. Quatre champs comptent pour la détection : l'adresse IP du client, l'horodatage, l'URL demandée avec son code de réponse, et le user-agent en fin de ligne.

Le user-agent sert à l'identification, l'adresse IP à la vérification, le code de réponse au diagnostic, et l'URL à comprendre ce qui intéresse le robot. Aucun de ces champs n'est suffisant seul ; c'est leur croisement qui produit une information fiable. Si vous ne savez pas où trouver ces fichiers, notre guide détaille comment récupérer ses logs selon son hébergement.

Un point mérite attention sur les piles modernes : certains robots qui exécutent le JavaScript génèrent des requêtes internes au framework, reconnaissables à des paramètres techniques. Sur nos logs, 86,2 % des requêtes de GoogleOther n'étaient pas des pages mais des charges utiles internes. Les compter comme des visites de pages fausse toute lecture de volume.

Reconnaître un crawler IA à sa chaîne de user-agent

Chaque opérateur publie la chaîne exacte de ses robots. La détection consiste à chercher une sous-chaîne caractéristique, insensible à la casse, dans le champ user-agent.

Côté OpenAI, trois agents distincts se partagent trois rôles : GPTBot collecte pour l'entraînement des modèles, OAI-SearchBot construit l'index de la recherche ChatGPT, et ChatGPT-User consulte une page en direct quand un utilisateur clique sur une citation. Ce sont trois jetons robots.txt séparés et trois décisions indépendantes — le détail de chacun figure sur les fiches GPTBot, OAI-SearchBot et ChatGPT-User.

Côté Anthropic, la répartition est comparable : ClaudeBot pour l'entraînement, Claude-SearchBot pour la qualité des résultats de recherche, Claude-User pour les consultations déclenchées par un utilisateur. Côté Google, Googlebot explore pour la recherche, Google-Extended régit l'usage du contenu par les produits d'IA générative, et GoogleOther couvre les autres usages internes. PerplexityBot et Applebot complètent la liste des agents courants.

Nous maintenons une fiche par robot dans notre référentiel des crawlers, avec pour chacun la chaîne complète, le jeton robots.txt, la source officielle et l'enjeu de visibilité associé.

Pourquoi le user-agent ne suffit jamais : l'usurpation

Le champ user-agent est déclaratif. Il est renseigné par le client, jamais vérifié par le serveur, et n'importe qui peut s'annoncer comme Googlebot ou GPTBot en ajoutant une option à une commande curl. Une détection fondée sur ce seul champ est donc structurellement peu fiable.

Ce n'est pas un risque théorique. Les scrapers commerciaux usurpent couramment l'identité des robots légitimes, précisément parce que la plupart des sites les laissent passer sans contrôle. Conséquence directe : un rapport de crawl non vérifié surestime l'intérêt réel des moteurs pour votre site, et peut vous conduire à des décisions fondées sur du bruit.

L'enjeu est aussi défensif. Un site qui décide de bloquer un robot d'entraînement n'obtient rien s'il filtre sur le user-agent : l'usurpateur change de chaîne, le robot légitime obéit. Le blocage frappe alors exactement le mauvais acteur — celui qui respecte les règles.

Vérifier l'authenticité d'un crawler par plage d'IP

La méthode fiable consiste à vérifier que l'adresse IP de la requête appartient aux plages officiellement publiées par l'opérateur du robot. Contrairement au user-agent, une adresse IP ne se falsifie pas dans une requête HTTP aboutie : la réponse doit revenir quelque part.

OpenAI publie ses plages dans des fichiers JSON dédiés, distincts pour chacun de ses agents. Google publie également les siennes, tout comme Perplexity et Apple. La vérification consiste à charger ces listes, puis à tester l'appartenance de chaque adresse observée aux blocs déclarés.

Anthropic ne publie pas de plages d'IP officielles, et sa documentation indique que le blocage par IP n'est pas fiable. Les robots ClaudeBot, Claude-SearchBot et Claude-User ne sont donc pas vérifiables par cette méthode : c'est une limite réelle, qu'il faut connaître plutôt que masquer par une fausse certitude.

Pour Googlebot, une seconde méthode existe et fait référence : la résolution DNS inverse. On résout l'adresse IP en nom d'hôte, on vérifie qu'il se termine par un domaine appartenant à Google, puis on résout ce nom en sens inverse pour confirmer qu'il pointe vers l'adresse de départ. Le double sens est indispensable — une résolution simple se contrefait.

→ Vérifiez vos propres logs dans l'analyseur Crawl Lab : il isole chaque robot, teste l'authenticité de chaque requête contre les plages d'IP officielles, et sépare les hits vérifiés des usurpations probables. Tout se passe dans votre navigateur, aucun fichier n'est téléversé.

Le piège du CDN : quand l'adresse IP de vos logs n'est pas celle du robot

Il existe une configuration où toute la vérification par plage d'IP échoue silencieusement, et elle est extrêmement répandue : le site est servi derrière un CDN ou un proxy inverse. Dans ce cas, la connexion que voit votre serveur d'origine ne vient pas du robot, mais du nœud du CDN qui relaie la requête.

Le symptôme est caractéristique : toutes vos requêtes semblent provenir d'une poignée d'adresses appartenant à votre fournisseur d'infrastructure, et aucun robot ne ressort comme authentique puisque aucune adresse observée n'appartient aux plages d'OpenAI ou de Google. Le rapport conclut à une usurpation généralisée, alors que le problème est purement une question de configuration de journalisation.

La correction consiste à journaliser l'adresse d'origine transmise par le proxy plutôt que l'adresse de connexion. Les CDN ajoutent cette information dans un en-tête dédié — X-Forwarded-For dans le cas général, CF-Connecting-IP chez Cloudflare — et il faut adapter le format de journalisation d'Apache ou de Nginx pour l'écrire dans le fichier. Sans cette étape, la vérification d'authenticité n'a aucune valeur.

Cette dépendance au CDN a une seconde conséquence, développée dans notre article sur le blocage par défaut des crawlers IA au 15 septembre 2026 : un robot refusé au niveau du réseau n'atteint jamais votre serveur, et ne laisse donc aucune ligne dans vos logs. Il ne produit pas une erreur, il produit une absence — le signal le plus difficile à repérer sans point de comparaison antérieur.

Distinguer les trois familles : entraînement, citation, agent

Détecter un robot ne suffit pas ; il faut savoir ce qu'il fait de votre contenu. Trois familles se distinguent par leur finalité, et cette distinction commande toutes les décisions qui suivent.

Les robots d'entraînement collectent du texte pour alimenter les corpus qui servent à entraîner les modèles. Le contenu est absorbé dans les poids du modèle : il n'existe aucun mécanisme de citation ni de renvoi de trafic. GPTBot, ClaudeBot et Google-Extended relèvent de cette catégorie.

Les robots de citation construisent un index destiné à répondre aux questions en citant leurs sources, avec un lien cliquable. Ce sont eux qui peuvent vous envoyer des lecteurs : OAI-SearchBot, Claude-SearchBot et PerplexityBot. Les bloquer revient à sortir des réponses IA sourcées.

Les agents consultent une page en temps réel parce qu'un humain l'a demandé, comme ChatGPT-User. Leur volume est faible mais leur signal est fort : chaque requête correspond à une intention utilisateur réelle. Cette tripartition recoupe les catégories que Cloudflare a rendues configurables, un changement dont les conséquences sont détaillées dans notre article sur le blocage par défaut du 15 septembre 2026.

Ce que le volume révèle : lire les signaux dans les chiffres

Une fois les robots identifiés et vérifiés, leur profil de crawl devient interprétable. Sur nos propres logs — un site mis en ligne treize jours plus tôt, 1 722 requêtes de robots sur huit jours — trois comportements nettement distincts sont apparus.

GPTBot a émis 56 requêtes depuis trois adresses IP, couvrant 49 URL distinctes : un balayage en largeur, presque une page par requête. ClaudeBot a produit 224 requêtes sur seulement 56 URL sur la même période : un comportement de repassage insistant sur un périmètre restreint. Deux robots d'entraînement, deux stratégies opposées.

OAI-SearchBot a émis 57 requêtes depuis quatorze adresses IP, dont un tiers portait un paramètre interne au framework — la signature d'un robot qui exécute le JavaScript de la page. GPTBot, lui, n'a produit aucune requête de ce type. Si votre contenu dépend du rendu côté client, les deux robots d'OpenAI ne voient donc pas la même chose de votre site.

Claude-SearchBot n'est pas apparu une seule fois. Nous nous gardons d'en tirer une règle : l'absence d'un robot de citation sur un domaine de deux semaines est un comportement attendu, pas un symptôme. Le détail complet de ces mesures figure dans notre étude de cas sur le budget de crawl d'un site neuf.

Les faux positifs classiques à écarter

Trois erreurs de lecture reviennent systématiquement. La première consiste à compter les requêtes de fichiers d'infrastructure — robots.txt, sitemaps, llms.txt — comme du budget de crawl gaspillé. Ces fichiers guident l'exploration : un robot doit les récupérer, et leur présence dans les logs est un signe de bon fonctionnement.

La deuxième consiste à traiter les requêtes internes au framework comme des vues de pages. Sur une pile moderne, un robot qui rend le JavaScript peut multiplier les requêtes techniques pour une seule page réelle, ce qui gonfle artificiellement son volume apparent.

La troisième consiste à interpréter une variation de volume sans regarder les codes de réponse. Une chute de crawl peut refléter un désintérêt du moteur — ou simplement le fait que votre serveur a renvoyé des erreurs. Sur nos logs, pendant trois jours d'erreurs 500, le crawl d'un robot a chuté de 81 % quand celui d'un autre ne perdait que 16 %. La lecture des codes est détaillée dans notre guide sur les erreurs 404 et 5xx vues par les crawlers.

Mettre la détection en routine

Une détection ponctuelle a peu de valeur ; c'est la série qui informe. Relever chaque mois le volume par robot, la part de requêtes vérifiées, et la répartition des codes de réponse permet de repérer une anomalie au moment où elle se produit plutôt que six semaines plus tard.

Ce relevé prend quelques minutes une fois le processus rodé, et il constitue la seule base défendable pour arbitrer sur le blocage des robots IA. Les KPI à suivre et leur interprétation font l'objet d'un guide dédié.

À lire aussi

• Analyse de log serveur pour le SEO : le guide complet (2026)
• Cloudflare bloque les crawlers IA par défaut le 15 septembre 2026
• Budget de crawl d'un site neuf : ce que nos logs montrent
• Analyse de log SEO : quels KPI suivre et comment les interpréter
• Récupérer ses logs serveur : Apache, Nginx, cPanel, CDN