Il arrive un moment, dans tout chantier de visibilité générative, où quelqu'un pose la question qui compte : est-ce que ça marche ? Et où personne ne peut répondre. Le robots.txt a été corrigé, les blocs critiques remontés dans le HTML, les pages restructurées. Ensuite, plus rien. On attend, on interroge ChatGPT à la main de temps en temps, on regarde si une citation apparaît.

Réponse courte : le seul endroit où la visite d'un robot d'IA est enregistrée de façon fiable, c'est votre fichier de logs serveur. Pas la Search Console, qui ne rapporte que Google. Pas votre outil d'analytics, qui ne voit par construction aucun de ces robots. Les logs, et rien d'autre.

C'est aussi la mesure la moins spectaculaire du Generative Engine Optimization, et de loin la plus honnête : elle vous dit non pas ce que vous espérez, mais ce qui a réellement été téléchargé, quand, avec quel code de réponse et combien d'octets.

Pourquoi vos deux outils habituels ne peuvent pas répondre

Ce n'est pas une question de configuration. Les deux sources sur lesquelles vous vous appuyez d'ordinaire sont structurellement aveugles à ce trafic.

La Search Console ne parle que de Google. C'est une évidence qu'il faut pourtant énoncer, parce que le rapport « Statistiques d'exploration » entretient l'illusion d'un tableau de bord de crawl généraliste. Il ne couvre que les robots de Google, agrégés par type. Aucune ligne pour GPTBot, aucune pour ClaudeBot, aucune pour PerplexityBot. Et côté Google même, la granularité manque : Google-Extended, par exemple, n'est pas un robot mais un jeton de contrôle. Il ne produit donc aucune télémétrie propre, comme nous l'expliquions dans notre guide des user-agents IA.

Votre analytics ne voit aucun crawler. Google Analytics, Matomo, Plausible et les autres reposent sur un script exécuté par le navigateur. Or les crawlers des moteurs génératifs n'exécutent pas JavaScript, ce qui est précisément le problème de rendu que nous décrivions récemment. Le robot passe, télécharge, repart, et votre balise ne se déclenche jamais. Un site peut recevoir cinquante mille récupérations d'OAI-SearchBot par mois sans qu'une seule ligne apparaisse dans son analytics.

Ce que votre analytics voit, en revanche, ce sont les visites référentes : un humain qui clique sur un lien depuis chatgpt.com, perplexity.ai ou gemini.google.com. C'est utile, et c'est même le seul indicateur de valeur commerciale directe. Mais c'est l'autre bout de la chaîne. Le référent arrive après la citation, qui arrive après l'indexation, qui arrive après le crawl. Quand rien n'apparaît en référent, vous ne savez pas lequel des trois maillons a cassé.

Les logs, eux, enregistrent chaque requête HTTP au niveau du serveur, quel que soit le client, script ou pas. C'est le seul endroit du dispositif où le crawl et la visite référente coexistent.

Où trouver vos logs, et le piège du CDN

Sur un serveur classique, les journaux d'accès vivent en général dans /var/log/nginx/access.log ou /var/log/apache2/access.log. Sur un hébergement mutualisé, un onglet du panneau d'administration les expose, souvent avec une rétention courte.

Le vrai piège est ailleurs. Si vous servez votre site derrière un CDN, ce réseau de serveurs intermédiaires qui distribue vos pages depuis des points de présence répartis dans le monde, vos logs d'origine sont incomplets, et parfois presque vides. Une réponse servie depuis le cache de bordure n'atteint jamais votre serveur applicatif. Sur un site de contenu bien caché, la majorité des récupérations de robots peuvent ainsi n'apparaître nulle part côté origine. Vous concluez que les robots ne passent pas, alors qu'ils passent beaucoup.

La règle est simple : mesurez au point le plus haut de la chaîne. Si vous êtes sur Cloudflare, Fastly, Akamai ou une plateforme d'hébergement moderne, ce sont leurs journaux qu'il faut exploiter, pas ceux de la machine derrière.

Une mention particulière pour Cloudflare, très répandu chez nos clients : les journaux bruts en flux continu sont réservés aux offres hautes, mais l'outil AI Crawl Control, sorti en disponibilité générale en août 2025 après un an sous le nom d'AI Audit, est accessible sur tous les plans et affiche directement les requêtes des robots d'IA par service. Sur le plan gratuit, l'historique se limite à vingt-quatre heures, ce qui suffit pour un diagnostic ponctuel mais pas pour un suivi. Notez le point au passage : cette limite de rétention est la contrainte pratique numéro un de toute cette méthode. Un log qui tourne tous les deux jours ne permet aucune analyse de tendance. Archivez avant d'analyser.

La clé de lecture : trois familles, trois questions différentes

Une fois le fichier ouvert, la tentation est de compter les visites de robots et d'en faire un chiffre unique. C'est la mauvaise lecture, et elle produit des rapports flatteurs qui ne veulent rien dire.

Les robots d'IA se répartissent en trois familles aux rôles distincts, et chacune répond à une question différente.

