Langues

Analyse des fichiers journaux

Comment lire les journaux d’accès bruts du serveur pour vérifier les requêtes réelles de Googlebot, Bingbot et des robots d’IA, puis repérer le gaspillage d’exploration et les pages orphelines.

Première publication : 22 juin 2026 · Dernière mise à jour : 21 août 2026 · Advanced
Langues
AIRédigé parAI v2
1 indice probant sur cette page

L’analyse des fichiers journaux consiste à lire les journaux d’accès bruts du serveur, qui recensent chaque requête sans échantillonnage. Elle montre quelles URL Googlebot, Bingbot et les robots d’IA ont réellement récupérées, à quelle fréquence et avec quel code d’état. Il faut d’abord vérifier l’identité des robots par DNS inverse et direct ou avec les plages IP publiées par Google. On analyse ensuite le gaspillage d’exploration, les URL les plus et les moins visitées, les codes d’état, les pages orphelines et la répartition mobile-ordinateur. Ces journaux complètent les statistiques d’exploration de GSC sans les remplacer. Ils sont surtout utiles aux grands sites, aux boutiques et lors des migrations.

En bref — Les logs constituent la vérité terrain non échantillonnée du crawl : chaque requête, chaque robot et chaque code d’état. La première étape, non négociable, consiste à vérifier Googlebot et Bingbot par DNS inversé puis direct (ou avec le fichier JSON des plages IP publié par Google). Les user-agents sont constamment usurpés : tous les calculs de crawl doivent porter uniquement sur l’ensemble vérifié. Analysez ensuite les URL et sections les plus et les moins explorées, l’évolution de la fréquence de crawl, les codes d’état classés par fréquence, le gaspillage de crawl (paramètres, facettes, recherche interne, pagination infinie), les pages orphelines ou jamais explorées (par rapprochement avec un crawl), ainsi que la répartition entre Googlebot mobile et ordinateur. Bing ne publie pas officiellement ses plages IP : la méthode consiste donc à vérifier le DNS vers *.search.msn.com. Les logs complètent les statistiques d’exploration de GSC ; ils ne les remplacent pas. Et en 2026, les robots d’IA occupent désormais une part considérable des requêtes observées.

Evidence for this claim Web-server access logs record HTTP requests and commonly include request, response-status, user-agent, and timing fields depending on configuration. Scope: Apache HTTP Server access-log behavior; other servers vary by configuration. Confidence: high · Verified: Apache HTTP Server: Log Files Evidence for this claim User-agent text alone does not authenticate Googlebot; Google recommends DNS verification or matching published IP ranges. Scope: Google crawler verification, applicable when classifying log traffic. Confidence: high · Verified: Google Search Central: Verify Googlebot

Pourquoi les logs sont la vérité terrain

Il existe trois manières de « voir » comment les moteurs de recherche explorent votre site, et elles ne se valent pas :

  • Un outil de crawl (Screaming Frog SEO Spider, Ahrefs Site Audit) simule une exploration. Il indique ce qu’un robot pourrait trouver, pas ce que Google a réellement récupéré.
  • Les statistiques sur l’exploration de GSC résument l’activité réelle, mais les données sont échantillonnées, agrégées et plafonnées (environ 1 000 lignes, près de 90 jours, sans export par URL).
  • Les logs serveur enregistrent l’activité réelle : chaque requête de chaque robot, avec l’URL exacte, l’horodatage et le code d’état.

Le guide d’Ahrefs sur les logs que j’ai relu le dit clairement : les logs serveur sont “the most trustworthy source of information to understand the URLs that search engines have crawled.” (traduction) : « la source d’information la plus fiable pour comprendre les URL que les moteurs de recherche ont explorées ». C’est précisément la raison d’être de cette technique. Pour savoir ce que Googlebot a vraiment fait — et non ce qu’il aurait pu faire ou ce qu’un résumé arrondi rapporte — je consulte les logs.

Une ligne de log classique contient l’adresse IP, le user-agent, le chemin de l’URL, l’horodatage, la méthode de requête (GET/POST) et le code d’état HTTP. Toute l’analyse qui suit consiste à segmenter intelligemment ces champs.

Quand cette analyse est vraiment utile — et quand elle ne l’est pas

Soyez lucide : l’analyse de logs est surtout destinée aux grands sites. Elle devient rentable pour les sites comptant des dizaines de milliers d’URL, les sites e-commerce à navigation à facettes, les migrations en cours et les sites bloqués dans l’état Discovered – currently not indexed. Comme je l’ai écrit dans mon guide du budget de crawl, “Most sites don’t need to worry about crawl budget, but there are few cases where you may want to take a look.” (traduction) : « La plupart des sites n’ont pas à se soucier du budget de crawl, mais quelques situations méritent qu’on s’y intéresse ». Daniel Waisberg, de Google, a formulé une idée similaire à propos des statistiques sur l’exploration : d’après Search Engine Journal, ce rapport préoccupe peu les sites de moins d’environ 1 000 pages.

