Analyser les logs des crawlers IA sans confondre visite, indexation et citation

Les logs serveur peuvent montrer qu’un agent a demandé une URL, reçu une redirection ou rencontré un blocage. Ils ne révèlent pas si la page a été indexée, utilisée dans une réponse ou citée à un utilisateur. Une bonne analyse commence donc par valider l’identité technique de la requête et limite strictement la conclusion.

Réponse en bref

Pour analyser les crawlers IA, conservez au minimum l’horodatage, l’IP, l’agent déclaré, la méthode, l’URL, le statut, les octets servis et le temps de réponse. Ne faites pas confiance au seul User-Agent : vérifiez l’IP avec la méthode publiée par le fournisseur. Distinguez les agents de recherche, d’entraînement et d’action utilisateur. Regroupez ensuite les erreurs par URL et statut. Un passage vérifié prouve seulement qu’une ressource a été demandée.

Pourquoi le User-Agent ne suffit pas

N’importe quel client HTTP peut déclarer OAI-SearchBot, GPTBot ou PerplexityBot. Une analyse qui compte uniquement la chaîne de caractères mélange agents légitimes, outils de test et imitateurs.

Les fournisseurs publient différentes méthodes de vérification : plages IP, fichiers JSON ou contrôle DNS. Utilisez la procédure actuelle de chaque documentation. Ne créez pas une liste permanente copiée dans le code sans mécanisme de mise à jour.

Pour Googlebot, Google documente une vérification par DNS inversé et direct, ainsi que des listes IP. OpenAI et Perplexity publient des plages pour leurs agents. Chaque mécanisme doit être traité indépendamment.

Distinguer les finalités

Fournisseur	Agent	Finalité documentée	Conclusion d’un passage
OpenAI	OAI-SearchBot	fonctionnalités Search	une URL a été demandée pour cet usage déclaré
OpenAI	GPTBot	amélioration des modèles fondamentaux	une URL a été demandée pour cet usage déclaré
OpenAI	ChatGPT-User	action déclenchée par un utilisateur	un accès ponctuel a eu lieu
Perplexity	PerplexityBot	exploration pour Search	une URL a été demandée par le crawler
Perplexity	Perplexity-User	action liée à une question utilisateur	un accès ponctuel a eu lieu

Ne fusionnez pas ces lignes dans un total « bots IA ». La politique et l’interprétation changent selon l’agent.

Lire les logs en quatre étapes

La méthode suit un ordre simple : vérifier l’identité, observer la réponse, regrouper les événements, puis séparer ce que chaque signal permet réellement de conclure.

1. Vérifier l’identité de la requête

1. lire l’agent déclaré ;
2. vérifier l’IP selon la documentation actuelle ;
3. conserver la version ou la date de la liste utilisée ;
4. marquer la requête comme vérifiée, non vérifiée ou indéterminée ;
5. ne pas ouvrir automatiquement le WAF en cas d’échec de vérification.

Un comportement prudent vaut mieux qu’une règle qui autorise tout un réseau parce qu’un nom apparaît dans l’en-tête.

2. Observer la réponse réelle

Conservez :

Champ	Pourquoi
horodatage avec fuseau	reconstruire la séquence
IP source	vérifier l’identité
méthode HTTP	distinguer GET, HEAD et autres
chemin et paramètres utiles	trouver la ressource demandée
statut	classer succès, redirection, refus ou erreur
octets servis	repérer les réponses vides
temps de réponse	détecter lenteur et timeout
référent si présent	contexte éventuel, sans en dépendre

Minimisez les données personnelles. Les paramètres de requête peuvent contenir des identifiants ou informations sensibles ; nettoyez ou hachez ce qui n’est pas nécessaire.

3. Regrouper les événements

Regroupez par agent vérifié, URL canonique, famille de statuts et période.

Statut	Lecture initiale	Vérification suivante
200	ressource servie	contenu utile et taille attendue
301/308	redirection permanente	destination finale et chaîne
302/307	redirection temporaire	raison et stabilité
403	accès refusé	robots, WAF, règle d’hébergement
404	ressource absente	liens, sitemap, ancienne URL
429	limitation	fréquence, quotas et politique
5xx	erreur serveur	disponibilité et logs applicatifs

Une réponse 200 peut contenir une page d’erreur HTML. Contrôlez le type, la taille et, sur un échantillon, le contenu renvoyé.

4. Séparer les conclusions

Conservez quatre niveaux :

1. requête vérifiée : identité technique raisonnablement confirmée ;
2. ressource servie : statut et contenu attendus ;
3. présence observée : lien ou mention vu dans une réponse datée ;
4. visite humaine : session arrivée sur le site.

Les logs serveur prouvent surtout les deux premiers. Les deux autres demandent un protocole de réponses et un outil de mesure.

Exemple de schéma de journal

observed_at,provider,agent,verified,path,status,bytes,duration_ms,classification
2026-07-13T10:15:00+02:00,openai,OAI-SearchBot,true,/guide/,200,48210,143,served
2026-07-13T10:17:00+02:00,perplexity,PerplexityBot,false,/guide/,403,721,12,unverified_blocked

Cet exemple est fictif. Il montre la structure attendue, pas une observation réelle de ce site.

Requêtes d’analyse utiles

Sur une période stable, calculez :

• nombre de requêtes vérifiées par agent ;
• URL distinctes demandées ;
• taux de statuts 2xx, 3xx, 4xx et 5xx ;
• chemins les plus bloqués ;
• chaînes de redirection fréquentes ;
• pages du sitemap jamais demandées, sans en faire une preuve d’exclusion ;
• évolution avant et après une correction technique.

Ne publiez pas un « crawl budget IA » à partir de ces nombres. Les fournisseurs ne documentent pas nécessairement une relation entre fréquence de passage et probabilité de citation.

Diagnostiquer un 403

Suivez l’ordre :

1. l’agent est-il légitime ?
2. la politique robots autorise-t-elle cet usage ?
3. le WAF bloque-t-il l’IP ou la signature ?
4. une protection anti-bot impose-t-elle JavaScript ou cookie ?
5. le chemin exige-t-il une authentification ?
6. l’exception envisagée ouvre-t-elle plus que nécessaire ?

Une zone privée doit rester protégée même si un utilisateur demande son accès via un assistant. Robots.txt n’est pas une barrière de sécurité.

Avant et après une correction

Conservez deux fenêtres comparables. Modifiez une seule couche lorsque c’est possible : robots, WAF, redirection ou rendu. Vérifiez ensuite :

• disparition du statut d’erreur ;
• absence d’ouverture excessive ;
• contenu complet servi ;
• stabilité sur plusieurs passages ;
• absence de régression pour les utilisateurs.

Ne concluez pas à une amélioration de visibilité tant qu’aucune mesure de présence ou de trafic ne l’indique.

Limites

Les logs disponibles dépendent de l’hébergement, du CDN, du cache et des politiques de conservation. Une requête peut être servie en périphérie sans atteindre le serveur applicatif. Les plages IP et agents peuvent changer. Une absence de logs ne prouve pas une absence de découverte. Cette méthode sert au diagnostic technique, pas à prédire des citations.

Articles liés

• Robots et crawlers IA : décider qui peut explorer quoi
• Apparaître dans ChatGPT : éligibilité, preuves et mesure
• Être référencé sur Perplexity

Prochaine étape

Exportez sept jours de logs, vérifiez les identités avant de compter les agents et classez d’abord les statuts 403, 429 et 5xx. Pour cadrer l’analyse sans partager de données sensibles, décrire l’hébergement et les champs disponibles.