Les robots d'entraînement (GPTBot, ClaudeBot, Google-Extended côté directive) collectent du texte pour les futures versions des modèles. Leurs passages ne vous apprennent rien sur votre visibilité actuelle. Un pic de GPTBot est un fait de bande passante, pas un succès marketing. C'est pourtant la famille la plus visible dans les logs : Cloudflare a mesuré, sur juillet et début août 2025, que l'entraînement représentait près de 80 % du crawl total des robots d'IA. Autrement dit, la ligne la plus grosse de votre rapport est celle qui compte le moins.

Les robots de recherche (OAI-SearchBot, Claude-SearchBot, PerplexityBot) alimentent l'index dans lequel le moteur puise pour répondre. Eux répondent à la question « puis-je être cité, et sur quelle version de ma page ». C'est la ligne à surveiller après une refonte, une republication ou une correction de rendu : tant qu'OAI-SearchBot n'est pas repassé sur l'URL modifiée, ChatGPT raisonne sur votre ancien contenu.

Les robots déclenchés par l'utilisateur (ChatGPT-User, Claude-User, Perplexity-User) vont chercher une page précise parce qu'une personne, dans sa conversation, a posé une question qui la concerne. C'est le signal le plus riche du fichier, et le plus sous-exploité. Chaque ligne correspond à une intention réelle, horodatée, sur une URL identifiée. Pas un volume de recherche estimé : une demande. Quand nous voyons ChatGPT-User revenir régulièrement sur une page de tarifs, nous savons que le sujet est vivant dans les conversations, indépendamment de tout classement.

Un rapport de logs utile sépare donc ces trois familles avant de compter quoi que ce soit. Le total agrégé est un chiffre de vanité.

Vérifier que le robot est bien celui qu'il prétend

Le champ user-agent est une simple chaîne de caractères envoyée par le client. N'importe qui peut se déclarer GPTBot en une ligne de code. Une partie non négligeable de ce que vous verrez dans vos logs sous un nom de robot d'IA sont des scrapeurs qui empruntent l'étiquette.

Les principaux éditeurs publient pour cette raison leurs plages d'adresses IP dans des fichiers JSON tenus à jour :

# OpenAI, un fichier par robot
https://openai.com/gptbot.json
https://openai.com/searchbot.json
https://openai.com/chatgpt-user.json

# Anthropic, un fichier unique couvrant ses trois robots
https://claude.com/crawling/bots.json

# Google, pour comparaison
https://developers.google.com/search/apis/ipranges/googlebot.json

Perplexity documente également ses plages sur son site développeurs. La vérification tient en deux conditions cumulatives : le user-agent correspond, et l'adresse source appartient à la plage publiée. Ce qui passe la première et rate la seconde peut être bloqué sans le moindre risque pour votre visibilité réelle. Pour Googlebot, la méthode canonique reste la résolution DNS inverse puis directe.

Une nuance à connaître avant de bâtir un tableau de bord dessus : ces fichiers n'ont pas tous la même finesse. OpenAI publie un fichier par robot, ce qui permet de distinguer une récupération d'entraînement d'une récupération de recherche à l'adresse près. Anthropic publie un fichier unique, sans séparation par agent : il vous confirme que la requête vient bien d'Anthropic, pas lequel de ses trois robots l'a émise. Pour cette distinction, vous restez dépendant du user-agent déclaré.

L'épisode d'août 2025 a montré que la question n'est pas théorique. Cloudflare a accusé Perplexity d'utiliser des robots non déclarés se présentant comme un Chrome ordinaire pour atteindre des contenus qui bloquaient ses agents officiels, et l'a retiré de son programme de robots vérifiés. Perplexity a contesté cette lecture. Sans trancher le litige, retenez l'enseignement opérationnel : une part du trafic automatisé qui vous concerne ne s'annonce pas, et l'absence d'un nom de robot dans vos logs ne prouve pas l'absence de ce robot.

Les cinq mesures qui valent le détour

Une fois le fichier filtré et les identités vérifiées, cinq indicateurs suffisent à couvrir l'essentiel.

La couverture. Combien de vos URL stratégiques ont été récupérées par un robot de recherche sur la période, et lesquelles ne l'ont jamais été. C'est le contrôle le plus rentable : il révèle presque toujours des pages importantes que rien n'atteint.

Les codes de statut. Une page qui répond 404 ou 500 à un robot ne sera pas citée, et le taux d'erreur est bien plus élevé qu'on ne l'imagine côté IA. L'étude Vercel et Merj de décembre 2024 mesurait 34,82 % de récupérations aboutissant sur des 404 pour ChatGPT, contre 8,22 % pour Googlebot. Vos logs vous diront si vous êtes dans cette moyenne.

Le poids des réponses. Le nombre d'octets renvoyés est le contrôle de rendu le plus rapide qui soit. Une page longue qui renvoie systématiquement quelques kilo-octets à OAI-SearchBot est une coquille vide, quoi qu'affiche votre navigateur.

