Logs serveur : détecter et analyser le passage des robots IA.

Les journaux serveur sont la seule preuve directe qu'un robot IA lit vos pages

Un outil d'analyse d'audience ne voit pas les robots. Google Analytics et ses équivalents reposent sur un script JavaScript que les robots de recherche IA n'exécutent pas ; un rapport de positions ne les voit pas davantage. Le seul endroit où le passage de OAI-SearchBot, de Claude-SearchBot ou de PerplexityBot laisse une trace vérifiable est le journal d'accès de votre serveur web, ou celui de votre CDN lorsqu'un intermédiaire répond à leur place.

Cette trace tranche trois questions que rien d'autre ne permet de trancher. Le robot vient-il, et à quelle fréquence ? Quelles pages lit-il, et lesquelles ignore-t-il ? Que lui répond votre serveur : une page complète, une redirection, une erreur 403 posée par un pare-feu ? Dans nos audits, la lecture des journaux est l'étape qui transforme une hypothèse (« nous sommes probablement bloqués ») en constat daté, et c'est souvent elle qui explique l'absence d'un site bien référencé dans les réponses génératives. Elle vérifie la première des quatre conditions d'une citation, l'accessibilité, avec des faits plutôt qu'avec des suppositions.

Deux précautions avant de commencer. Lisez les journaux au bon endroit : si un CDN ou un pare-feu applicatif filtre le trafic en amont, une requête bloquée n'atteint jamais le serveur d'origine, et son absence dans les journaux d'origine ne prouve rien ; il faut alors exporter les journaux du CDN, où la requête apparaît avec son code de refus. Conservez ensuite au moins trente jours d'historique : les robots de recherche IA passent bien moins souvent que Googlebot, et une fenêtre d'une semaine conduit à des conclusions fausses, dans un sens comme dans l'autre.

Quels agents chercher, et ce que leur présence signifie

Chaque éditeur exploite plusieurs robots, identifiés par un jeton distinct dans l'en-tête User-Agent, et ces jetons n'ont pas la même valeur pour vous. Un robot d'entraînement qui lit votre site ne dit rien de votre visibilité dans les réponses. Un robot d'index de recherche indique que vos pages entrent dans un index consultable au moment d'une question. Un agent déclenché à la demande signale qu'une conversation réelle a conduit le moteur jusqu'à votre page, pendant que l'utilisateur attendait sa réponse. Le guide des robots IA décrit chaque agent et sa syntaxe robots.txt ; le tableau ci-dessous se limite à leur lecture dans un journal.

Tableau : faites défiler horizontalement.

Un cas particulier mérite d'être signalé : Google-Extended n'apparaîtra jamais dans vos journaux. D'après la documentation de Google, ce jeton ne correspond à aucun agent distinct ; il sert uniquement, dans le fichier robots.txt, à contrôler l'usage de vos contenus pour l'entraînement de Gemini, tandis que l'exploration reste effectuée par Googlebot. Chercher Google-Extended dans un journal, ne pas le trouver et en conclure quelque chose est une erreur que nous rencontrons régulièrement.

Lire une ligne de journal : les cinq champs qui comptent

Les serveurs Apache et Nginx écrivent par défaut un format voisin, dit « combiné », dans lequel chaque requête occupe une ligne. Cinq champs suffisent à l'analyse : l'adresse IP d'origine, l'horodatage, la ligne de requête (méthode, URL, protocole), le code de statut renvoyé et l'en-tête User-Agent. La taille de la réponse est un sixième indice utile : quelques centaines d'octets servis à un robot, là où un navigateur reçoit cinquante kilo-octets, signalent une page vidée, une redirection ou un défi anti-robot.

Si votre hébergeur ne donne pas accès à ces fichiers bruts, demandez-lui un export sur trente jours, ou activez la journalisation de votre CDN : la plupart proposent un export vers un stockage externe, ou un tableau de bord filtrable par agent. Un journal tronqué à quelques jours, ou expurgé de l'en-tête User-Agent pour des raisons de volume, ne permet pas l'analyse ; c'est un point à régler avec l'hébergeur avant l'audit.

Les requêtes qui donnent une réponse en dix minutes

Quelques commandes suffisent pour obtenir un premier diagnostic sur un fichier de journal standard, sans outil spécialisé. Les exemples ci-dessous supposent le format combiné ; adaptez les numéros de champs si votre serveur en utilise un autre. L'option -i rend la recherche insensible à la casse, ce qui évite de manquer Bingbot, dont le jeton s'écrit en minuscules dans l'en-tête réel.

# 1. Combien de requêtes par agent sur la période ?
grep -oiE 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot|Perplexity-User|Googlebot|bingbot' access.log | sort | uniq -c | sort -rn

# 2. Quelles pages OAI-SearchBot lit-il le plus ?
grep 'OAI-SearchBot' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

# 3. Que répond le serveur à Claude-SearchBot ? (codes de statut)
grep 'Claude-SearchBot' access.log | awk '{print $9}' | sort | uniq -c

