Comment lire un fichier de logs Apache pour isoler le crawl de Googlebot ?

Un fichier de logs Apache est la seule source qui dise avec certitude ce que Googlebot a demandé sur un site, à quelle heure, et ce que le serveur lui a répondu. Tout le reste, y compris la Search Console, est une reconstitution partielle et différée. La difficulté n'est pas d'obtenir ces journaux, la plupart des hébergeurs les mettent à disposition, mais de séparer les quelques milliers de lignes qui concernent le robot d'exploration des centaines de milliers qui concernent les visiteurs, les robots d'aspiration et les scanners de vulnérabilités. Cet article décrit la lecture d'un journal ligne à ligne, la vérification d'identité du robot, les filtres qui donnent un résultat exploitable, et les quatre indicateurs qu'un mois de journaux permet de calculer. Tout ce qui suit se fait avec les outils présents sur n'importe quel serveur, sans installer le moindre logiciel d'analyse : sur un journal mensuel, un enchaînement de grep, de awk et de sort traite plusieurs millions de lignes en quelques secondes, là où un outil graphique renonce ou réclame un import préalable de plusieurs heures.

Ce que contient réellement une ligne de log Apache

Avant tout filtrage, il faut savoir ce qu'on lit. Le format par défaut d'Apache, appelé combined, produit une ligne par requête, composée de champs séparés par des espaces, certains regroupés entre guillemets ou entre crochets. Cette structure est stable et documentée, ce qui permet de la traiter avec des outils aussi simples que grep et awk, sans jamais charger le fichier entier en mémoire. C'est un point important sur un site de contenu, où un journal mensuel dépasse fréquemment le gigaoctet. Nous détaillons cette lecture dans notre rubrique consacrée au référencement naturel, mais le préalable reste toujours le même : identifier les champs avant de filtrer quoi que ce soit.

Les champs du format combined, un par un

La ligne commence par l'adresse IP du client, suivie de deux champs d'identification presque toujours vides, remplacés par un tiret. Vient ensuite l'horodatage entre crochets, avec le décalage horaire, ce qui compte dès qu'on compare des journaux à des données Search Console exprimées en heure du Pacifique. Le quatrième champ, entre guillemets, contient la requête complète : la méthode HTTP, le chemin demandé avec sa chaîne de paramètres, et la version du protocole. Suivent le code de réponse et le nombre d'octets envoyés, puis deux champs entre guillemets, le référent et l'agent utilisateur. C'est ce dernier champ qui contient la signature du robot, et c'est aussi le plus facile à falsifier, raison pour laquelle il ne suffit jamais à lui seul.

Les variantes de format qui cassent les scripts

Tous les hébergeurs ne servent pas le format combined tel quel. Certains ajoutent le nom d'hôte en tête de ligne, ce qui décale tous les champs d'un cran et fait échouer silencieusement un script écrit pour le format standard. D'autres insèrent le temps de traitement de la requête, en microsecondes, entre la taille de la réponse et le référent. Derrière un répartiteur de charge ou un service comme Cloudflare, l'adresse IP du premier champ est celle du proxy, l'adresse réelle se trouvant dans un en-tête X-Forwarded-For qu'il faut avoir pensé à journaliser. Le premier réflexe consiste donc à afficher trois lignes du fichier et à compter les champs à la main avant d'écrire la moindre commande. Cette minute passée à lire évite des heures d'analyse fondée sur un décalage d'un champ, erreur d'autant plus insidieuse qu'elle ne produit aucun message : le script tourne, sort des chiffres, et ces chiffres décrivent le référent quand on croyait mesurer l'agent utilisateur.

Les fichiers compressés et la rotation

Les journaux sont presque toujours soumis à une rotation quotidienne ou hebdomadaire, les anciens fichiers étant compressés au format gzip. Il est inutile de les décompresser : les commandes zgrep et zcat lisent directement l'archive et évitent d'occuper plusieurs gigaoctets de disque pour rien. Sur un hébergement mutualisé, la rétention dépasse rarement trente jours, ce qui impose de récupérer les fichiers régulièrement si l'on veut travailler sur une fenêtre plus longue. Un mois est le minimum utile pour observer une fréquence de passage, trois mois permettent de distinguer une tendance d'une variation saisonnière. Sur un serveur dédié ou un VPS, la rétention se règle dans la configuration de logrotate, où porter la valeur à quatre-vingt-dix jours ne coûte que quelques centaines de mégaoctets une fois les fichiers compressés. C'est un réglage à faire avant d'en avoir besoin, puisqu'un journal effacé ne se reconstitue pas.

Vérifier qu'il s'agit bien de Googlebot

