Logs serveur et crawlers IA, savoir qui visite vraiment votre site

Lisez vos logs serveur. Chaque requête y laisse une ligne avec l'adresse IP, la date, l'URL demandée, le code HTTP et le user-agent. Filtrez ce fichier sur les jetons des agents IA, comptez les lignes par agent et par URL, et vous obtenez la fréquence de visite, les pages explorées et celles qui ne le sont jamais.

Aucun autre outil ne donne cette vue. La Search Console ne rapporte que Googlebot, GA4 ne mesure qu'un visiteur humain dont le navigateur exécute du JavaScript, et un crawler IA n'en exécute généralement pas. Les logs, eux, enregistrent la requête au niveau du serveur, avant tout rendu et avant tout consentement analytique. C'est aussi la seule source capable de vous dire qu'une page importante n'a jamais été demandée, ce qu'aucun tableau de bord de citations ne peut faire.

Le travail se fait en quatre temps, et chacun répond à une question différente.

• Collecter. Vérifiez que votre couche d'entrée écrit bien le user-agent et le code HTTP, ce qui n'est pas garanti par défaut sur toutes les plateformes.
• Filtrer. Isolez les lignes dont le user-agent contient un jeton d'agent IA connu, en insensible à la casse.
• Agréger. Comptez les visites par agent, par URL et par code HTTP, puis relevez la date de dernière visite pour chaque page.
• Vérifier. Confrontez les adresses IP aux plages publiées par le fournisseur avant de tirer la moindre conclusion sur l'identité d'un agent.

Avant de plonger dans les logs. Vérificateur d'accès des crawlers IA | Simulateur de crawler IA

Trois choses très différentes atterrissent dans le même fichier de log, et les confondre fausse toute lecture. Le crawl automatisé est programmé par le fournisseur, il parcourt le site sans qu'aucun internaute ne l'ait demandé, et il alimente soit un index de recherche soit un jeu de données d'entraînement. La récupération déclenchée par un internaute part d'une question posée dans un assistant, elle ne concerne qu'une poignée d'URL et elle est souvent immédiate. Le trafic humain référé n'est pas un robot du tout, c'est une personne qui a cliqué sur un lien de citation dans une réponse IA, et il se repère dans le champ referer plutôt que dans le user-agent.

La documentation des fournisseurs assume cette séparation. OpenAI distingue OAI-SearchBot, qui fait remonter des sites dans les résultats de recherche de ChatGPT, GPTBot, dédié aux modèles de fondation, et ChatGPT-User, déclenché par certaines actions d'un utilisateur. Anthropic sépare de la même façon ClaudeBot, Claude-SearchBot et Claude-User. Perplexity oppose PerplexityBot, qui sert la recherche, à Perplexity-User, qui répond à une action dans le produit.

Cette nuance a une conséquence directe sur robots.txt. OpenAI écrit que ses règles peuvent ne pas s'appliquer aux actions initiées par un utilisateur, Perplexity indique que Perplexity-User ignore généralement robots.txt, et Google formule la même chose pour ses récupérateurs déclenchés par un utilisateur. Voir passer un de ces agents malgré une règle de blocage n'est donc pas forcément un incident, c'est le comportement documenté.

OpenAI, robots et crawlers | Anthropic, exploration du web | Perplexity, crawlers | Google, récupérateurs déclenchés par un utilisateur

Le format combined suffit pour commencer, à condition d'y ajouter la durée de réponse. Nginx le définit d'office avec l'adresse client, l'utilisateur, la date locale, la ligne de requête, le statut, les octets du corps, le referer et le user-agent. Il manque un seul champ vraiment utile pour un diagnostic de crawl, le temps de traitement, disponible dans la variable request_time que la documentation décrit comme le temps de traitement de la requête en secondes avec une résolution à la milliseconde.

Apache expose le même jeu de champs avec sa directive LogFormat. Son format combined reprend l'hôte, la date, la requête, le statut final et les deux en-têtes Referer et User-Agent. Deux ajouts valent la peine, la durée en microsecondes avec le spécificateur D, et les octets réellement envoyés en-têtes comprises avec le spécificateur O, qui nécessite le module mod_logio.

# nginx.conf, le format combined enrichi de la latence de réponse
log_format ai_agents '$remote_addr - $remote_user [$time_local] '
                     '"$request" $status $body_bytes_sent '
                     '"$http_referer" "$http_user_agent" $request_time';

access_log /var/log/nginx/access.log ai_agents;

