Analyse de logs SEO : ce que Google explore vraiment

Chaque outil SEO habituel — Search Console, votre suite d'analytics, un crawler comme Screaming Frog — vous donne une estimation de ce que fait un moteur de recherche sur votre site. L'analyse de logs, elle, vous donne le fait brut : la ligne exacte que votre serveur a écrite au moment précis où Googlebot, Bingbot ou n'importe quel autre robot a demandé une page. Pas d'échantillonnage, pas d'agrégation sur seize mois, pas de délai de plusieurs jours avant que la donnée apparaisse dans un rapport quelconque. C'est le seul enregistrement de première main de ce qui s'est réellement passé entre un crawler et votre serveur — tout le reste n'est qu'une reconstruction indirecte, aussi bonne soit-elle.

Un fichier de logs brut ressemble à du bruit au premier regard : des dizaines de milliers de lignes qui se ressemblent toutes. Mais une fois qu'on sait quoi y chercher, il répond à des questions qu'aucune autre source ne peut trancher avec la même précision — quelles pages sont vraiment explorées, où part le budget de crawl, et si ce qui prétend être Googlebot en est vraiment un.

Ce que contient une ligne de log, et pourquoi c'est la seule vérité disponible

Une ligne de log serveur classique, au format combiné utilisé par Apache et repris tel quel par la plupart des configurations Nginx, ressemble à ceci une fois décomposée : l'adresse IP du client qui a fait la requête, l'horodatage exact avec le fuseau horaire, la méthode HTTP et l'URL demandée, le code de statut renvoyé, le nombre d'octets transférés, l'en-tête referer (souvent vide pour un robot), et enfin la chaîne user-agent que le client a déclarée. Rien de plus, mais rien de moins : c'est l'échange complet, tel qu'il s'est produit, sans aucune interprétation entre les deux.

C'est ce qui rend cette source irremplaçable face aux deux alternatives habituelles. Search Console ne montre que des statistiques de crawl agrégées à l'échelle du site, avec un historique limité et un décalage de plusieurs jours — impossible d'y retrouver l'historique complet d'une URL précise sur la période de votre choix. Votre outil d'analytics, lui, ne voit quasiment aucun robot : il repose sur l'exécution d'un script JavaScript dans un navigateur, et l'immense majorité des crawlers ne chargent jamais ce script. Un Googlebot qui visite une page cent fois dans le mois sera invisible dans Google Analytics et n'existera, pour vous, que dans les logs.

• IP du client — qui a fait la requête (à vérifier, voir plus bas)
• Horodatage — jusqu'à la seconde, avec fuseau horaire
• Méthode + URL demandée — le chemin exact, paramètres compris
• Code de statut — 200, 301, 404, 500… ce qui a réellement été renvoyé
• Taille de la réponse — utile pour repérer une page vide ou cassée
• User-agent déclaré — une simple chaîne de caractères, donc à ne jamais prendre pour argent comptant

Où trouver ses logs, et sous quel format vous allez les rencontrer

Sur un hébergement mutualisé classique, les logs bruts sont en général téléchargeables depuis le panneau de contrôle (la fonction « Raw Access Logs » d'un cPanel, par exemple), mais ils sont souvent purgés au bout de quelques jours seulement — il faut les récupérer et les archiver soi-même avant qu'ils disparaissent, pas les découvrir au moment où on en a besoin. Sur un serveur dédié ou un VPS avec accès SSH, ils vivent typiquement dans /var/log/apache2/ ou /var/log/nginx/, tournés par logrotate selon une fréquence et une rétention qui dépendent de la configuration du serveur — si vous prévoyez une analyse régulière, demandez à ce que la rétention soit allongée avant d'en avoir besoin, pas après.

Le piège le plus fréquent concerne les sites derrière un CDN comme Cloudflare, Fastly ou Akamai : une bonne partie des requêtes, y compris celles de Googlebot, sont servies directement depuis le cache en périphérie et n'atteignent jamais votre serveur d'origine. Les logs d'origine seuls donnent alors une image tronquée du crawl réel. Il faut activer et exporter les logs du CDN lui-même — une fonctionnalité qui, chez la plupart des fournisseurs, n'est disponible que sur les offres payantes ou entreprise.

• Common Log Format (CLF) — le format Apache minimal, sans referer ni user-agent
• Combined Log Format — le même, avec referer et user-agent ajoutés ; le plus courant
• W3C Extended Log Format — utilisé par IIS, colonnes déclarées dans un en-tête, ordre des champs différent
• Logs JSON de CDN — un objet par requête, plus verbeux mais bien plus simple à traiter par script qu'un texte à largeur fixe

Vérifier qu'un Googlebot est un vrai Googlebot (l'étape que presque tout le monde saute)