Si votre site de quelques centaines de pages est correctement exploré, passez votre chemin et consacrez-vous à un problème offrant davantage d’impact.

Comment obtenir vos logs — l’accès est souvent le plus difficile

Les logs se trouvent là où la requête a réellement abouti :

  • Apache et Nginx → format de log Apache « combined » (le plus courant).
  • Microsoft IIS → format W3C.
  • AWS ELB/ALB → format ELB.
  • CDN (Cloudflare, Fastly, Akamai) → leurs propres exports. Ce point est important : sur un site protégé par un CDN, un log limité au serveur d’origine ignore les réponses servies depuis le cache périphérique. Récupérez donc les logs à la couche réellement atteinte par le robot.

Visez 30 jours au minimum, idéalement 90, afin de saisir les variations de fréquence de crawl. Prévoyez aussi des difficultés : obtenir l’accès aux logs serveur est souvent la partie la plus compliquée, notamment en raison des contrôles de l’équipe DevOps. Même des employés de Google ont souligné, dans un épisode de Search Off the Record consacré aux migrations, combien ces fichiers peuvent être difficiles à obtenir. Réservez du temps à cette demande.

Les logs ne contiennent pas uniquement le trafic des robots : ils enregistrent chaque requête, y compris celles des visiteurs réels, et peuvent associer au chemin de l’URL des paramètres de requête, des identifiants de session ou d’autres données sensibles. Les recommandations d’OWASP sont sans ambiguïté : identifiants d’authentification, jetons d’accès et données personnelles ne devraient généralement pas être consignés tels quels ; il faut d’abord les supprimer, les masquer ou les hacher. Intégrez cette protection aux contrôles d’accès et au processus d’export avant de transmettre un fichier de logs pour analyse, pas après.

Étape 1 — Vérifier que les robots sont authentiques, avant toute autre chose

La plupart des guides expédient cette étape en une ligne. Ne faites pas de même. De nombreux robots se font passer pour Googlebot afin de contourner les pare-feu (Ahrefs). Le user-agent n’est qu’un texte non authentifié : considérez chaque ligne « Googlebot » comme une affirmation qui reste à prouver.

Googlebot — deux méthodes valables :

  1. DNS inversé puis direct — le contrôle bidirectionnel. Voici les étapes indiquées par Google : effectuez une recherche DNS inversée sur l’IP trouvée dans vos logs avec la commande host ; vérifiez que le domaine est googlebot.com, google.com ou googleusercontent.com ; puis lancez une recherche DNS directe sur ce nom d’hôte et assurez-vous qu’elle renvoie l’adresse IP d’origine. C’est cette dernière étape qui rend le contrôle fiable : un usurpateur peut faire pointer un DNS inversé vers un nom *.googlebot.com, mais seul le retour à la même IP ferme la boucle. Les commandes macOS/Linux et Windows figurent dans l’onglet Scripts.
  2. Comparer l’IP aux plages publiées par Google. Google fournit des fichiers JSON contenant les IP de ses robots au format CIDR : common-crawlers.json pour Googlebot et les robots courants, ainsi que special-crawlers.json, les fichiers des récupérateurs déclenchés par l’utilisateur et le fichier global goog.json. Comme je l’ai noté dans mon guide de Googlebot, Google “provided a list of public IPs you can use to verify the requests are from Google… You can compare this to the data in your server logs.” (traduction) : « Google a fourni une liste d’IP publiques permettant de vérifier que les requêtes proviennent bien de Google… Vous pouvez la comparer aux données de vos logs serveur ».

Bingbot — DNS uniquement. La différence essentielle est la suivante : Bing ne publie pas officiellement ses plages IP. Selon Bing, “…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet,” (traduction) : « comme d’autres moteurs de recherche, Bing ne publie pas la liste des adresses ou plages IP depuis lesquelles nous explorons Internet », car “the IP addresses or ranges we use can change any time.” (traduction) : « les adresses ou plages IP que nous utilisons peuvent changer à tout moment ». Pour Bingbot, effectuez donc une recherche DNS inversée puis directe vers un nom d’hôte se terminant par *.search.msn.com — par exemple msnbot-157-55-33-18.search.msn.com — ou utilisez l’outil de vérification de Bingbot. Microsoft a depuis publié un fichier JSON d’IP Bingbot, mais ses consignes officielles restent centrées sur le DNS, précisément parce que les IP changent.

Écartez ensuite les imposteurs. Effectuez tous vos calculs sur le seul ensemble vérifié. Un « Googlebot » non vérifié est presque toujours un scraper ou un robot usurpateur : il relève d’une analyse de sécurité, pas de votre étude du gaspillage de crawl.

Étape 2 — Les éléments à rechercher

