Logs serveur : suivre les crawlers IA sur ton site

Tout le reste de la mesure en GEO est bruité. Les réponses des modèles varient d’un appel à l’autre, les relevés manuels sont des échantillons, et les outils de suivi interrogent les moteurs selon leurs propres règles d’échantillonnage.

Les logs serveur, eux, enregistrent des faits : telle machine a demandé telle URL à telle heure et a reçu tel code de statut. Pas d’estimation, pas de non-déterminisme, et aucun abonnement à payer. C’est la source de données la plus fiable que tu aies sur ta visibilité dans les IA, et c’est aussi la moins consultée.

Ce que les logs répondent, et que rien d’autre ne répond

Quatre questions, auxquelles aucun relevé de prompts ne peut répondre :

• Est-ce que les robots IA passent sur mon site ? Si la réponse est non, tout travail éditorial est prématuré.
• Passent-ils partout, ou seulement sur la page d’accueil ? Un crawl qui s’arrête à la racine révèle un problème de maillage ou de plan de site.
• Que reçoivent-ils ? Un 200 sur une page vide, un 404, une chaîne de redirections : les logs le disent, un test manuel dans un navigateur ne le dit pas.
• Quelqu’un vient-il de poser une question qui a mené à ma page ? C’est le signal des agents déclenchés par l’utilisateur, et c’est le plus intéressant des quatre.

Où sont tes logs

Ça dépend de ton hébergement, et c’est souvent là que les gens abandonnent.

Serveur Apache ou nginx que tu administres. Dans /var/log/apache2/access.log ou /var/log/nginx/access.log, en général au format « combined » : IP, date, requête, code de statut, taille, référent, user-agent. C’est le cas le plus simple.

Hébergement mutualisé. Les logs sont accessibles depuis l’espace d’administration, ou en SSH dans un dossier logs de ton compte. La rétention est souvent courte — vérifie-la avant de compter dessus.

Derrière un CDN. C’est le piège. Si Cloudflare, Fastly ou l’équivalent servent tes pages depuis leur cache, une partie des visites de robots n’atteint jamais ton serveur d’origine, et tes logs d’origine sous-estiment le crawl. Il faut alors consulter le journal du CDN. Cloudflare expose d’ailleurs ses propres statistiques sur le trafic des robots IA dans son interface, ce qui évite l’analyse manuelle quand on n’a besoin que des volumes.

Hébergement de type plateforme — Vercel, Netlify et similaires. Les journaux existent mais la rétention dépend du plan, et elle est généralement courte sur les offres d’entrée.

Les user-agents à filtrer

Voici ceux qui comptent aujourd’hui. Le rôle importe autant que le nom : bloquer celui d’entraînement en croyant se retirer de la recherche est l’erreur la plus répandue du domaine.

Deux noms que tu ne verras jamais dans tes logs : Google-Extended et Applebot-Extended. Ce sont des jetons de contrôle que l’on déclare dans robots.txt pour refuser l’usage du contenu à des fins d’entraînement — pas des robots. Ils ne font aucune requête. Si tu les cherches dans tes logs, tu trouveras zéro, et ce zéro ne signifie rien.

Les commandes qui répondent aux quatre questions

Sur un fichier au format combined. Adapte le chemin.

Qui est passé, et combien de fois :

grep -oiE 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|Perplexity-User|Googlebot' access.log | sort | uniq -c | sort -rn

Tu obtiens le classement des robots par volume. Lis-le en deux temps : la présence d’abord, les proportions ensuite. Un robot absent est un problème ; un robot deux fois moins fréquent qu’un autre ne l’est pas forcément.

Quelles pages sont crawlées par un robot donné :

grep -i 'OAI-SearchBot' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

Si cette liste ne contient que la racine, ton maillage interne ou ton plan de site ne guide pas le robot plus loin.

Quels codes de statut reçoivent les robots IA :

grep -iE 'GPTBot|OAI-SearchBot|PerplexityBot|ClaudeBot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn

C’est la commande la plus rentable des quatre. Tout ce qui n’est pas 200 ou 304 mérite un coup d’œil : les 404 révèlent des liens morts que les robots suivent encore, les 301 et 302 en masse révèlent des chaînes de redirection qui gaspillent le budget de crawl, les 403 et 429 révèlent qu’un pare-feu ou une limitation de débit bloque des robots que tu voulais laisser passer.

Les visites déclenchées par des utilisateurs, jour par jour :

grep -iE 'ChatGPT-User|Perplexity-User|Claude-User' access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

Le signal que je regarde en premier

Parmi tous ces chiffres, un seul m’intéresse vraiment au quotidien : les visites des agents déclenchés par l’utilisateur — ChatGPT-User, Perplexity-User, Claude-User.

La différence avec un crawler d’indexation est de nature. Un crawler passe selon son propre calendrier, qu’on te lise ou non. Ces agents-là ne se déclenchent que parce que quelqu’un a posé une question et que le moteur a décidé d’aller chercher ta page pour y répondre.

Autrement dit : une visite de ChatGPT-User sur une URL, c’est une conversation réelle où ta page a été retenue. Ce n’est pas une preuve qu’elle a été citée dans la réponse finale — le modèle peut récupérer une page et ne pas s’en servir. Mais c’est le signal le plus proche d’une citation que tu puisses obtenir sans interroger les moteurs un par un.

En pratique : je note quelles URL reçoivent ces visites, et leur évolution. Une page qui commence à en recevoir après une réécriture, c’est un retour bien plus rapide que le relevé mensuel de prompts.

Les quatre limites, à connaître avant de conclure

Un user-agent se falsifie. C’est une simple chaîne de caractères dans un en-tête HTTP, n’importe qui peut écrire GPTBot. Pour les décisions qui comptent — facturation, blocage, étude publiée —, il faut vérifier l’origine réelle : les éditeurs publient des plages d’IP pour leurs robots, ou permettent la vérification par DNS inverse. Pour du simple suivi de tendance, le user-agent brut suffit.

Le cache du CDN masque une partie du trafic, comme vu plus haut.

Il n’y a pas de référent. Un robot n’indique pas quelle requête d’utilisateur a déclenché sa visite. Tu sais qu’une page a été récupérée, jamais pour répondre à quoi.

La rétention est souvent trop courte. Un mois de logs ne permet aucune comparaison utile. Si ton hébergement efface vite, mets en place un export, même rudimentaire.

Par où commencer

Si tu n’as jamais ouvert tes logs, le minimum utile prend une demi-heure :

1. Localise le fichier et vérifie combien de jours il couvre.
2. Lance la commande « qui est passé » et note les absences. Si OAI-SearchBot ou PerplexityBot sont à zéro sur plusieurs semaines, vérifie ton robots.txt et ton rendu avant toute autre chose — le sujet est traité dans rendre un site récupérable par les IA.
3. Lance la commande des codes de statut et corrige ce qui n’est pas 200 ou 304.
4. Mets en place un relevé mensuel de ces trois chiffres, à côté de ton relevé de citations.

Les logs répondent à « est-ce que la machine me voit ». Ils ne répondent pas à « est-ce que je suis cité » : pour ça, il faut interroger les moteurs, et la méthode est dans mesurer sa visibilité dans les IA. Les deux mesures sont complémentaires, et les faire dans cet ordre évite de travailler l’éditorial sur un site que les robots n’atteignent pas.