Log file analysis

Ce que le log dit et qu'aucune autre source ne dit

Un crawler simule un parcours à partir des liens qu'il trouve. La Search Console rapporte un agrégat échantillonné, avec un décalage de quelques jours et des catégories fermées que vous ne pouvez pas redécouper. Le fichier de log, lui, est un journal d'événements bruts : chaque requête HTTP reçue par le serveur y écrit une ligne, avec l'IP source, l'horodatage, la méthode, l'URL demandée, le code de retour, le poids de la réponse, le referer et le user-agent. Ce n'est pas une modélisation du crawl, c'est le crawl.

La conséquence pratique tient en une phrase : le log est la seule source qui documente les non-événements. Une URL déclarée dans le sitemap et jamais demandée par Googlebot depuis six semaines, aucun crawl simulé ni aucun rapport d'indexation ne vous la sort proprement. Les pages orphelines fonctionnent dans l'autre sens : le log montre des URL réellement requêtées, variantes à paramètres, vieux chemins encore liés depuis l'extérieur, restes de migration, que le crawler ne trouvera jamais puisque plus rien n'y pointe en interne. L'intersection des deux ensembles, ce que le sitemap promet et ce que le bot demande, est l'unique livrable qui justifie à lui seul une analyse de logs.

Deuxième écart, souvent mal compris en réunion technique : les analytics JavaScript ne voient pas les bots, par construction. Pas d'exécution du tag, pas de hit. Comparer un rapport GA4 et un fichier de log ne revient pas à comparer deux mesures du même phénomène, mais l'audience humaine d'un côté et l'activité machine de l'autre. Les deux sources ne se contredisent jamais, elles ne parlent pas de la même chose.

Anatomie d'une ligne, et comment la parser sans usine à gaz

Le format n'a pas bougé depuis vingt ans. Apache et nginx écrivent par défaut en Combined Log Format, une extension du Common Log Format à laquelle s'ajoutent le referer et le user-agent. Voici à quoi ressemble une visite de Googlebot, telle qu'elle est écrite sur disque :

66.249.66.1 - - [12/Jul/2026:08:14:22 +0200] "GET /guides/netlinking/ HTTP/1.1" 200 18422 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Cette ligne dit quatre choses exploitables : l'IP appartient à une plage annoncée par Google et doit être vérifiée, la requête a été servie en 200 avec 18 422 octets, il n'y a pas de referer parce qu'un bot n'en envoie pas, et le user-agent se déclare Googlebot, ce qui ne prouve rien tant que la vérification n'a pas été faite. Multipliée par plusieurs millions de lignes, cette structure suffit à répondre à presque toutes les questions de crawl.

Pour un premier tri, la ligne de commande reste plus rapide que n'importe quelle interface : un filtre sur le user-agent, une extraction du champ du code de retour, un comptage avec uniq et un tri décroissant donnent en trois secondes la distribution des statuts servis à Googlebot sur un fichier de plusieurs gigaoctets. Dès qu'il faut croiser, Python prend le relais :

import pandas as pd

df = pd.read_csv("access.log", sep=" ", header=None, engine="python")
df.columns = ["ip", "id", "user", "ts", "tz", "req", "status", "size", "ref", "ua"]
googlebot = df[df["ua"].str.contains("Googlebot", na=False)]
print(googlebot["status"].value_counts())
print(googlebot["req"].value_counts().head(20))

Au-delà de quelques dizaines de millions de lignes, charger le fichier entier en mémoire n'est plus tenable. Le réflexe est alors de lire par blocs, ou de pointer DuckDB directement sur les fichiers compressés et de raisonner en SQL. Ce détail technique décide souvent de la faisabilité du projet : une équipe qui n'a pas prévu ça abandonne au bout de deux heures et conclut que « les logs, ça ne marche pas chez nous ».

Crawl budget en 2026 : Googlebot d'un côté, les bots IA de l'autre

