Analyse de logs
Ce que les journaux serveur révèlent du passage de Googlebot : outils, seuil de pertinence, lecture d’un fichier réel.
L’analyse de logs SEO (log file analysis) est l’examen des fichiers journaux du serveur pour observer le comportement réel des robots d’exploration. Elle isole les passages de Googlebot et des autres bots parmi les hits enregistres. En SEO, l’analyse de logs revele ce que le crawl simule et la Search Console ne montrent pas : le crawl effectif, page par page.
Comment fonctionne l’analyse de logs ?
L’analyse de logs part du fichier d’accès du serveur (Apache, Nginx ou LiteSpeed), ou chaque requête inscrit une ligne : IP, horodatage, URL appelée, code de réponse HTTP, user-agent et poids. La méthode consiste d’abord à collecter ces lignes sur une période donnée, puis à filtrer les passages des robots des moteurs par leur user-agent (Googlebot, Bingbot, robots IA). Une vérification par DNS inverse ecarte les faux Googlebot. L’analyse de logs segmente ensuite les URL par type de page, mesure la fréquence de crawl par groupe et croise ces données avec un crawl simule et la Search Console. Ce croisement transforme des millions de lignes brutes en priorités d’optimisation actionnables.
Pourquoi l’analyse de logs est importante pour le SEO ?
L’analyse de logs est importante en SEO parce qu’elle est la seule source exhaustive du crawl réellement subi par le serveur. Le rapport Statistiques d’exploration de la Search Console ne conserve que 90 jours de données agrégées, la ou les logs remontent aussi loin que la rétention le permet. L’analyse de logs met ainsi au jour des problèmes invisibles autrement : budget de crawl gaspille sur des paramètres d’URL et des doublons, pages stratégiques sous-crawlées, erreurs 5xx nocturnes qu’un crawl ponctuel de jour ne verra jamais, chaînes de redirection, et pages orphelines connues de Google mais absentes du maillage. Chaque anomalie se traduit en action de priorisation technique.
| Critère | Analyse de logs | Statistiques d’exploration (GSC) |
|---|---|---|
| Exhaustivité | Tous les hits réels du serveur | Données agrégées, exemples d’URL |
| Profondeur historique | Selon la rétention serveur | 90 jours (Google) |
| Détail par URL | Ligne par ligne, URL exacte | Groupes par réponse et type |
| Bots couverts | Tous (Googlebot, Bingbot, IA) | Crawlers Google uniquement |
| Prérequis | Accès serveur + outil d’analyse | Propriété racine verifiee |
Quels outils pour faire une analyse de logs SEO ?
Pour une analyse de logs SEO, les outils dédiés les plus courants sont Screaming Frog Log File Analyser, OnCrawl, Botify et Seolyzer (français). Ils importent les fichiers d’accès, filtrent les user-agents et visualisent la fréquence de crawl par groupe d’URL. Sur des sites a très forte volumétrie, une stack big data comme ELK ou Splunk prend le relais. L’essentiel reste de croiser les logs avec le crawl et la Search Console.
À partir de quelle taille de site l’analyse de logs est-elle utile ?
L’analyse de logs délivre le plus de valeur sur les sites à forte volumétrie : e-commerce à facettes, plateformes générant beaucoup de paramètres d’URL, médias a forte cadence de publication. Google lui-même juge son rapport Statistiques d’exploration superflu sous 1 000 pages. En dessous, l’analyse de logs reste ponctuellement utile pour un cas précis, comme débusquer des erreurs 5xx nocturnes ou une page orpheline qui capte du crawl inutilement.
Exemple concret d’analyse de logs
Une approche faible consiste à ouvrir l’access.log brut dans un tableur : le fichier mélange internautes, bots de monitoring et faux Googlebot, ce qui fausse toute lecture du crawl. Une approche solide isole d’abord les passages de Googlebot, verifie leur legitimite, puis compte les codes de réponse par URL. La commande ci-dessous donne un premier aperçu des URL les plus crawlées et de leurs statuts.
# Isoler les passages Googlebot et compter code HTTP + URL
grep -i "googlebot" access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head -20# Verifier qu'une IP est un vrai Googlebot (DNS inverse puis direct)
host 66.249.66.1Erreur fréquente observée en audit
Cas réel. Sur un site voyage à fort volume, l’analyse de logs a permis de vérifier que Googlebot passait réellement sur des URLs générées par erreur. Le diagnostic a isolé environ 14 000 pages inutiles liées à un mauvais pattern de sous-landings “tout inclus”. Sans les logs serveur, le problème serait resté partiellement masqué par les données agrégées de la Search Console. La correction a porté sur le modèle d’URL, le maillage interne et la consolidation des pages canoniques.
Faire expliquer ce terme par une IA
Ouvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
Sources
- 1Aide Google Search Console, Rapport Statistiques d’exploration
- 2Google Search Central, nouveau rapport Statistiques d’exploration · novembre 2020
- 3Google for Developers, Vérifier les requêtes des robots de Google
Trois idées reçues sur l’analyse de logs
L’analyse de logs passe pour un exercice réservé aux gros sites, et se confond avec les rapports de la Search Console.
Les Statistiques d’exploration remplacent les logs. Le rapport agrège sur 90 jours, sans détail URL par URL. Les logs conservent chaque requête reçue par le serveur.
L’analyse de logs ne sert qu’aux très gros sites. Elle révèle les zones de gaspillage à toute taille. Seul le rapport entre coût et bénéfice monte avec le volume.
Tout hit déclaré Googlebot vient de Google. Le User-Agent se falsifie en une ligne de code. Le reverse DNS écarte les agents usurpés avant toute conclusion.
Questions fréquentes
Combien de temps de logs faut-il conserver ?−
Trente jours suffisent pour un premier diagnostic. Une analyse saisonnière ou une refonte demande six mois à un an. Le rapport Statistiques sur l’exploration de la Search Console ne remonte que 90 jours, ce qui rend l’archivage utile au-delà.
Les logs d’un hébergement mutualisé sont-ils exploitables ?+
Oui, la plupart des hébergeurs livrent des logs au format Combined. Le fichier arrive compressé, par jour, depuis le panneau d’administration ou en FTP. Un CDN placé devant le serveur masque une partie du trafic : ses propres logs deviennent alors nécessaires.
Faut-il vérifier l’authenticité des robots dans les logs ?+
Oui, le User-Agent se falsifie en une ligne de code. Google recommande un reverse DNS sur l’adresse IP pour confirmer un vrai Googlebot. Sans cette vérification, une part du trafic déclaré Googlebot fausse toute l’analyse.