Le user-agent d'une requête HTTP n'est qu'une chaîne de texte que le client envoie de son plein gré ; rien n'empêche un script écrit en cinq minutes d'annoncer « Googlebot » via curl. Beaucoup d'analyses de logs s'arrêtent pourtant à un simple filtre texte sur ce champ, ce qui revient à croire n'importe qui sur parole. C'est un problème pour deux raisons distinctes. D'abord côté sécurité : de nombreux pare-feu applicatifs et règles anti-bot font une exception pour tout ce qui prétend être Googlebot, précisément pour ne jamais bloquer le vrai — un scraper ou un bot malveillant qui usurpe ce user-agent passe donc sans encombre. Ensuite côté analyse : si vous mesurez la fréquence de crawl, la couverture ou les tendances d'erreurs sans filtrer les imposteurs, vos chiffres sont pollués par un volume de faux trafic dont vous ignorez l'ampleur.

La vérification fiable repose sur le DNS, en deux temps. On effectue d'abord une résolution DNS inverse sur l'adresse IP de la requête : un vrai robot Google renvoie un nom d'hôte se terminant par googlebot.com ou google.com. On effectue ensuite la résolution directe de ce nom d'hôte obtenu, et on vérifie qu'elle pointe bien vers la même adresse IP de départ — ce double contrôle, dit forward-confirmed reverse DNS, empêche quelqu'un de fabriquer un faux enregistrement inverse pour se faire passer pour Google. C'est la méthode que Google documente lui-même comme procédure officielle de vérification. Bing propose l'équivalent pour Bingbot, avec un nom d'hôte se terminant par search.msn.com et un outil de vérification intégré à Bing Webmaster Tools.

Pour une analyse en volume, une alternative plus rapide consiste à comparer les IP observées à la liste des plages d'adresses que Google publie officiellement — moins rigoureux qu'une double résolution DNS ligne par ligne, mais largement suffisant si la liste est tenue à jour, et surtout beaucoup plus rapide à appliquer sur un mois entier de logs. Dans les deux cas, l'opération se fait une fois par IP distincte, pas une fois par ligne : le nombre d'adresses différentes utilisées par les crawlers légitimes sur un site normal reste, sur un mois, une liste courte et gérable.

Ce que les logs révèlent, et que rien d'autre ne montre

Une fois le trafic robot isolé et vérifié, les logs répondent à des questions très concrètes qu'aucun rapport agrégé ne peut trancher URL par URL :