La documentation Google sur le budget de crawl des grands sites, mise à jour en décembre 2025, le décompose en deux termes : la limite de taux, ce que le serveur encaisse, et la demande de crawl, ce que Google veut chercher selon la popularité, la fraîcheur et la valeur perçue des URL. Les seuils cités par Google restent le million de pages uniques mises à jour chaque semaine, ou plus de 10 000 pages mises à jour quotidiennement. En dessous, le sujet ne se pose pas, et il faut le dire franchement : sur un site de 800 pages, un rapport de logs qui parle de gaspillage de crawl budget vend du vent. La valeur y est ailleurs, dans les codes de retour, la fraîcheur de recrawl et les orphelines.

La même documentation rappelle qu'on ne réalloue pas un budget avec robots.txt : bloquer des URL ne transfère pas automatiquement la capacité libérée vers d'autres, sauf si la capacité serveur était réellement la contrainte. Le chiffre de 30 à 50 % de crawl non essentiel qui circule dans les guides est une estimation de praticiens, pas un repère publié par Google, et il ne devrait jamais servir d'objectif chiffré dans une recommandation.

Ce qui a vraiment changé, c'est la population de robots. Le rapport Cloudflare Radar publié le 16 décembre 2025 mesure 4,2 % des requêtes HTML de son réseau générées par des bots IA non-Google, contre environ 4,5 % pour Googlebot, ce dernier restant le crawler vérifié dominant avec plus de 28 % du trafic de bots vérifiés. La part IA n'est pas stable : elle oscille entre 2,4 % début avril 2025 et 6,4 % fin juin 2025 selon les mêmes données. Les analyses publiées à partir de ces chiffres relèvent un volume Googlebot en hausse de 96 % sur un an entre mai 2024 et mai 2025, et GPTBot en hausse de 305 %. Conclusion opérationnelle : un tableau de bord qui agrège « les robots » en une seule courbe ne permet plus de savoir si une surcharge serveur pénalise le crawl de recherche ou si elle vient de la récupération de contenu par un moteur génératif. Il faut au minimum quatre familles : Googlebot, Bingbot, les crawlers d'entraînement type GPTBot ou ClaudeBot, et les fetchers déclenchés par une action utilisateur.

Il y a un usage netlinking du log que presque personne n'exploite, et c'est dommage. Quand un lien est inséré dans un article existant, il n'a aucun effet tant que la page n'a pas été recrawlée. Le log de l'éditeur répond en une requête : date du dernier passage de Googlebot sur cette URL, avant et après l'insertion. C'est l'un des rares contrôles honnêtes qu'un acheteur puisse demander, et c'est ce qui distingue un média réellement crawlé d'une coquille jamais revisitée. Sur un catalogue de médias consultable sans inscription, la fréquence de recrawl vaut mieux qu'un score d'autorité pour trier les supports.

Cette démonstration filmée montre l'effet concret d'une analyse de logs sur la façon dont Google explore un site :

La méthode : de la ligne brute à la décision

Tout commence par la fenêtre d'observation, et c'est là que la plupart des missions échouent avant d'avoir commencé. Beaucoup d'hébergements mutualisés purgent au bout de sept jours. Sept jours ne couvrent aucun phénomène intéressant : la mise à jour core de décembre 2025 s'est déployée du 11 au 29 décembre, soit dix-huit jours. Trente jours constituent un minimum, quatre-vingt-dix jours permettent de comparer avant et après une refonte. La demande de rétention se fait avant le début de la mission, jamais pendant.

Vient la vérification des bots. Un user-agent se falsifie en une ligne de curl, et les logs de n'importe quel site contiennent des faux Googlebot, scrapers ou outils de veille concurrentielle. La méthode officielle reste la résolution DNS inverse de l'IP, qui doit renvoyer un hôte en googlebot.com ou google.com, puis la résolution directe de cet hôte, qui doit ramener l'IP de départ. Google publie aussi ses plages d'IP en JSON, ce qui permet de filtrer par appartenance sans requête DNS pour chaque ligne. Tant que ce filtre n'est pas posé, chaque conclusion tirée du fichier est fausse d'un facteur inconnu.

Ensuite, on ne regarde pas les URL une par une, on agrège par gabarit : répertoire, type de page, présence de paramètres. Les questions à poser au jeu de données sont toujours les mêmes. Quelle part du crawl part sur la navigation à facettes, la pagination profonde et les résultats de recherche interne. Quelles URL du sitemap n'ont jamais été demandées. Quels chemins renvoient des 404 ou des chaînes de redirections répétées à chaque visite. Quel est le temps de réponse servi au bot aux heures de forte activité, sachant qu'un serveur qui ralentit fait baisser la limite de taux, et que ce même ralentissement dégrade en parallèle les Core Web Vitals côté utilisateur.