La fraîcheur. Le délai depuis le dernier passage d'un robot de recherche sur chaque URL importante. C'est ce délai, et non la date de votre publication, qui détermine à partir de quand une correction peut produire un effet.

La demande. Le volume et la répartition des visites déclenchées par l'utilisateur, page par page. C'est la carte de ce qui intéresse réellement vos interlocuteurs dans les conversations.

Les commandes pour commencer

Rien d'exotique n'est nécessaire pour un premier diagnostic. Sur un log au format combiné standard, ces quatre commandes donnent déjà une image exploitable.

# 1. Qui passe, et combien de fois, par famille de robot
grep -Eio "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot|Perplexity-User|Google-Extended|Googlebot" access.log \
  | sort | uniq -c | sort -rn

# 2. Quelles pages le robot de recherche de ChatGPT a-t-il réellement lues
grep "OAI-SearchBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

# 3. Quels codes de statut leur renvoyez-vous
grep "OAI-SearchBot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

# 4. Combien d'octets par page, pour repérer les coquilles vides
grep "OAI-SearchBot" access.log | awk '{print $10, $7}' | sort -n | head -20

La lecture est directe. Une première commande dominée par GPTBot avec un OAI-SearchBot proche de zéro signifie que vous nourrissez l'entraînement sans être indexé pour les réponses. Une deuxième commande où vos pages de service n'apparaissent pas vous dit qu'elles ne sont pas dans l'index. Une troisième commande chargée en 404 pointe une migration mal redirigée. Une quatrième commande où les tailles plafonnent à quelques milliers d'octets confirme un problème de rendu avant même d'ouvrir le code.

Remplacez access.log par le nom de votre fichier, et gardez à l'esprit que la position des champs varie selon le format configuré : vérifiez sur une ligne au hasard que $7 est bien l'URL et $9 le code de statut.

Ce que ces chiffres ne diront pas

Trois angles morts méritent d'être posés d'emblée, parce qu'ils évitent des conclusions fausses.

Un crawl n'est pas une citation. Le rapport entre les deux est déconcertant. Sur les données Cloudflare de juillet et début août 2025, il fallait environ 887 pages explorées par GPTBot pour une visite référée par OpenAI, environ 118 pour Perplexity, et de l'ordre de 50 000 pour le robot d'Anthropic, dont le rôle était alors essentiellement l'entraînement. Ces ordres de grandeur donnent la bonne échelle mentale : un volume de crawl élevé est une condition d'entrée, jamais une performance en soi.

L'absence de crawl récent ne prouve pas l'absence de citation. Un moteur peut répondre à partir de son index, sans repasser sur votre page. Les logs mesurent l'alimentation du système, pas sa sortie. Pour la sortie, il faut interroger les moteurs eux-mêmes de façon systématique, ce qui est un autre exercice.

Le cache et l'échantillonnage faussent les totaux. Nous l'avons dit pour le CDN, cela vaut aussi pour tout dispositif de journalisation échantillonné. Traitez ces chiffres comme des tendances relatives, pas comme une comptabilité.

Questions fréquentes

À quelle fréquence faut-il analyser ses logs ? Une fois par mois suffit en régime de croisière. Une analyse avant et une deux à quatre semaines après chaque changement structurel : refonte, migration, correction de rendu, modification du robots.txt.

Faut-il un outil payant ? Non pour commencer. Les commandes ci-dessus couvrent le diagnostic initial. Un outil d'analyse de logs devient pertinent au-delà de quelques centaines de milliers de lignes par jour, ou quand le suivi doit être partagé et historisé.

Mon hébergeur ne me donne pas accès aux logs, que faire ? Passez par le niveau CDN si vous en avez un, et vérifiez si votre plateforme expose un rapport de robots. À défaut, un contrôle par curl en imitant le user-agent d'un crawler vous dira ce que le robot recevrait, à défaut de vous dire s'il est venu.

Que faire d'un GPTBot qui consomme énormément de bande passante ? C'est une décision de politique de contenu, pas de visibilité. Le limiter ou le bloquer ne coûte aucune citation, à condition de laisser passer OAI-SearchBot. La distinction est détaillée dans notre guide des user-agents.

Les logs remplacent-ils un suivi de citations ? Non, ils le complètent. Les logs mesurent l'entrée du système, le suivi de citations mesure la sortie. Un écart persistant entre un crawl abondant et des citations absentes est un problème de contenu ou d'autorité, pas de technique.

Il y a quelque chose d'un peu ingrat dans cette méthode. Elle ne produit ni graphique flatteur ni score sur cent, et elle demande d'ouvrir un fichier que la plupart des équipes n'ont jamais consulté. Mais c'est la seule qui distingue « les moteurs ne me citent pas » de « les moteurs ne m'ont jamais lu », et ces deux diagnostics n'appellent pas du tout le même travail.

C'est pour cette raison que nous ouvrons chaque audit GEO par un extrait de logs sur trente jours. Avant de discuter contenu, autorité ou structure, il faut savoir si la matière est seulement arrivée jusqu'au moteur.