grep -c "GPTBot" access.log : cette simple commande, lancée un lundi matin sur un mois de logs bruts, a renvoyé 340. Trois cent quarante requêtes d’un robot de moteur de réponse génératif sur un seul article de blog technique, en un mois. Dans l’outil d’analyse installé sur le site, le nombre de sessions attribuées à ce même article et provenant d’un moteur de réponse : zéro.
Ce grand écart n’a rien d’anormal une fois qu’on comprend le mécanisme : un moteur de réponse peut explorer une page, en extraire un passage, le citer dans une réponse générée, sans qu’aucun clic ne suive vers le site d’origine. Le trafic référent classique ne capte que la minorité d’utilisateurs qui cliquent sur un lien de citation quand il existe. La majorité des expositions reste invisible tant qu’on ne regarde pas du côté du serveur.
Ce que les outils d’analyse ne peuvent pas voir
Un outil d’analyse embarqué en JavaScript ne se déclenche que lorsqu’un navigateur charge la page et exécute le script de mesure. Un robot de crawl, qu’il appartienne à un moteur de recherche classique ou à un moteur de réponse génératif, télécharge le HTML brut sans exécuter le JavaScript embarqué : il n’existe donc structurellement aucune trace de son passage dans les rapports d’audience. Seul le journal du serveur web enregistre la requête, avec son user-agent, son adresse IP et l’URL exacte demandée.
- Le crawl d’entraînement ou d’indexation d’un moteur de réponse ne déclenche aucun script de mesure côté navigateur.
- Une citation générée à partir du contenu ne redirige pas systématiquement l’utilisateur vers la source.
- Seuls les journaux d’accès bruts du serveur conservent une trace fiable de ces passages.
Construire un tableau de correspondance simple
La méthode la plus fiable ne demande aucun outil tiers : elle s’appuie sur les journaux d’accès déjà produits par le serveur web. L’objectif est de croiser deux colonnes, jour après jour : le nombre de requêtes identifiées comme provenant d’un robot de moteur de réponse, et le nombre de sessions attribuées au même article dans l’outil d’analyse.
awk '{print $1, $4, $7, $12}' access.log \
| grep -E "GPTBot|ClaudeBot|PerplexityBot" \
| grep "/mon-article-technique/" \
| wc -l
Cette ligne isole les requêtes de trois robots connus vers une URL précise, puis en compte le nombre. Répétée chaque semaine, elle constitue un signal de suivi indépendant des outils d’analytics, à condition de conserver un historique suffisant des journaux bruts.
Distinguer crawl d’entraînement et crawl de citation
Tous les robots ne poursuivent pas le même objectif. Certains explorent le contenu pour constituer un jeu de données d’entraînement, d’autres l’explorent à la demande, au moment où un utilisateur pose une question, pour produire une réponse ancrée sur une source récente. La fréquence des passages donne une indication : un pic ponctuel corrélé à une actualité suggère un crawl à la demande, tandis qu’un passage régulier et espacé évoque plutôt un crawl de collecte.
Ce que révèle l’absence totale de corrélation
Sur l’article suivi pendant ce test, aucune session n’a jamais été attribuée à un moteur de réponse dans l’outil d’analyse, alors que les passages de robots se comptaient par dizaines chaque semaine. Deux explications possibles coexistent, et elles ne s’excluent pas : soit l’article est effectivement cité sans lien cliquable dans les réponses générées, soit il est simplement exploré sans jamais être repris dans une réponse visible par un utilisateur.
Un passage de robot n’est pas une preuve de citation ; c’est une preuve d’exploration. La distinction compte pour ne pas surinterpréter un simple pic de logs.
Aller plus loin : recouper avec les journaux d’erreurs
Un signal complémentaire consiste à surveiller les codes de statut renvoyés à ces robots. Un taux élevé de réponses 304 ou 200 sur un contenu stable indique une exploration régulière et sans friction. Un taux anormal de 404 ou 500 signale au contraire que le robot rencontre des URLs cassées ou des erreurs serveur, ce qui limite mécaniquement sa capacité à citer correctement le contenu.
- Isoler les user-agents des principaux robots de moteurs de réponse dans les journaux bruts.
- Compter les passages par article et par semaine.
- Croiser ce comptage avec les sessions attribuées dans l’outil d’analyse.
- Surveiller les codes de statut renvoyés pour détecter les blocages involontaires.
En résumé
Le clic reste un signal utile, mais il ne raconte plus toute l’histoire de l’exposition d’un contenu. Les journaux d’accès bruts, souvent négligés une fois l’outil d’analyse en place, redeviennent une source de vérité pour mesurer un phénomène que le JavaScript embarqué ne peut structurellement pas capter. Mettre en place un comptage régulier, même artisanal, vaut mieux qu’une absence totale de suivi sur ce sujet.