Filtrer sur la chaîne Googlebot dans l'agent utilisateur donne un résultat immédiat, et faux. N'importe quel script peut se déclarer Googlebot, et beaucoup le font, précisément parce que les sites traitent ce robot avec plus d'égards que les autres. Sur les journaux que nous examinons, la proportion de lignes se réclamant de Googlebot sans en être varie de dix à quarante pour cent selon l'exposition du site. Cette vérification est la même que celle décrite dans notre article sur l'analyse de logs en SEO, et elle repose sur une propriété que les usurpateurs ne peuvent pas reproduire.

La résolution DNS inversée puis directe

La méthode officielle tient en deux étapes. On demande d'abord le nom d'hôte associé à l'adresse IP de la ligne, par une résolution inversée. Ce nom doit se terminer par googlebot.com ou google.com. On résout ensuite ce nom en adresse IP, par une résolution directe, et on vérifie qu'on retombe exactement sur l'adresse de départ. Une usurpation échoue à la première étape, car l'attaquant ne contrôle pas la zone inverse de son fournisseur, ou à la seconde, car il ne contrôle pas la zone directe de Google. La vérification en une seule étape, qui se contente du nom d'hôte inverse, reste insuffisante : rien n'empêche un hébergeur complaisant de déclarer une zone inverse arbitraire, et c'est précisément ce que la résolution directe recoupe. Cette double vérification coûte une requête DNS par adresse distincte, pas par ligne : sur un journal mensuel, quelques centaines d'adresses suffisent à couvrir la totalité du trafic de Googlebot.

La liste d'adresses publiée par Google

Google publie désormais les plages d'adresses de ses robots dans des fichiers JSON accessibles publiquement, ce qui permet de se passer de résolution DNS en comparant l'adresse à un ensemble de préfixes. C'est plus rapide sur un gros volume, et cela fonctionne hors ligne. Le fichier distingue les plages du robot d'exploration classique, celles des fetchers déclenchés par une action utilisateur, et celles des services spéciaux. Ces listes évoluent, il faut donc les rafraîchir avant chaque analyse plutôt que les figer dans un script écrit deux ans plus tôt. En pratique, la comparaison se fait par préfixe réseau et non par égalité stricte, ce qui suppose de manipuler des blocs CIDR plutôt que des adresses : une bibliothèque standard suffit, dans presque tous les langages, et le contrôle porte sur quelques centaines de blocs seulement.

Distinguer les différents robots de Google

Sous le nom de Googlebot se cachent plusieurs agents dont les usages diffèrent. Le robot pour ordinateur et celui pour mobile n'explorent pas dans les mêmes proportions, l'indexation étant orientée mobile depuis plusieurs années. S'ajoutent le robot des images, celui des vidéos, celui de Google Ads qui contrôle les pages de destination, et plus récemment les agents liés aux fonctionnalités génératives. Confondre ces populations fausse toute mesure de fréquence : un pic de passages du robot publicitaire n'a rien à voir avec l'exploration organique, et l'agent d'inspection déclenché depuis la Search Console apparaît dans les journaux sans rien dire de l'exploration spontanée. La règle de tri est simple : conserver les agents pour ordinateur et pour mobile dans la mesure principale, isoler les autres dans des comptages séparés, et ne jamais additionner l'ensemble sous une même étiquette.

Les filtres qui produisent un résultat exploitable

Une fois les lignes authentifiées, l'analyse consiste à agréger. Compter les passages par jour, par répertoire, par code de réponse, puis croiser ces comptes avec la liste des URL réellement publiées. C'est à ce stade que les journaux disent des choses que rien d'autre ne dit, et notamment comment se répartit le budget de crawl de Googlebot entre les pages qui comptent et celles qui ne comptent pas. Les commandes ci-dessous supposent un format combined standard, à adapter au vôtre après le comptage des champs.

Agréger par jour et par répertoire

Le comptage par jour se fait en extrayant la partie date de l'horodatage et en dénombrant les occurrences. Le comptage par répertoire demande de découper le chemin demandé sur le premier segment, ce qui donne immédiatement la répartition entre le blog, les pages fixes, la médiathèque et les éventuels répertoires techniques. Sur les sites de contenu que nous auditons, ce simple tableau révèle souvent qu'un tiers des passages est consacré à des ressources statiques déjà en cache navigateur, ou à des répertoires qui n'auraient jamais dû être explorables. Le rapport entre les passages sur les articles et les passages sur les pages de liste est un autre chiffre parlant. Le découpage par segment mérite d'être affiné dès que le site dépasse quelques centaines de pages : sur deux niveaux plutôt qu'un, on distingue une rubrique saturée d'une rubrique délaissée, et l'on voit apparaître des répertoires oubliés, restes d'une ancienne installation, qui continuent de recevoir des visites sans rien apporter.

Croiser avec les codes de réponse

