Anatomie d'une ligne de journal
Un log d'accès, c'est une liste d'événements. Quelqu'un (ou quelque chose) a demandé une URL à votre serveur, le serveur a répondu, et il en garde une trace. Dans le format « combiné » d'Apache ou de Nginx, les champs sont toujours les mêmes et toujours dans le même ordre : IP du demandeur, horodatage, méthode et URL, code HTTP, poids de la réponse, referer, user-agent.
Ça donne ceci, en simplifiant un peu :
66.249.66.1 - - [11/Aug/2026:09:14:22 +0200] "GET /guide-technique/ HTTP/1.1" 200 18432 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Quatre champs portent l'essentiel de la valeur : l'URL, le code de réponse, l'horodatage et le user-agent. Avec ces quatre-là et un peu de volume, vous reconstituez la carte de ce que Google a parcouru, à quelle fréquence, et ce qu'il a reçu en face.
Pourquoi cette source et pas une autre
Un crawler type Screaming Frog vous montre votre site tel qu'un robot bien élevé le verrait aujourd'hui, en suivant les liens depuis l'accueil. Utile, mais théorique : c'est une simulation. La Search Console, elle, publie un rapport « Statistiques d'exploration » qui donne les grandes masses (volume de requêtes, temps de réponse, types de fichiers). Gratuit et fiable, mais agrégé : ça ne descend pas à l'URL.
Les journaux n'ont ni l'un ni l'autre de ces défauts. Ils sont exhaustifs et nominatifs. C'est là que vous découvrez que Googlebot repasse sans arrêt sur une page de pagination sans intérêt et jamais sur la fiche que vous venez de publier. Aucun autre outil ne vous dira ça.
Mettre la main sur les fichiers
C'est souvent l'étape qui bloque, et rarement pour des raisons techniques. Sur un serveur dédié ou un VPS, les fichiers sont à leur place habituelle : /var/log/nginx/access.log ou /var/log/apache2/access.log, avec les archives compressées à côté. Vous les récupérez en SSH et c'est réglé.
Sur un mutualisé, ça dépend de l'hébergeur : certains les exposent dans le panneau d'administration ou en FTP, d'autres seulement sur demande, d'autres pas du tout. Posez la question au support avant de promettre une analyse à un client.
Si le site est derrière un CDN, attention au piège : le serveur d'origine ne voit plus qu'une fraction du trafic, puisque le cache répond à sa place. Les logs pertinents sont alors ceux du CDN, généralement via une fonction d'export réservée aux offres hautes. Sinon vous analyserez un échantillon biaisé sans le savoir.
Dernier point, moins glamour mais réel en France : ces fichiers contiennent des adresses IP. La CNIL considère l'adresse IP comme une donnée personnelle, ce qui implique une durée de conservation limitée et proportionnée. Si vous exportez vos logs vers un outil tiers, vérifiez où ils atterrissent.
Vérifier que Googlebot est bien Googlebot
Le user-agent se déclare, donc il se falsifie. N'importe quel script peut s'annoncer comme Googlebot, et beaucoup le font. Prenez ce champ pour argent comptant et vos volumes seront gonflés, vos conclusions fausses.
La méthode officielle tient en deux temps : une résolution DNS inverse sur l'IP, qui doit renvoyer un nom en googlebot.com ou google.com, puis une résolution directe de ce nom, qui doit retomber sur l'IP de départ. Google publie aussi ses plages d'IP au format JSON, plus rapide à filtrer sur gros volume. La procédure complète est sur le site développeurs de Google. Faites-le une fois, gardez la liste d'IP validées, rejouez le contrôle de temps en temps.
Ce qu'on cherche vraiment dedans
Une fois les données propres, l'analyse ne consiste pas à regarder des lignes défiler. On agrège, et on traque les écarts entre ce que le site devrait offrir et ce que le robot a réellement consommé.
- Les pages jamais visitées. Croisez les URL de votre sitemap avec celles qui apparaissent dans les journaux sur la période. Ce qui figure dans le premier ensemble et pas dans le second n'existe pas pour Google. C'est le diagnostic le plus rentable de toute l'analyse, et souvent le plus douloureux.
- Les URL surexplorées. À l'inverse, des familles d'adresses aspirent une part démesurée des passages : filtres à facettes, tris, paramètres de suivi, calendriers infinis, pagination profonde. Chaque requête dépensée là ne l'est pas ailleurs.
- La répartition des codes HTTP. Proportion de 200, 301, 404 et 5xx servis au robot, et surtout son évolution. Une remontée de 5xx sur les créneaux les plus chargés veut dire que le serveur cale. Une masse de 301 en chaîne signale un historique de redirections mal nettoyé.
- Les pages orphelines explorées. Des URL visitées alors qu'aucun lien interne ne pointe dessus : anciens contenus, pages de test, versions d'impression, restes de migration.
- Les ressources. Si les fichiers JS et CSS nécessaires au rendu n'apparaissent jamais, ou reviennent en 403, vous avez un problème d'accès.
Le premier et le deuxième point se lisent ensemble : c'est le lien direct avec ce que recouvre le budget d'exploration et les cas où il vaut la peine de l'optimiser, sujet qui ne devient concret que sur les gros sites, justement parce qu'on ne le voit que là. Quant aux ressources, c'est le complément terrain de ce que Google perçoit réellement d'un site construit en JavaScript : le crawler dit ce qui devrait être chargé, les logs disent ce qui l'a été.
Avec quoi traiter tout ça
Pour un petit site, quelques commandes suffisent. Un grep pour isoler les lignes Googlebot, un awk pour extraire l'URL et le code, un sort | uniq -c pour compter, et vous avez un classement des pages les plus explorées en trente secondes. Ne vous laissez pas impressionner : sur des volumes raisonnables, le terminal fait le travail.
Au-delà, un outil dédié gère le parsing des formats, la déduplication et le croisement avec un export de crawl. Le Log File Analyser de Screaming Frog est la référence côté payant abordable. Les tableurs atteignent leurs limites vite : mieux vaut basculer sur Python avec pandas.
Le vrai gain n'est pas dans l'outil, il est dans le croisement : logs, export de crawl et données Search Console dans le même tableau, avec l'URL comme clé commune. C'est là que les pages « explorées, actuellement non indexées » deviennent une liste actionnable et non une statistique frustrante.
Les erreurs d'interprétation classiques
La période trop courte, d'abord. Trois jours de logs ne prouvent rien : Google n'explore pas de façon uniforme, il y a des vagues. Comptez plusieurs semaines avant de conclure quoi que ce soit sur une fréquence.
Ensuite, confondre exploration et indexation. Une page très visitée par Googlebot n'est pas forcément indexée, et une page indexée depuis longtemps peut n'être revisitée que rarement. Deux mécaniques distinctes, et les journaux ne renseignent que la première.
Enfin, plus insidieux : une baisse de la fréquence d'exploration n'est pas toujours une mauvaise nouvelle. Si vous venez de nettoyer trois mille URL parasites, la courbe descend, et c'est exactement ce que vous vouliez. Regardez la répartition, pas le total. C'est aussi pour ça qu'on repasse derrière ses réglages après coup, comme dans notre guide pour piloter l'exploration de son site via le fichier robots.txt et le sitemap XML.