Fichiers logs SEO : comprendre le vrai crawl de Googlebot

Les fichiers logs sont la source la plus directe pour comprendre le comportement réel de Googlebot sur un site. Google l’explique désormais sans ambiguïté : la meilleure source pour analyser ce que Google explore est le journal d’accès brut du site, car il contient une entrée pour chaque URL demandée, par des navigateurs comme par des robots. Google rappelle aussi que les ressources nécessaires au rendu, comme le JavaScript, le CSS ou certains médias, consomment elles aussi du budget de crawl sur l’hôte qui les sert. Autrement dit, les logs ne servent pas seulement à savoir si des pages HTML sont visitées ; ils permettent de voir la réalité complète du crawl, y compris les ressources techniques invisibles dans beaucoup d’outils SEO. ([developers.google.com](https://developers.google.com/search/blog/2024/12/crawling-december-resources?hl=en))

Pour un SEO technique, l’intérêt des logs est simple : ils montrent ce que le serveur a réellement reçu, et non ce qu’un crawler tiers suppose, ni ce qu’un rapport agrégé résume. C’est la meilleure façon de répondre à des questions très concrètes : Googlebot passe-t-il trop souvent sur des pages sans valeur SEO ? Ignore-t-il des sections importantes ? Revient-il après un correctif ? Le site renvoie-t-il des erreurs serveur qui ralentissent l’exploration ? Les réponses sont dans les requêtes, les horodatages, les statuts HTTP et les segments d’URL. ([support.google.com](https://support.google.com/webmasters/answer/9679690?hl=en))

Ce guide se concentre sur l’essentiel : quelles données extraire, quels segments comparer, quels indicateurs suivre et comment interpréter les résultats sans se perdre dans l’outillage.

Pourquoi les logs sont différents de la Search Console

La Search Console reste utile, notamment avec le rapport Crawl Stats, qui donne l’historique de l’exploration Google, le nombre de requêtes, le moment des passages, les réponses du serveur et d’éventuels problèmes de disponibilité. Le rapport permet aussi de ventiler les données par type de réponse, type de fichier, finalité du crawl et type de Googlebot, avec des exemples d’URL pour chaque groupe. C’est une excellente vue d’ensemble. ([support.google.com](https://support.google.com/webmasters/answer/9679690?hl=en))

Mais les logs vont plus loin sur trois points. D’abord, ils sont bruts : chaque ligne correspond à une requête réellement servie. Ensuite, ils permettent vos propres segmentations, adaptées à l’architecture du site : répertoires, templates, paramètres, pages SEO stratégiques, facettes, APIs, images, fichiers de rendu. Enfin, ils permettent de suivre une chronologie fine, par heure ou par minute, utile pour relier un incident serveur, une mise en production ou un changement de maillage à l’évolution du crawl. La Search Console est donc un bon tableau de bord ; les logs sont le niveau preuve.

Première règle : vérifier que c’est bien Googlebot

Un des pièges classiques de l’analyse de logs consiste à filtrer seulement sur le user-agent. Google prévient explicitement que l’en-tête HTTP user-agent de Googlebot est souvent usurpé. Pour vérifier qu’une requête vient bien de Googlebot, Google recommande soit un reverse DNS lookup, soit la comparaison de l’adresse IP avec les plages IP publiées pour les crawlers Google. Google publie aussi les masques de reverse DNS attendus pour ses crawlers communs, comme googlebot.com. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/googlebot))

En pratique, pour une analyse SEO sérieuse, il faut donc conserver au minimum l’adresse IP source et le user-agent. Le bon réflexe n’est pas « user-agent contient Googlebot », mais « user-agent compatible + IP validée ». Cette étape évite de surévaluer le crawl de Google à cause de faux bots, et elle vaut aussi pour Bing, qui propose un outil officiel de vérification de Bingbot. ([bing.com](https://www.bing.com/webmasters/help/verify-bingbot-2195837f?utm_source=openai))

Quelles données extraire d’un log SEO

Pas besoin de collecter tout ce que le serveur sait faire pour démarrer. Pour lire le crawl, quelques champs suffisent, à condition qu’ils soient propres et exploitables :

Date et heure : pour mesurer la fréquence de passage et relier le crawl aux incidents ou déploiements.
URL demandée : idéalement normalisée, avec chemin et query string séparés pour isoler les paramètres.
Code de statut HTTP : indispensable pour distinguer un crawl utile d’un crawl gaspillé ou problématique.
User-agent : pour identifier le type de crawler, notamment Googlebot smartphone, desktop, image ou ressource.
Adresse IP source : pour valider l’authenticité du bot.
Octets envoyés ou taille de réponse : utile pour repérer les URL coûteuses et les réponses anormalement lourdes.
Host demandé : essentiel si le site a plusieurs sous-domaines, un CDN ou des environnements distincts.
Référent technique ou champs serveur complémentaires quand disponibles : parfois utiles pour comprendre des boucles ou des redirections.

Ces champs permettent déjà de répondre à la plupart des questions SEO sur le crawl. Ils sont aussi cohérents avec ce que Google recommande d’observer dans le rapport Crawl Stats : réponses serveur, types de fichiers, finalité des requêtes et type de Googlebot. ([support.google.com](https://support.google.com/webmasters/answer/9679690?hl=en))

Les segments à comparer en priorité

L’erreur la plus fréquente n’est pas de manquer de données, mais de regarder un volume global de crawl sans le découper. Un site peut afficher beaucoup d’activité Googlebot tout en explorant surtout les mauvaises zones. L’analyse utile repose donc sur des comparaisons entre segments homogènes.

Le premier découpage à faire est par type d’URL : pages HTML stratégiques, catégories, fiches produit, articles, pagination, recherche interne, paramètres, images, JS, CSS, fichiers API, sitemaps, flux, PDF. Google rappelle que les ressources de rendu et les médias sont crawlés séparément et consomment eux aussi du budget de crawl. Si une part excessive des requêtes part dans le rendu ou dans des ressources secondaires, cela mérite au moins d’être compris. ([developers.google.com](https://developers.google.com/search/blog/2024/12/crawling-december-resources?hl=en))

Le deuxième découpage est par valeur SEO : pages indexables et utiles, pages à faible valeur, pages non indexables, variantes, pages filtrées, URLs avec paramètres, pages destinées uniquement aux utilisateurs connectés. Ce classement n’existe pas dans les logs ; il faut l’ajouter via une table de correspondance ou des règles de segmentation. C’est ce qui permet de répondre à la vraie question métier : où part le crawl par rapport à ce qui mérite d’être crawlé ?

Le troisième découpage est par statut de réponse. Les groupes 2xx, 3xx, 4xx, 5xx et 304 ne racontent pas la même histoire. Google précise que les contenus renvoyés avec un code 2xx peuvent être pris en compte pour l’indexation, sans garantie. Les 4xx ne sont pas utilisés pour l’indexation ; les nouvelles pages 404 ne sont pas traitées et la fréquence d’exploration diminue progressivement. Les 5xx et les 429 font ralentir temporairement l’exploration. Les 304 permettent à Google de réutiliser la dernière version explorée quand le contenu n’a pas changé. ([developers.google.com](https://developers.google.com/crawling/docs/troubleshooting/http-status-codes?hl=fr))

Le quatrième découpage est par temps : avant/après une mise en production, semaine par semaine, jour par jour, ou heure par heure en cas d’incident. Sans cette comparaison temporelle, on voit mal l’effet réel d’un correctif.

Les indicateurs à suivre pour interpréter le crawl

Un bon tableau d’analyse de logs n’a pas besoin de cinquante métriques. Huit indicateurs couvrent déjà la majorité des besoins SEO techniques.

Volume de requêtes Googlebot : nombre total de hits validés Googlebot sur une période.
Répartition par segment : part du crawl allouée à chaque type d’URL ou dossier.
Ratio pages utiles / pages secondaires : part du crawl consacrée aux pages réellement importantes.
Répartition par statuts HTTP : 2xx, 3xx, 4xx, 5xx, 304, avec évolution dans le temps.
Fréquence de passage par URL ou par groupe d’URL : délai moyen entre deux visites.
Temps de première revisite après correctif : combien de temps Google met à revenir sur une zone modifiée.
Part du crawl sur ressources non HTML : images, JS, CSS, PDF, API, autres fichiers.
Concentration du crawl : combien d’URL captent la majorité des hits, utile pour repérer les surcrawlings.

Ces indicateurs font le lien entre logs et interprétation. Un volume élevé n’est pas forcément bon ; un volume faible n’est pas forcément mauvais. Tout dépend de la qualité des zones crawlées et de la stabilité des réponses serveur.

Cas concret n°1 : repérer les pages trop crawlées

Le surcrawling se voit quand une portion disproportionnée des requêtes touche des pages qui n’apportent pas de valeur de recherche : filtres combinatoires, pagination profonde, URLs paramétrées, recherches internes, variantes de tri, endpoints techniques, anciennes redirections encore massivement sollicitées. L’indicateur clé n’est pas seulement le nombre d’URL concernées, mais la part des hits qu’elles absorbent.

Exemple typique : un site e-commerce constate que Googlebot visite beaucoup le domaine, mais les nouveaux produits montent lentement dans l’exploration. Les logs montrent qu’une large part des hits part dans des URLs de filtres avec paramètres. Ce diagnostic devient solide si l’on compare trois groupes : pages produits indexables, catégories stratégiques et URLs à paramètres. Si les paramètres captent une part importante des requêtes alors qu’ils ne correspondent pas à des pages prioritaires, on a un problème d’allocation du crawl.

Google rappelle que toute URL crawlée affecte le budget de crawl, et que Googlebot découvre les nouvelles URLs principalement via les liens présents dans les pages déjà explorées. Si le site expose trop de variantes explorables, il augmente mécaniquement la charge de crawl inutile. ([developers.google.com](https://developers.google.com/search/blog/2017/01/what-crawl-budget-means-for-googlebot?utm_source=openai))

L’objectif n’est pas forcément de bloquer brutalement. Il faut d’abord comprendre l’origine : maillage interne, facettes ouvertes, liens générés par le front, paramètres sans contrôle, sitemaps trop larges ou redirections héritées. Ensuite seulement, on agit avec les leviers adaptés : architecture, liens, règles d’indexabilité, gestion des paramètres, ou robots.txt quand c’est pertinent. Google rappelle toutefois que bloquer le crawl n’est pas équivalent à empêcher l’apparition d’une URL dans les résultats, et que le blocage de ressources critiques au rendu peut créer d’autres problèmes. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/googlebot))

Cas concret n°2 : identifier les zones ignorées

L’autre grande utilité des logs est de repérer les sections peu ou pas explorées. Ici, l’analyse ne porte pas sur les hits excessifs, mais sur l’absence relative de visites. Pour cela, il faut comparer la liste des URLs ou des segments stratégiques attendus avec les requêtes réellement vues dans les logs sur une période donnée.

Une section peut être ignorée pour plusieurs raisons : maillage insuffisant, profondeur trop forte, découverte tardive, faibles signaux d’intérêt, duplication, ou arbitrage de crawl. Google indique d’ailleurs que si ses systèmes estiment avoir manqué du contenu de qualité sur un site, ils peuvent augmenter le budget pour pouvoir l’explorer. À l’inverse, proposer surtout des pages de faible qualité n’incite pas Googlebot à élargir son exploration. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors?authuser=0&hl=fr))

Concrètement, un non-expert peut suivre un indicateur simple : sur les pages stratégiques créées ou mises à jour au cours des 30 derniers jours, quelle part a reçu au moins une visite Googlebot validée ? Puis combien de jours s’écoulent avant la première visite ? Ces deux mesures disent beaucoup. Si une partie importante des nouvelles pages n’est jamais vue, ou très tard, le problème n’est pas le ranking : c’est d’abord la découverte ou la priorisation du crawl.

Cas concret n°3 : surveiller les erreurs serveur qui freinent Googlebot

Les 5xx et les 429 sont des signaux particulièrement importants. Google indique que les erreurs serveur 5xx et 429 poussent ses robots à ralentir temporairement l’exploration. Une fois que le serveur recommence à répondre en 2xx, Google augmente progressivement la vitesse d’exploration. Google précise aussi que le contenu reçu via une URL qui renvoie 5xx est ignoré. ([developers.google.com](https://developers.google.com/crawling/docs/troubleshooting/http-status-codes?hl=fr))

En analyse de logs, cela implique deux lectures. La première est quantitative : volume et pourcentage de 5xx/429 sur les requêtes Googlebot, avec la liste des segments touchés. La seconde est temporelle : les erreurs arrivent-elles à des heures précises, après un batch, sur un sous-domaine, ou seulement sur un template ? Une hausse des 503 sur certaines catégories pendant quelques heures peut suffire à ralentir le crawl d’une zone clé.

Pour des non-experts, une règle d’interprétation simple est utile : si les statuts 5xx ou 429 augmentent sur les hits Googlebot, il ne faut pas seulement regarder l’indexation ; il faut aussi surveiller la fréquence de passage des jours suivants. Le ralentissement n’est pas théorique, il peut se voir dans les logs.

Cas concret n°4 : lire la fréquence de passage

Google explique que, pour la plupart des sites, Googlebot ne devrait pas accéder au site plus d’une fois toutes les quelques secondes en moyenne, même si des délais peuvent donner l’impression d’un rythme plus élevé sur de courtes périodes. Cette précision est utile, mais elle ne remplace pas une mesure propre à votre site. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/googlebot))

Dans les logs, la fréquence de passage peut se lire à plusieurs niveaux : fréquence par URL, par répertoire, par template ou par famille de pages. Sur un site éditorial, par exemple, les pages d’accueil, rubriques et articles frais peuvent être revisités plus souvent que les archives profondes. Sur un e-commerce, certaines catégories ou fiches à fort renouvellement peuvent revenir souvent, alors que des fiches dormantes sont moins sollicitées.

L’intérêt est surtout comparatif. Si une catégorie stratégique n’est revisitée qu’occasionnellement, tandis qu’un répertoire secondaire concentre des revisites quotidiennes, l’allocation du crawl peut être mal orientée. À l’inverse, après un renforcement du maillage ou une correction d’erreurs serveur, une baisse du délai moyen de revisite sur les pages clés est un signal encourageant.

Cas concret n°5 : mesurer l’effet d’un correctif

L’analyse de logs devient particulièrement utile après une action technique : correction de redirections, fermeture d’URLs facettées, nettoyage de liens internes, amélioration des réponses serveur, simplification du rendu, ajustement du robots.txt, ou refonte d’une arborescence. Google indique que la Search Console peut continuer à afficher une erreur sur une page corrigée tant que la page n’a pas été explorée à nouveau. Les logs permettent justement de vérifier ce retour du bot, sans attendre un rapport agrégé. ([developers.google.com](https://developers.google.com/search/help/debug?utm_source=openai))

La bonne méthode consiste à mesurer au minimum quatre choses avant et après le correctif : part du crawl sur la zone concernée, distribution des statuts HTTP, délai moyen de revisite, et apparition ou disparition d’exemples problématiques. Si vous corrigez des 503 sur une section, vous devez chercher à la fois la chute des erreurs et la reprise graduelle du volume de crawl en 2xx. Si vous limitez des URLs paramétrées, vous devez voir leur part dans les hits baisser et, idéalement, une meilleure exposition des pages stratégiques.

Le code 304 mérite ici une attention particulière. Google précise qu’avec If-Modified-Since, le serveur peut renvoyer 304 Not Modified sans corps si le contenu n’a pas changé, et que Google réutilisera alors la dernière version explorée. Google ajoute qu’envoyer 304 quand le contenu n’a pas changé économise du temps et des ressources serveur, ce qui peut indirectement améliorer l’efficacité du crawl. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors?authuser=0&hl=fr))

Concrètement, une augmentation cohérente des 304 sur des contenus stables n’est pas forcément un problème. Elle peut signaler un site techniquement plus efficient, à condition que les pages réellement modifiées continuent bien de repasser en 200 quand nécessaire.

Comment démarrer sans se noyer dans l’outillage

Pour une première analyse, il n’est pas nécessaire de bâtir une usine à données. Une approche simple suffit : récupérer une période représentative, valider Googlebot par IP et user-agent, classer les URLs en quelques familles métier, puis calculer les indicateurs de base. La priorité est la qualité des segments, pas la sophistication du logiciel.

Un workflow minimal peut tenir en cinq étapes :

Collecter 7 à 30 jours de logs, selon le volume du site.
Filtrer les requêtes Googlebot authentifiées.
Segmenter les URLs en groupes utiles pour le SEO : stratégiques, secondaires, paramétrées, ressources, erreurs, redirections.
Comparer les parts de crawl, les statuts et la fréquence de passage entre groupes.
Rejouer la même lecture après un correctif pour mesurer l’effet réel.

En complément, le rapport Crawl Stats de la Search Console peut servir de contrôle externe : il aide à voir les tendances globales de Google, les réponses reçues, les types de fichiers et les finalités du crawl. Mais pour expliquer précisément ce qui se passe dans une zone du site, les logs restent la référence. ([support.google.com](https://support.google.com/webmasters/answer/9679690?hl=en))

Ce qu’il faut retenir

Les logs SEO ne sont pas réservés aux très grands sites ni aux profils ultra techniques. Google lui-même les présente comme la meilleure source pour savoir ce qu’il explore réellement. Leur force est de rendre le crawl observable, URL par URL, avec des preuves : qui a demandé quoi, quand, et avec quelle réponse serveur. ([developers.google.com](https://developers.google.com/search/blog/2024/12/crawling-december-resources?hl=en))

Pour qu’ils deviennent utiles, il faut toutefois respecter une discipline simple : vérifier l’authenticité de Googlebot, segmenter les URLs selon la valeur SEO, lire les statuts HTTP correctement, et comparer les évolutions dans le temps. C’est ainsi que l’on repère les pages trop crawlées, les zones ignorées, les erreurs qui freinent l’exploration et les effets réels d’un correctif. ([developers.google.com](https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests?utm_source=openai))

En SEO technique, beaucoup de sujets restent interprétatifs. Les logs, eux, réduisent l’incertitude. Ils ne disent pas tout sur le classement, mais ils disent très précisément quelque chose de fondamental : le comportement réel du crawler face à votre site.