La distribution des codes est un indicateur de santé immédiat. Une proportion élevée de 404 signale des liens internes cassés ou un sitemap périmé. Une proportion élevée de 301 indique des chaînes de redirections qui consomment le budget d'exploration deux fois pour une seule page utile. Les 304, qui répondent qu'une ressource n'a pas changé, sont au contraire un bon signe : ils coûtent presque rien au serveur et signalent que les en-têtes de cache sont correctement posés. Les 5xx, même rares, méritent un examen individuel, car un serveur qui échoue pendant une exploration voit sa fréquence de passage diminuer durablement. Il faut regarder leur horaire autant que leur nombre : quelques erreurs groupées sur un même créneau nocturne désignent une tâche planifiée trop gourmande, alors que des erreurs dispersées signalent plutôt une saturation ponctuelle du nombre de processus disponibles.

Repérer les pages jamais visitées

L'opération la plus utile consiste à comparer l'ensemble des URL apparaissant dans les journaux avec l'ensemble des URL publiées, obtenu depuis le sitemap ou depuis un crawl. La différence donne deux listes. Les URL explorées mais non publiées désignent des pages fantômes, des paramètres oubliés ou des restes d'une ancienne version du site. Les URL publiées mais jamais explorées sur la période sont plus préoccupantes : ce sont des pages que Google n'a pas visitées depuis au moins un mois, généralement parce qu'elles sont trop profondes ou parce qu'aucun lien interne récent ne pointe vers elles. La comparaison demande de normaliser les deux ensembles avant de les soustraire, faute de quoi la moitié des écarts constatés ne sont que des différences de barre oblique finale, de casse ou d'encodage de caractères accentués.

Les quatre indicateurs à tirer d'un mois de journaux

Un journal n'a d'intérêt que s'il produit des chiffres comparables d'un mois sur l'autre. Quatre indicateurs suffisent à suivre l'exploration d'un site de contenu, et ils se calculent tous à partir des agrégats précédents. Ils ne remplacent pas l'analyse qualitative des chemins explorés, mais ils permettent de savoir si une action a produit un effet, ce que l'observation à l'œil nu ne permet jamais d'affirmer.

Le taux de pages explorées

C'est la part des URL publiées qui a reçu au moins une visite du robot sur la période. Un site sain se situe au-dessus de quatre-vingt-dix pour cent sur trente jours. En dessous de soixante-dix pour cent, une partie du site est structurellement hors d'atteinte, et aucune optimisation de contenu ne corrigera cela tant que le maillage n'aura pas été repris. Le calcul demande une précaution : les URL redirigées et les pages retirées doivent sortir du dénominateur, sans quoi l'indicateur se dégrade mécaniquement à chaque nettoyage du site, donnant l'impression exactement inverse de ce qui se passe. Cet indicateur a l'avantage d'être insensible au volume : il compare le site à lui-même. Il gagne à être calculé rubrique par rubrique plutôt que globalement, car une moyenne satisfaisante masque souvent une rubrique entière laissée de côté, dont les articles ne reçoivent plus aucune visite depuis des semaines.

La fréquence moyenne de passage

Elle se calcule en divisant le nombre de passages authentifiés par le nombre d'URL distinctes explorées. Prise seule, elle ne dit rien ; suivie dans le temps, elle indique si Google accorde plus ou moins d'attention au site. Une hausse après une amélioration du temps de réponse est fréquente et se constate en deux à trois semaines. Une baisse après une publication massive de contenu faible est tout aussi fréquente, et beaucoup moins agréable à constater. Il faut se garder d'interpréter une variation isolée : entre deux mois, un écart de dix à quinze pour cent relève du bruit, et seule une inflexion tenue sur trois relevés successifs mérite qu'on cherche une cause.

La répartition entre articles et pages techniques

Ce rapport mesure l'efficacité du budget d'exploration. On additionne les passages sur les contenus éditoriaux d'un côté, sur les pages de liste, les archives et les ressources de l'autre. Un rapport favorable aux contenus indique que la structure du site oriente correctement le robot. Un rapport inverse justifie de revoir l'indexabilité des pages de navigation, sujet que nous avons traité en détail à propos de la pagination des rubriques. La mesure suppose une convention de classement stable, écrite une fois pour toutes : sans elle, deux analyses menées à trois mois d'intervalle ne sont pas comparables, chacun ayant rangé les archives et les pages de recherche interne dans la catégorie qui l'arrangeait.

Le délai de première visite d'un contenu neuf

Il se mesure en cherchant, pour chaque article publié dans le mois, la date de son premier passage dans le journal. Le délai médian est un excellent indicateur de la vitalité d'un site : quelques heures sur un site fréquemment exploré, plusieurs jours sur un site négligé. C'est aussi la mesure la plus directe de l'effet d'un maillage interne depuis les contenus récents, puisqu'un article relié dès sa publication est découvert nettement plus vite qu'un article laissé seul dans sa rubrique. La médiane vaut mieux que la moyenne pour cet indicateur, un seul article découvert au bout de trois semaines suffisant à décaler une moyenne calculée sur une trentaine de publications.