Une fois les requêtes vérifiées, voici comment les lire :

  • URL et sections les plus et les moins explorées. Classez les requêtes par URL et par répertoire. Vous découvrirez où part réellement le budget de crawl — avec souvent des surprises.
  • Évolution de la fréquence de crawl. Suivez-la par URL et par section pour repérer les baisses — une migration a cassé quelque chose — ou les pics — nouvelle section ou piège à robots créant une infinité d’URL.
  • Codes d’état rencontrés, classés par fréquence. Quantifiez les 200, les 301/302 et leurs chaînes, les 404 et les 5xx. Une 404 appelée 5 000 fois par semaine n’a rien à voir avec une 404 appelée une seule fois : corrigez selon la fréquence de crawl, pas la simple existence.
  • Gaspillage de crawl. Navigation à facettes, paramètres d’URL, résultats de recherche interne, calendriers et paginations infinis peuvent engloutir une grande partie du budget de crawl. Les logs révèlent précisément les motifs inutiles auxquels les robots consacrent leur temps.
  • Pages orphelines et jamais explorées. Il faut les deux jeux de données. Croisez les logs avec un crawl du site : une URL présente dans les logs mais absente du crawl peut être orpheline, une ancienne redirection ou une page liée depuis l’extérieur ; une URL du crawl absente des logs n’a jamais été récupérée par Google.
  • Googlebot mobile ou ordinateur. Segmentez par user-agent. Depuis le passage au mobile-first, Googlebot Smartphone devrait être majoritaire ; une forte part ordinateur mérite examen.
  • Temps de réponse et santé du crawl. Une hausse du temps de réponse moyen est corrélée à une baisse du crawl. Search Engine Journal résume ainsi les conseils de Waisberg : “Watch out for a consistent increase in average response time. Google says it might not affect crawl rate immediately, but it’s a good indicator that your servers might not be handling all the load.” (traduction) : « Surveillez toute augmentation durable du temps de réponse moyen. Google indique qu’elle n’affectera peut-être pas immédiatement le rythme de crawl, mais qu’elle signale que vos serveurs pourraient ne pas absorber toute la charge ».

Ce que les logs ne vous disent PAS

Gardez ces distinctions à l’esprit pour ne pas surinterpréter les données :

  • Crawl ≠ indexation. Une URL récupérée chaque jour par Googlebot peut rester indéfiniment hors de l’index. Les logs prouvent une récupération, pas un état d’indexation : associez-les aux rapports Indexation des pages et Inspection de l’URL de GSC.
  • Crawl ≠ classement, et davantage de crawl n’améliore rien. Comme je l’ai souvent répété, “The rate of crawling isn’t going to impact your rankings.” (traduction) : « Le rythme de crawl n’aura aucune incidence sur vos classements ». Ne poursuivez pas le volume de crawl comme s’il s’agissait d’un levier de classement.
  • noindex ne réduit pas le crawl. noindex contrôle l’indexation, pas l’exploration. Pour vraiment empêcher le crawl, utilisez robots.txt ou un code d’état.
  • Crawl ≠ entraînement d’un modèle ou citation. Une requête vérifiée de GPTBot, ClaudeBot ou PerplexityBot prouve seulement qu’une récupération a eu lieu à cette couche. Elle ne prouve ni que la page a servi à entraîner un modèle, ni qu’elle a été conservée en aval, ni qu’elle a été citée dans une réponse conversationnelle. Ces résultats distincts ne sont pas observables : n’accordez pas à une ligne de log une portée qu’elle n’a pas.

La nouveauté de 2026 : les robots d’IA sont partout dans les logs

Les acteurs présents dans un fichier de logs moderne ont changé. Dans mon analyse des données de Cloudflare Radar (À la rencontre des nouveaux robots du Web), les robots des moteurs de recherche restent les plus actifs, mais les robots d’IA occupent solidement la deuxième place et pourraient les dépasser d’ici quelques années. GPTBot, ClaudeBot, PerplexityBot et leurs homologues apparaissent désormais en masse. En segmentant les requêtes vérifiées par user-agent, ne vous étonnez pas de voir les robots d’IA rivaliser avec les moteurs en part de requêtes. Screaming Frog a d’ailleurs ajouté à son Log File Analyser un tutoriel consacré à leur suivi.

Comment cette analyse s’intègre au reste du crawl

Les logs forment la couche de diagnostic de tout le domaine du crawl. Ils permettent de mesurer la consommation du budget de crawl que les moteurs décrivent abstraitement — Gary Illyes le définit comme “the number of URLs Googlebot can and is willing or is instructed to crawl.” (traduction) : « le nombre d’URL que Googlebot peut explorer et qu’il souhaite ou reçoit l’instruction d’explorer ». Ils prennent aussi les pièges à robots sur le fait : un espace d’URL infini produit par un calendrier ou une facette apparaît sous forme d’un flot de requêtes presque identiques. Enfin, ils permettent de vérifier si vos efforts sur la fréquence de crawl — lastmod exact, liens internes vers les pages importantes — ont vraiment modifié le comportement des robots. N’oubliez pas : ils complètent les statistiques sur l’exploration de GSC, sans les remplacer. GSC fournit une première vue échantillonnée ; les logs offrent le détail non échantillonné, par URL et pour plusieurs robots.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.