• Quelles URLs sont réellement explorées, et à quelle fréquence — en croisant le décompte de hits par chemin avec votre inventaire de pages réel, on trouve souvent des pages secondaires visitées quotidiennement pendant que des pages stratégiques n'ont pas reçu un seul passage depuis des semaines.
• Le budget de crawl absorbé par des URLs à paramètres ou des pages à facettes — sur un site e-commerce, les variantes de tri, de filtre ou les identifiants de session peuvent générer un volume de hits qui écrase largement celui des pages produits elles-mêmes ; les logs sont la seule façon de le quantifier réellement, pas de le supposer.
• Les pages orphelines explorées sans être liées nulle part — une URL que le robot continue de visiter alors qu'elle n'apparaît plus dans votre maillage interne ni dans votre sitemap actuel révèle presque toujours un backlink externe oublié, un ancien sitemap encore soumis, ou une chaîne de redirections qui y mène encore.
• Des motifs d'erreurs situés dans le temps — pas seulement la liste des codes renvoyés, mais leur répartition dans le temps : un pic récurrent de 500 toujours à la même heure qui trahit une tâche de sauvegarde mal placée, ou des 404 qui continuent d'arriver des mois après une migration sur un motif d'URL précis, signe qu'un vieux flux ou sitemap est toujours actif quelque part en dehors de votre contrôle direct.
• Le délai réel entre la publication d'une page et son premier passage de crawler — en comparant l'horodatage de publication côté CMS à l'horodatage du premier hit vérifié dans les logs pour cette même URL, on obtient une mesure de fraîcheur de crawl concrète, propre à votre site, plutôt qu'une hypothèse générale sur la rapidité de découverte de Google.

Une première analyse, pas à pas, sur un site de taille modeste

L'exercice n'a pas besoin d'être sophistiqué pour être utile. Sur un site de quelques centaines à quelques milliers de pages, une première passe tient en une poignée d'étapes, sans outillage complexe :

• Récupérer au moins 30 jours de logs bruts, avant qu'ils ne soient purgés par la rotation automatique.
• Isoler les lignes dont le user-agent déclaré prétend appartenir à un moteur de recherche, puis ne garder que les IP vérifiées selon la méthode décrite plus haut.
• Agréger les hits confirmés par chemin d'URL et trier par volume décroissant : quelles sont les vingt pages les plus visitées par le robot ?
• Comparer ce classement à l'inventaire réel du site — sitemap ou export CMS — pour repérer les pages importantes totalement absentes, et les pages sans valeur qui reçoivent un volume disproportionné.
• Regarder la répartition des codes de statut sur toute la période : quelle proportion des hits confirmés tombe sur des 404, des redirections ou des erreurs serveur plutôt que sur des 200 ?
• Repérer les motifs de paramètres d'URL qui dominent le volume, pour voir si le crawl part majoritairement sur du contenu réel ou sur des variantes techniques.

Pour un site de cette taille, un traitement en ligne de commande avec des outils texte classiques (grep, awk, sort) suffit largement à répondre à ces questions sans écrire de véritable programme. Pour qui préfère une interface visuelle plutôt qu'un terminal, des analyseurs de logs dédiés existent, comme le Log File Analyser de Screaming Frog, qui fait l'agrégation et le rapprochement avec le sitemap automatiquement.

Quand l'analyse de logs vaut l'effort, et quand elle est disproportionnée

L'analyse de logs vaut le détour dès que la taille ou la structure du site crée une vraie incertitude sur ce que le crawler fait réellement : un catalogue e-commerce avec navigation à facettes et combinaisons de paramètres, un site de plusieurs milliers d'URLs, une migration ou une refonte où l'on a besoin de confirmer ce que Google a effectivement vu plutôt que ce qui est censé être en ligne, un rapport de statistiques de crawl dans Search Console qui montre un volume de requêtes élevé sans que l'indexation suive au même rythme, ou des pics de charge serveur qu'on soupçonne d'être liés à un robot. Dans tous ces cas, la question posée — où va réellement le crawl, et pourquoi — n'a pas d'autre réponse fiable que les logs eux-mêmes.

À l'inverse, pour un site vitrine d'une vingtaine de pages ou un blog de quelques dizaines d'articles, sans navigation à paramètres et sans problème d'indexation déjà signalé dans Search Console, l'effort de récupération des logs, de vérification des IP et de construction du rapport de rapprochement coûte largement plus de temps que ce que l'analyse rapporte. Le rapport Indexation des pages et les statistiques de crawl de Search Console suffisent à cette échelle. Une règle simple : si votre nombre d'URLs indexables se compte en centaines basses et que rien dans Search Console ne signale de souci de crawl ou d'indexation, l'analyse de logs est un diagnostic à garder en réserve, pas une priorité du moment.