Analyse de logs : voir ce que Googlebot fait vraiment sur votre site

Search Console indique combien de pages ont été explorées. Les logs indiquent lesquelles, à quelle fréquence, et ce que le serveur a répondu. Sur un site de plus de quelques milliers d'URL, l'écart entre les deux est là où se cachent les problèmes.

Ce que contient une ligne de log

Chaque requête reçue par le serveur produit une ligne : adresse IP, date et heure, méthode et URL demandée, code HTTP renvoyé, taille de la réponse, référent, agent déclaré.

Pour le SEO, quatre champs suffisent : l'URL, la date, le code de réponse et l'agent. Le reste sert au diagnostic technique.

Les fichiers se récupèrent chez l'hébergeur, dans le panneau d'administration ou par accès SSH. Sur un serveur Plesk ou cPanel, ils sont accessibles depuis l'interface. Un mois de données suffit pour commencer, une semaine pour un petit site.

La première chose à faire : vérifier les agents

Un agent déclaré ne prouve rien. N'importe quel outil peut se présenter comme Googlebot, et une bonne partie des visites qui s'en réclament n'en sont pas.

La vérification se fait par résolution DNS inverse : l'adresse IP doit résoudre vers un nom de domaine googlebot.com ou google.com, et la résolution directe de ce nom doit redonner l'adresse de départ. Google publie aussi la liste de ses plages d'adresses.

Sans ce filtre, toutes les statistiques qui suivent sont fausses.

Les trois diagnostics qui justifient l'exercice

Le budget d'exploration gaspillé. Comptez les requêtes par type d'URL. Il est courant de découvrir que 40 % des visites de Googlebot portent sur des pages de filtres, des paramètres de tri ou des résultats de recherche interne, pendant que des pages utiles restent inexplorées.

Les pages jamais visitées. Comparez la liste des URL de votre sitemap avec celles présentes dans les logs. Les absentes ne sont pas mal classées : elles ne sont pas vues. Les causes sont presque toujours les mêmes, un maillage interne trop pauvre ou une profondeur excessive.

Les erreurs invisibles ailleurs. Les codes 404 et 500 servis aux robots n'apparaissent pas toujours dans Search Console, surtout sur des URL générées dynamiquement. Les logs les montrent tous.

Ce que les logs révèlent sur les moteurs de réponse

Depuis 2023, les logs contiennent aussi les visites de GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot et Google-Extended.

Deux informations en sortent. Quels robots viennent réellement, ce qui permet de vérifier que votre fichier robots.txt fait ce que vous croyez, sujet traité dans notre guide sur le blocage de GPTBot. Et quelles pages ils demandent, ce qui donne une idée des contenus qu'ils jugent pertinents sur votre domaine. Le rôle de chaque agent est détaillé dans notre liste des robots d'IA.

C'est aujourd'hui la seule mesure directe de l'exposition d'un site aux moteurs de réponse. Tout le reste, y compris les outils de suivi de citation, mesure la sortie, pas l'entrée.

Par quoi commencer sans y passer une semaine

Récupérez une semaine de logs. Filtrez sur les agents des robots après vérification. Comptez les requêtes par répertoire, puis par code de réponse.

Trois chiffres suffisent à décider s'il faut aller plus loin : la part de requêtes qui aboutissent à un code autre que 200, la part qui porte sur des URL à paramètres, et le nombre d'URL du sitemap jamais demandées.

Si ces trois chiffres sont bons, votre exploration se porte bien et le problème est ailleurs. S'ils sont mauvais, vous venez de trouver un chantier qui rapportera plus que trois mois de production de contenu.

Ce que les logs ne disent pas

Trois limites, à connaître avant de bâtir un diagnostic entier dessus.

Ils ne disent rien du classement. Une page explorée quotidiennement peut rester en trentième position. L'exploration est une condition, pas une performance. Les logs répondent à « est-ce vu », pas à « est-ce bien vu ».

Ils ne montrent pas le rendu. Une page servie en code 200 avec un HTML quasi vide, dont le contenu arrive ensuite par JavaScript, apparaît dans les logs exactement comme une page complète. Le contrôle du rendu se fait ailleurs, avec l'outil d'inspection d'URL de Search Console.

Ils ne couvrent pas toujours tout le trafic. Un CDN ou un cache placé devant le serveur absorbe une partie des requêtes, qui n'apparaissent jamais dans les logs d'origine. Sur une architecture de ce type, les journaux à analyser sont ceux du CDN.

Le maillage interne, réponse à la plupart des constats

Sur les sites où l'analyse est menée pour la première fois, le même diagnostic revient : des pages du sitemap jamais demandées, et un volume de requêtes concentré sur quelques répertoires.

La cause est rarement technique. C'est presque toujours un maillage interne pauvre, qui laisse des pages accessibles seulement depuis un plan de site ou une pagination profonde. Un robot suit des liens ; une page sans lien entrant interne n'existe pratiquement pas pour lui.

La correction est éditoriale plus que technique : lier depuis les pages qui reçoivent déjà des visites vers celles qui n'en reçoivent pas, avec des ancres explicites. C'est aussi ce qui améliore la lecture, et le seul chantier de cette liste qui profite en même temps aux lecteurs et aux robots.