# 4. Passage de PerplexityBot, jour par jour
grep 'PerplexityBot' access.log | awk -F'[' '{print substr($2,1,11)}' | sort | uniq -c

# 5. Pages demandées par les agents à la demande, avec l'heure et le statut
grep -E 'ChatGPT-User|Claude-User|Perplexity-User' access.log | awk '{print $4, $7, $9}'

Lisez les résultats dans cet ordre. La première commande dit si les agents viennent : un compte nul sur trente jours pour OAI-SearchBot et PerplexityBot, alors que Googlebot passe chaque jour, oriente vers un blocage ou vers un site jamais découvert. La troisième dit ce qu'on leur répond : une majorité de codes 403 ou 429 désigne une règle de pare-feu ou une limitation de débit, à corriger avant tout travail de contenu ; l'article sur les blocages involontaires des pare-feu et des CDN détaille les correctifs. La deuxième et la cinquième disent ce qu'ils lisent, et c'est là que la stratégie commence.

Fréquence de passage et pages consultées : ce qu'il faut comparer

Aucun éditeur de moteur génératif ne publie de fréquence d'exploration, et les volumes varient fortement d'un site à l'autre. Deux repères se dégagent néanmoins des journaux que nous analysons. Le premier : les robots d'index de recherche IA passent beaucoup moins souvent que Googlebot, et se concentrent sur un sous-ensemble de pages ; un site de deux mille URL peut n'en voir que quelques dizaines lues par OAI-SearchBot dans le mois. Le second : les agents à la demande sont rares, quelques requêtes par jour sur un site B2B de taille moyenne, mais chacune correspond à une conversation réelle et vaut donc davantage qu'un passage d'indexation.

La comparaison la plus instructive n'oppose pas les agents entre eux, mais les sections du site. Répartissez par répertoire les requêtes des robots d'index d'un côté, celles des agents à la demande de l'autre. Vous découvrez alors quelles pages entrent dans l'index sans jamais servir dans une réponse, et lesquelles sont réellement lues pendant qu'un utilisateur attend.

Ce type de lecture révèle aussi les absences. Une page pilier jamais demandée par un agent à la demande, alors qu'elle est indexée et bien positionnée sur Google, est une page que les moteurs génératifs ne retiennent pas comme source. Le problème n'est plus l'accès, mais la citabilité de son contenu, et c'est un autre chantier.

Authentifier un agent avant d'en tirer une conclusion

L'en-tête User-Agent est déclaratif : n'importe quel script peut se présenter comme GPTBot ou comme Googlebot. Avant de conclure qu'un éditeur lit votre site, ou de bloquer une adresse qui se prétend robot officiel, vérifiez l'origine de la requête. Deux méthodes existent, documentées par les éditeurs eux-mêmes. La première est la résolution DNS inverse : Google et Microsoft indiquent que leurs robots proviennent d'hôtes dont le nom se termine par googlebot.com ou google.com pour l'un, search.msn.com pour l'autre, et qu'une résolution directe du nom obtenu doit ramener à l'adresse initiale. La seconde est la liste d'adresses publiée : OpenAI, Perplexity, Google et Microsoft mettent à disposition des fichiers listant les plages utilisées par chacun de leurs agents.

# Résolution inverse d'une adresse qui se présente comme Googlebot
host 66.249.66.1
# → crawl-66-249-66-1.googlebot.com ; confirmer par la résolution directe
host crawl-66-249-66-1.googlebot.com

# Adresses distinctes qui se présentent comme OAI-SearchBot, par volume
grep 'OAI-SearchBot' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Pour les éditeurs qui publient une liste, comparez les adresses relevées dans vos journaux aux plages annoncées ; pour les autres, tenez-vous à la documentation la plus récente, car ces listes évoluent. Une adresse qui ne figure dans aucune plage et se présente sous un jeton officiel est presque toujours un outil tiers, un aspirateur de contenu ou un concurrent qui teste votre site. Elle ne doit ni fausser votre lecture, ni déclencher un blocage du jeton lui-même : bloquez l'adresse, jamais l'agent.

Relier les passages aux citations que vous obtenez

Les journaux prennent tout leur sens rapprochés de la mesure de la part de citation. Le principe est simple : vous exécutez votre panel de questions dans les moteurs, vous relevez les URL citées, puis vous cherchez ces mêmes URL dans les journaux, en particulier dans les requêtes des agents à la demande autour de l'heure d'exécution. Le croisement produit quatre situations, et chacune appelle une décision différente.

Deux nuances empêchent de lire ce croisement de manière mécanique. D'abord, une citation n'implique pas toujours une requête à la demande : le moteur peut répondre à partir de son index, alimenté plus tôt par OAI-SearchBot ou PerplexityBot, sans relire la page pendant la conversation. Ensuite, une requête à la demande ne garantit pas une citation : le moteur a lu la page, puis l'a écartée au profit d'une autre source, ce qui désigne un problème de contenu plutôt que d'accès. Ce sont précisément ces pages, lues mais non retenues, qui constituent la meilleure liste de réécriture prioritaire.

Ce qu'il faut retenir