nginx, ngx_http_log_module | Apache, fichiers de journaux | Apache, mod_log_config

Sous Apache, la logique est identique et seule la syntaxe change. Déclarez un format nommé, puis pointez CustomLog dessus. Gardez le statut final avec le modificateur supérieur, sinon une redirection interne vous fera enregistrer le statut de la requête d'origine plutôt que celui réellement servi.

# httpd.conf, combined enrichi des octets réels et de la durée
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\" %D" ai_agents
CustomLog logs/access_log ai_agents

Ces commandes ne contiennent aucune donnée client et fonctionnent sur n'importe quel fichier au format combined. Le champ 9 correspond au code HTTP et le champ 7 à l'URL demandée dans ce format, ce qui rend les agrégations directes. Adaptez la liste des jetons à votre marché, un site francophone verra surtout OpenAI, Google, Perplexity et Anthropic.

La sixième commande est la plus utile et la plus rarement exécutée. Elle compare la liste des URL réellement visitées à votre liste de pages prioritaires et vous rend la différence, autrement dit les pages qu'aucun agent IA n'est jamais venu chercher. Un contenu jamais exploré ne peut être ni indexé ni cité, quelle que soit sa qualité éditoriale.

AI='GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Googlebot|GoogleOther|bingbot|meta-externalagent'

# 1. Toutes les visites d'agents IA, tous statuts confondus
grep -Ei "$AI" access.log

# 2. Volume par agent, du plus actif au moins actif
grep -Eio "$AI" access.log | sort | uniq -c | sort -rn

# 3. Uniquement les réponses en erreur servies à un agent
grep -Ei "$AI" access.log | awk '$9 ~ /^(403|404|429|500|503)$/'

# 4. Les 20 URL les plus explorées par GPTBot
grep -i 'GPTBot' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

# 5. Dernière visite enregistrée pour un agent donné
grep -i 'ClaudeBot' access.log | tail -1

# 6. Pages prioritaires jamais visitées, par différence avec le sitemap
grep -Ei "$AI" access.log | awk '{print $7}' | sort -u > vues.txt
comm -23 pages-prioritaires.txt vues.txt

Pour construire la liste des pages prioritaires. Générateur llms.txt | Hikoo Analyzer

Un en-tête user-agent est une chaîne de texte libre choisie par le client. N'importe qui peut envoyer une requête en se déclarant GPTBot, et votre log l'enregistrera tel quel. Une ligne de log n'est donc jamais la preuve qu'un fournisseur est passé, elle prouve seulement qu'une requête a revendiqué cette identité. Tant que vous restez au niveau du comptage de tendances, l'approximation est acceptable. Dès que vous décidez de bloquer, de facturer ou de servir un contenu différent, elle ne l'est plus.

Deux méthodes documentées permettent de trancher. La première est la comparaison de l'adresse IP aux plages publiées par le fournisseur. OpenAI publie un fichier par robot, Anthropic publie une liste unique, Perplexity publie un fichier par crawler. La seconde est le DNS inverse suivi d'un DNS direct, la méthode que Google documente pour Googlebot, où l'adresse doit résoudre vers un nom sous googlebot.com, google.com ou googleusercontent.com, et où ce nom doit ensuite résoudre vers l'adresse de départ.

Une troisième voie se met en place. Web Bot Auth fait signer les requêtes par le robot avec les en-têtes Signature, Signature-Input et Signature-Agent, en s'appuyant sur les signatures de messages HTTP du RFC 9421 et sur des clés Ed25519. La vérification devient cryptographique et ne dépend plus d'une liste d'adresses à tenir à jour. Cloudflare l'implémente déjà pour ses robots vérifiés, et les spécifications correspondantes sont encore en cours à l'IETF, donc l'usage reste partiel à ce jour.

# 1. DNS inverse sur l'adresse relevée dans le log
host 66.249.66.1
# 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

# 2. DNS direct sur le nom obtenu, il doit rendre la même adresse
host crawl-66-249-66-1.googlebot.com
# crawl-66-249-66-1.googlebot.com has address 66.249.66.1

# 3. Fournisseurs qui publient leurs plages en CIDR
curl -s https://openai.com/gptbot.json
curl -s https://claude.com/crawling/bots.json
curl -sL https://www.perplexity.com/perplexitybot.json

Google, vérifier Googlebot | Cloudflare, Web Bot Auth | IETF, architecture Web Bot Auth

