Lire les logs serveur pour comprendre le passage de Googlebot

Jf Dupont consacre ce dossier à une source que beaucoup de sites laissent dormir : les journaux d'accès du serveur, appelés logs. Ils enregistrent chaque requête reçue, y compris celles de Googlebot. Les lire permet de savoir quelles pages le robot visite réellement, à quelle fréquence, et où il gaspille son temps. C'est la seule donnée qui montre le comportement du moteur sans filtre ni échantillonnage, là où les autres outils se contentent d'estimer ou de résumer.

• Les logs serveur listent chaque visite de robot, ligne par ligne, avec l'adresse demandée et le code de réponse.
• Ils révèlent les pages ignorées par Google, les erreurs répétées et le crawl perdu sur des URL inutiles.
• Un export de quatre semaines et un tableur suffisent pour une première analyse sérieuse.

Ce que contient une ligne de journal d'accès

Un serveur Apache ou Nginx écrit, pour chaque requête, une ligne au format dit combiné. On y trouve l'adresse IP du visiteur, la date et l'heure, la méthode et l'URL demandée, le code de statut HTTP renvoyé, le poids de la réponse, la page de provenance et enfin l'agent utilisateur, c'est-à-dire la signature que se donne le client.

Pris un par un, ces champs paraissent anodins. Croisés, ils racontent une histoire précise : telle fiche reçoit Googlebot trois fois par jour, telle autre n'a pas été touchée depuis deux mois, telle rubrique renvoie des 404 que personne n'avait remarquées. Aucun outil d'audit externe ne peut reconstituer cela, car un crawler tiers simule une visite au lieu d'observer celle du moteur.

Distinguer le vrai Googlebot des robots qui l'imitent

L'agent utilisateur se falsifie en une ligne de code. De nombreux scrapers se présentent donc comme Googlebot pour passer les protections. Avant toute conclusion, il faut écarter ces faux visiteurs, sinon les chiffres sont gonflés et les priorités faussées.

La vérification recommandée par Google tient en deux étapes. Une résolution DNS inverse sur l'adresse IP doit renvoyer un nom d'hôte se terminant par googlebot.com ou google.com. Une résolution directe de ce nom doit ensuite retomber sur la même IP. Google publie aussi la liste de ses plages d'adresses au format JSON, ce qui permet un filtrage automatique sur de gros volumes.

Les signaux à extraire en priorité

Un fichier de logs brut compte vite des centaines de milliers de lignes. Plutôt que de tout explorer, mieux vaut partir de quelques questions fermées.

SignalCe qu'il révèleAction possiblePages stratégiques jamais crawléesMaillage interne trop faible ou page orphelineAjouter des liens depuis des pages déjà visitéesPart de codes 3xx et 4xxRedirections en chaîne, liens cassésCorriger les liens internes à la sourceURL à paramètres très visitéesFiltres, tris ou sessions qui dupliquent les pagesBloquer ou canonicaliser ces variantesFréquence de passage par rubriqueZones que le moteur juge vivantes ou délaisséesRéorienter la mise à jour éditorialeCodes 5xx ponctuelsServeur saturé à certaines heuresVérifier l'hébergement et le cache

Le croisement le plus parlant reste celui des logs avec la liste des URL que l'on souhaite voir indexées, issue du sitemap. L'écart entre les deux ensembles dessine la carte des efforts à fournir.

Budget de crawl : repérer le temps perdu par les robots

Sur un petit site, Google finit presque toujours par tout parcourir. La question du budget de crawl devient sensible au-delà de quelques milliers d'URL, ou dès qu'un module génère des adresses à l'infini : calendriers, combinaisons de filtres, pages de recherche interne indexables.

Dans ces cas, les logs montrent souvent une proportion étonnante de visites consacrées à des pages sans valeur. Chaque requête dépensée sur une variante inutile est une requête qui ne sert pas un contenu neuf. Nettoyer ces fuites accélère la prise en compte des publications récentes, un gain mesurable en comparant la date de mise en ligne et la date du premier passage de Googlebot.

Faire parler une donnée brute, une compétence qui dépasse le SEO

Analyser des logs n'a rien de magique : c'est un travail de tri, de vérification des sources et de questionnement. Le référenceur part d'un volume énorme d'événements, écarte le bruit, puis isole les quelques indicateurs qui orientent une décision. La valeur ne vient jamais de la quantité de données collectées, mais de la pertinence de la question posée au départ.

Ce mécanisme se retrouve à l'identique dans d'autres métiers où l'information arrive en flux continu. Les clubs et les organisateurs d'événements qui croisent billetterie, audiences et retombées de partenariats suivent la même discipline, comme le détaille une analyse pertinente dans cette revue spécialisée consacrée à l'économie du secteur : sans hypothèse claire, un tableau de chiffres ne dit rien à personne. Pour un site web, la règle est identique, et c'est elle qui sépare une analyse de logs utile d'un simple export archivé.

Monter une première analyse sans infrastructure lourde

Inutile de déployer une pile logicielle complexe pour commencer. La démarche suivante convient à la plupart des sites éditoriaux :

Récupérer les fichiers bruts depuis l'interface de l'hébergeur ou par accès SFTP, sur au moins quatre semaines.

Filtrer les lignes dont l'agent utilisateur mentionne Googlebot, puis valider les IP par DNS inverse.

Regrouper les URL par répertoire ou par type de page pour obtenir une vue lisible.

Comparer cette liste au sitemap et noter les pages absentes ou surreprésentées.

Répéter l'exercice après chaque correction pour vérifier que le comportement du robot a bien changé.

Un analyseur de logs dédié fait gagner du temps sur les gros fichiers, mais un tableur et quelques formules suffisent pour un site de quelques centaines de pages. L'essentiel est de conserver les exports successifs afin de comparer les périodes entre elles.

Lever les doutes avant d'ouvrir ses premiers fichiers

Les logs d'un hébergement mutualisé sont-ils accessibles ?

Dans la majorité des cas, oui. Les panneaux d'administration courants proposent un accès aux journaux bruts, parfois limité à quelques jours. Il faut alors programmer un téléchargement régulier pour constituer un historique exploitable.

Sur combien de jours une analyse de logs devient-elle fiable ?

Quatre semaines donnent une image correcte d'un site de taille moyenne. Les pages profondes peuvent n'être visitées qu'une fois par mois, une fenêtre plus courte risque donc de les faire passer pour ignorées à tort.

Une page que Googlebot n'a jamais demandée peut-elle apparaître dans les résultats ?

Une URL peut être indexée sans contenu si des liens externes la signalent, mais une page jamais explorée ne peut pas être classée sur son texte. L'absence de passage dans les logs reste donc un signal d'alerte sérieux.

L'analyse de logs rend-elle la Search Console inutile ?

Non, les deux sources se complètent. La Search Console renseigne sur les impressions, les clics et l'état d'indexation, tandis que les logs décrivent l'exploration réelle. Les rapprocher permet de relier un problème de visibilité à sa cause technique.