La dernière étape est une jointure, jamais un rapport isolé : la liste des URL crawlées se croise avec l'export du sitemap, l'export du crawler et les impressions Search Console. Quatre statuts en sortent, et chacun appelle une action différente : crawlée et performante, crawlée et sans impression, jamais crawlée mais stratégique, crawlée alors qu'elle ne devrait pas exister. Un tableau de logs qui ne débouche pas sur ces quatre piles reste une curiosité technique.

Pour visualiser l'enchaînement complet sur un cas réel, cette vidéo déroule la manipulation de bout en bout :

Outils : ce qu'ils font vraiment, ce qu'ils coûtent

Le Log File Analyser de Screaming Frog est un logiciel distinct du SEO Spider, souvent confondu avec lui. Les comparatifs publiés au deuxième trimestre 2026 le situent à 99 £ par an, gratuit jusqu'à 1 000 événements de log, certains agrégateurs de prix affichant l'équivalent de 128 à 139 dollars annuels. Sa force reste la jointure native avec un crawl du même site, qui produit directement la liste des orphelines. Sa limite est la machine locale : au-delà de quelques dizaines de millions de lignes, l'analyse devient pénible.

Le Log File Analyzer de Semrush joue un autre rôle, celui du diagnostic rapide intégré à une suite déjà en place, avec une lecture immédiate des statuts et de la fréquence de passage. Botify se place à l'autre extrémité, sur des sites à très gros volume où l'ingestion continue et la segmentation par gabarit valent leur prix. Côté libre, GoAccess reste l'outil le plus honnête pour un contrôle quotidien en terminal, et le couple DuckDB plus Python couvre tout ce que les interfaces ne savent pas faire, notamment les jointures multi-sources.

Cette démonstration montre l'interprétation des passages de Googlebot dans une de ces interfaces :

Sur les médias éditoriaux que nous opérons en propre, le suivi n'a pas besoin d'un outil à quatre chiffres : un agrégat quotidien par domaine, avec date de dernier passage de Googlebot par URL et distribution des statuts, suffit à repérer un site qui décroche. Le choix de l'outil compte beaucoup moins que la régularité de la mesure.

Ce qu'on voit rater le plus souvent

Le piège numéro un est le CDN. Si le cache sert la réponse en périphérie, la requête n'atteint jamais l'origine et n'apparaît pas dans le log applicatif. L'analyse conclut alors à un sous-crawl inexistant. La règle est simple : sur une architecture avec cache en frontal, on travaille sur les logs du CDN, ou sur les deux sources en parallèle, jamais sur l'origine seule. Même logique avec un load balancer mal configuré, où toutes les IP sources deviennent identiques et rendent impossible toute vérification de bot.

Deuxième piège, l'échantillon d'une journée. Googlebot n'a aucune raison de traiter un mardi comme un dimanche, et une journée de sitemap poussé fausse toute la distribution. Troisième piège, l'absence de vérification des user-agents, déjà évoquée, qui gonfle artificiellement la présence de Googlebot sur les sites très scrapés.

Le dernier, plus récent, est conceptuel. Un rapport de logs qui présente une hausse du crawl comme une victoire fait un raccourci que 2026 ne permet plus. L'étude Ahrefs mise à jour le 28 mai 2026, portant sur 300 000 mots-clés et des données Search Console agrégées, mesure un CTR en position 1 sur requêtes informationnelles passé de 0,076 en décembre 2023 à 0,039 en décembre 2025, et de 0,073 à 0,016 sur les requêtes affichant un AI Overview, soit une baisse de 58 % attribuée par Ahrefs à cette fonctionnalité. Une page peut être crawlée plus souvent et rapporter moins de clics. Depuis le 3 juin 2026, Google expose des rapports Search Console dédiés à la visibilité générative, avec les impressions issues d'AI Overviews et d'AI Mode : c'est à ces données qu'il faut joindre les logs pour produire un constat défendable, plutôt qu'à une courbe de passages de bots lue toute seule.