Avant d'interpréter un fichier de log, vérifiez que votre chaîne écrit bien ce que vous croyez. Envoyez une requête à votre propre site avec un user-agent de test, puis relisez la ligne produite. Si le user-agent est tronqué, si le statut est celui d'une redirection intermédiaire ou si la requête n'apparaît pas du tout parce qu'un cache en amont l'a servie, vous le découvrez maintenant plutôt qu'au milieu d'une analyse.

La capture ci-dessous montre exactement cela sur un serveur local. Il s'agit d'une requête de test émise depuis notre propre poste avec une chaîne user-agent imitant celle de GPTBot, pas d'une visite d'un crawler officiel. Le seul but est de prouver que le format de log capture le user-agent, le statut et la durée, et que les erreurs apparaissent bien elles aussi.

# Requête de TEST vers notre propre serveur local, avec un user-agent de test.
# Ce n'est pas une visite d'un crawler officiel.

$ UA="Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot"
$ curl -s -o /dev/null -w "%{http_code} %{size_download} %{time_total}\n" -A "$UA" \
    http://localhost:3010/fr/blog/guides/logs-serveur-crawlers-ia-guide-2026/
200 460948 0.016284

$ curl -s -o /dev/null -w "%{http_code} %{size_download} %{time_total}\n" -A "$UA" \
    http://localhost:3010/fr/blog/guides/page-qui-nexiste-pas/
404 8376 0.023425

# Les deux lignes réellement écrites dans access.log par le format combined + $request_time

$ tail -2 access.log
::1 - - [31/Aug/2026:18:55:31 +0200] "GET /fr/blog/guides/logs-serveur-crawlers-ia-guide-2026/ HTTP/1.1" 200 460948 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot" 0.014
::1 - - [31/Aug/2026:18:55:31 +0200] "GET /fr/blog/guides/page-qui-nexiste-pas/ HTTP/1.1" 404 8376 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot" 0.020

Le code HTTP est le champ le plus rentable du fichier, car il dit ce que l'agent a réellement reçu. Un 200 sur une page vide ne vaut pas mieux qu'un 404, et un 403 répété sur une section entière signale presque toujours une règle de pare-feu applicatif ou une protection anti-robot qui bloque un agent que vous pensiez autoriser.

Le 429 mérite une attention particulière. Le RFC 6585 le définit comme la réponse à un client qui a envoyé trop de requêtes dans un laps de temps donné, avec un en-tête Retry-After facultatif indiquant le délai d'attente. Servi massivement à un crawler, il ralentit son exploration et repousse la découverte de vos nouvelles pages. Anthropic documente d'ailleurs la prise en charge de l'extension non standard Crawl-delay dans robots.txt, une façon plus propre de réguler le rythme qu'un rejet en 429.

RFC 6585, code 429 | Anthropic, Crawl-delay

Une requête traverse plusieurs couches et chacune ne journalise qu'une partie de l'histoire. Le CDN voit tout le trafic, y compris ce qu'il sert depuis son cache et qui n'atteindra jamais votre origine. Le serveur d'origine ne voit que les requêtes passées à travers. Si vous n'analysez que les logs d'origine derrière un CDN agressif, vous sous-estimez systématiquement l'activité des crawlers.

Sur Vercel, les journaux d'exécution exposent la méthode, le chemin demandé, le statut, la région, l'état du cache et le user-agent de la requête. Deux limites comptent. D'abord, les requêtes statiques n'apparaissent que lorsqu'elles sont servies depuis le cache, et la documentation renvoie vers les Log Drains pour obtenir la totalité des requêtes statiques. Ensuite, la rétention est courte, une heure sur le plan Hobby, un jour sur Pro, trois jours sur Enterprise, et trente jours avec Observability Plus. Une analyse de crawl sur trente jours suppose donc un export, pas une simple consultation.

Sur Cloudflare, le jeu de champs du dataset des requêtes HTTP couvre exactement ce dont une analyse de crawl a besoin, notamment ClientRequestUserAgent, ClientIP, ClientRequestPath, EdgeResponseStatus, EdgeResponseBytes et EdgeTimeToFirstByteMs. Les clients Bot Management disposent en plus de BotScore et de VerifiedBotCategory. Cloudflare propose aussi AI Crawl Control, anciennement AI Audit, qui montre quels services IA accèdent au contenu et fonctionne sur tous les plans.

Vercel, journaux d'exécution | Cloudflare, champs de log HTTP | Cloudflare, AI Crawl Control

Un suivi de crawl IA utile tient en neuf colonnes. Elles suffisent à répondre aux seules questions qui comptent, à savoir qui vient, où, à quel rythme, avec quel résultat, et ce qui reste invisité. Tout ce qui dépasse cette liste relève du confort, pas du diagnostic.

Deux indicateurs méritent d'être suivis dans le temps plutôt qu'en valeur instantanée. La couverture des pages prioritaires, c'est à dire la part de vos URL stratégiques visitées au moins une fois sur la période, mesure votre exposition réelle. La part d'erreurs servies aux agents se dégrade souvent en silence après une mise à jour de pare-feu ou un changement de plan CDN, et une hausse soudaine explique presque toujours une chute de visites la semaine suivante.

Un 200 dans les logs ne dit pas ce qui a été servi. Une page peut répondre correctement et ne contenir qu'un squelette HTML dont le texte n'arrive qu'après exécution du JavaScript, ce que la plupart des crawlers IA ne font pas. Le log vous donne le statut, le simulateur vous donne le contenu.

Sur la capture ci-dessous, nous avons soumis une page publique de notre propre blog au simulateur de crawler Hikoo. Le résultat affiche le nombre de mots réellement lisibles, le nombre de titres et de liens, et le texte brut tel qu'un agent le reçoit. Croisez systématiquement les deux, un statut 200 dans le log et un volume de mots cohérent dans le simulateur.

Outils utilisés. Simulateur de crawler IA | Vérificateur d'accès des crawlers IA | Audit IA gratuit

Un access.log contient des adresses IP, donc des données à caractère personnel dès que des visiteurs humains y figurent. Une analyse de crawl n'a pourtant besoin d'aucune donnée identifiante une fois la vérification d'identité faite. Traitez la vérification et l'analyse comme deux étapes distinctes, la première sur la donnée brute et de courte durée, la seconde sur un jeu agrégé conservé plus longtemps.

• Fixez une durée de conservation explicite pour les logs bruts et automatisez la purge, la rétention par défaut de votre hébergeur n'est pas une politique.
• Anonymisez l'adresse IP après vérification, par exemple en tronquant le dernier octet en IPv4 et les derniers segments en IPv6.
• Ne conservez pour l'analyse de crawl que l'agent normalisé, l'URL, la date, le statut, les octets et la latence.
• Retirez les paramètres de requête des URL agrégées, ils transportent souvent des identifiants de session ou de campagne.
• Documentez la finalité et la durée dans votre registre de traitement, une analyse technique reste un traitement.
• Restreignez les logs bruts aux personnes qui en ont un besoin opérationnel, et journalisez ces accès.

L'analyse manuelle répond à une question ponctuelle. Elle tient mal dans la durée, parce qu'il faut collecter, dédupliquer, vérifier les identités, conserver l'historique au delà de la rétention de la plateforme, et refaire l'exercice à chaque changement d'infrastructure.

Hikoo intègre un suivi des agents IA dans le tableau de bord. Il enregistre les visites des crawlers IA sur votre site, quand ils passent, à quelle fréquence et quelles pages ils consultent, agent par agent. Cette vue s'ajoute à Spotlight, qui mesure de son côté les citations de votre marque dans les réponses IA. Les deux répondent à des questions différentes, l'une dit ce que les agents lisent chez vous, l'autre dit ce qu'ils en disent ailleurs.

Le rapprochement est la valeur réelle. Une page très explorée et jamais citée pose un problème de contenu, une page jamais explorée pose un problème technique, et seule la lecture conjointe permet de trancher. Hikoo Analyzer complète le tableau en notant la lisibilité de chaque page pour la récupération.

Continuer. Hikoo Spotlight | Hikoo Analyzer | robots.txt et crawlers IA | Préparer son site pour les agents IA | Mesurer le trafic IA dans GA4 | Visibilité IA

Les logs serveur restent la seule mesure exhaustive du passage des agents IA sur votre site. Ils disent quelles pages sont lues, à quel rythme, avec quel code HTTP, et lesquelles restent invisitées, là où les outils analytiques classiques ne voient rien. Le travail se résume à enrichir le format de log, filtrer sur les bons jetons, vérifier les identités par adresse IP, puis suivre neuf colonnes dans le temps.

La suite naturelle est de croiser cette lecture technique avec la mesure de vos citations. Commencez par un audit gratuit de votre site pour situer votre lisibilité pour les agents, puis suivez dans Hikoo à la fois les visites des crawlers et les citations de votre marque. C'est le rapprochement des deux qui vous dit quoi corriger en premier.