Fichiers de log (Log Analysis)
Glossaire – Définition
Les fichiers de log (ou journaux de serveur) sont des fichiers texte générés automatiquement par le serveur web qui enregistrent chaque requête reçue, en indiquant l’adresse IP du visiteur, la date et l’heure, l’URL demandée, le code de réponse HTTP et l’agent utilisateur.
Google Analytics mesure ce que font les utilisateurs humains. Les fichiers de log mesurent ce que font les robots. Ce sont deux sources de données différentes, et la confusion entre les deux est l’une des raisons pour lesquelles l’analyse de logs reste sous-utilisée en SEO, même sur des sites où elle serait particulièrement utile.
Chaque fois que Googlebot visite une page, le serveur écrit une ligne dans le fichier de log. Cette ligne contient l’URL crawlée, le code HTTP retourné (200, 301, 404…) et l’horodatage. En agrégeant ces données sur une période donnée, on obtient une carte précise du crawl : quelles pages Google visite, à quelle fréquence, et lesquelles il ignore.
L’analyse de logs est l’outil de référence pour diagnostiquer les problèmes de budget de crawl sur les sites de grande taille. Des consultants SEO comme Bastian Grimm ou Frederic Dubut (Microsoft Bing, ex-Orange) ont documenté des cas où des milliers de pages inutiles absorbaient la majorité du budget de crawl disponible, laissant des pages commerciales importantes peu ou jamais visitées par les robots.
Pour bien comprendre :
- Ce qu’on trouve dans un fichier de log et comment le lire
- Budget de crawl : pourquoi les logs le révèlent mieux que Search Console
- Comment accéder à ses logs et les analyser
- Les 5 anomalies de crawl détectables par l’analyse de logs
- L’avis de l’expert B-Strong
- Questions fréquentes
Ce qu’on trouve dans un fichier de log et comment le lire
Un fichier de log Apache ou Nginx enregistre une ligne par requête. Chaque ligne suit le format Combined Log Format et contient six informations exploitables en SEO : l’IP du client, la date, la méthode HTTP, l’URL, le code de réponse et l’user agent. Pour Googlebot, l’user agent contient la chaîne « Googlebot ».
Une ligne typique ressemble à :
66.249.66.1 - - [12/Jul/2026:06:14:22 +0200] "GET /blog/article-seo/ HTTP/1.1" 200 4521 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"Ce qu’on lit dans cette ligne :
- 66.249.66.1 : l’IP de Googlebot (Google publie la liste de ses plages d’IP pour vérification).
- GET /blog/article-seo/ : l’URL crawlée et la méthode HTTP.
- 200 : le code de réponse. Un 200 signifie que la page a été servie normalement. Un 404 signifie que Googlebot a tenté de crawler une page inexistante.
- 4521 : la taille de la réponse en octets. Des pages anormalement légères (quelques centaines d’octets) peuvent indiquer des pages quasi-vides.
- Googlebot/2.1 : l’agent utilisateur. Googlebot existe en deux variantes : Googlebot (crawler principal) et Googlebot-Image, Googlebot-Video pour les médias.
Les fichiers de log grossissent vite : un site avec 100 000 visites par jour peut générer plusieurs gigaoctets de logs par mois. L’analyse brute dans un éditeur de texte n’est pas réaliste au-delà de quelques milliers de lignes. Des outils spécialisés sont nécessaires.
Budget de crawl : pourquoi les logs le révèlent mieux que Search Console
Google Search Console affiche les pages indexées et les erreurs de couverture, mais pas la fréquence à laquelle Googlebot visite chaque URL ni le temps qu’il passe à crawler des ressources inutiles. Les logs donnent cette information directement, URL par URL, avec les timestamps.
Le budget de crawl est la quantité de pages que Googlebot est prêt à explorer sur un site dans un laps de temps donné. Ce budget dépend de deux facteurs : la popularité du site (ses backlinks, son autorité) et sa « crawl health » (vitesse de réponse du serveur, ratio de pages retournant une erreur). Google l’a formalisé dans une documentation publiée en 2017, mise à jour depuis.
Sur un site e-commerce de 50 000 produits, l’analyse de logs révèle souvent des patterns préoccupants :
- Pages de facettes crawlées massivement : les filtres (/couleur-rouge, /taille-M, /marque-X) génèrent des milliers d’URL souvent non indexables mais très crawlées. Sur certains sites, elles représentent 60 à 80% des visites de Googlebot.
- Pages en erreur 404 encore crawlées : après une migration ou une suppression de produit, les anciens URLs continuent d’être crawlés pendant des mois si les redirections ou le robots.txt ne les bloquent pas.
- Pages stratégiques peu crawlées : des fiches produits récentes ou des articles de blog publiés depuis plusieurs semaines qui n’ont reçu aucune visite de Googlebot.
- Ressources statiques consommant du budget : images, CSS, JS parfois crawlés par Googlebot sans bénéfice SEO réel.
Comment accéder à ses logs et les analyser
L’accès aux fichiers de log dépend du type d’hébergement. Sur un serveur dédié ou VPS, ils sont directement disponibles dans /var/log/apache2/ ou /var/log/nginx/. Sur un hébergement mutualisé, ils sont souvent accessibles depuis le panneau de contrôle (cPanel, Plesk). Sur les hébergements managés ou les CDN, les logs peuvent être désactivés par défaut ou nécessiter une activation manuelle.
Pour analyser les logs, quatre approches selon le volume et le budget :
- Screaming Frog Log File Analyser : outil desktop de Screaming Frog (gratuit, sans limite de lignes). Import direct des fichiers de log, filtrage par user agent, visualisation des URLs les plus crawlées et des codes de réponse. Bonne option pour les audits ponctuels sur des sites de taille moyenne.
- Botify : plateforme SaaS spécialisée en log analysis SEO. Corrèle les données de crawl avec les données d’indexation et de trafic organique. Utilisé par les grandes équipes SEO sur des sites de plusieurs millions de pages. Coût élevé.
- Semrush Log File Analyzer : fonctionnalité intégrée à Semrush depuis 2020. Import de fichiers de log jusqu’à 1 Go. Adapté pour des audits réguliers sans outils dédiés.
- Python + Pandas : pour les équipes techniques, analyser les logs avec un script Python (bibliothèque Pandas) offre une flexibilité totale. Filtrage par user agent, agrégation par URL, export Excel. Solution gratuite mais qui demande des compétences en data.
Les 5 anomalies de crawl détectables par l’analyse de logs
Ces anomalies ne sont pas visibles dans Google Search Console. Elles n’apparaissent que dans les logs. Les détecter tôt évite de gaspiller le budget de crawl pendant des mois sur des ressources sans valeur SEO.
| Anomalie | Signe dans les logs | Impact SEO | Correction |
|---|---|---|---|
| Facettes crawlées massivement | Des milliers de variantes d’URL (?couleur=, ?tri=) avec des codes 200 | Budget de crawl dilué sur des pages non indexables | Bloquer via robots.txt ou paramètres dans Search Console |
| Pages en 404 encore visitées | URLs supprimées avec codes 404 répétés sur plusieurs semaines | Gaspillage de crawl sur des ressources inexistantes | Redirection 301 vers la page la plus pertinente ou robots.txt |
| Pages stratégiques jamais crawlées | Absence totale de l’URL dans les logs sur 30 jours | Pages potentiellement non indexées faute de crawl | Améliorer le maillage interne, soumettre via Search Console |
| Crawl concentré sur quelques URLs | Top 10 des URLs = 70% des visites de Googlebot | Pages profondes rarement explorées | Revoir l’architecture, renforcer les liens internes vers les pages enfouies |
| Faux Googlebot dans les logs | User agent « Googlebot » mais IP hors plages officielles Google | Scrapers consommant des ressources serveur | Vérifier les IPs via le DNS inverse et bloquer les scrapers en .htaccess |
L’avis de l’expert B-Strong
J’analyse des fichiers de log depuis 2001. Ce n’est pas l’exercice SEO le plus glamour, mais c’est souvent celui qui révèle les vrais problèmes, ceux que les autres outils ne voient pas.
Sur un client retail avec 80 000 références produits, les logs m’ont montré que Googlebot passait 71% de son budget de crawl sur des pages de filtres et de tri que personne n’avait pensé à bloquer. Des centaines de fiches produits récentes attendaient leur premier crawl depuis des semaines. La correction a pris deux jours : quelques lignes dans robots.txt et une règle dans le sitemap. Trois semaines plus tard, l’indexation des nouvelles fiches avait accéléré.
Mon conseil : si votre site dépasse 5 000 pages, planifiez une analyse de logs au moins une fois par trimestre. Screaming Frog Log File Analyser suffit pour la plupart des cas. Pour les sites au-dessus de 500 000 pages, Botify ou un pipeline Python custom deviennent nécessaires. L’accès aux logs bruts est la première chose que je demande lors d’un audit technique.
Ce qu’on nous demande souvent
Quelle est la différence entre les logs serveur et Google Search Console ?
Search Console rapporte ce que Google a décidé d’indexer ou non, avec les erreurs qu’il a rencontrées. Les logs serveur enregistrent chaque requête reçue, y compris celles des bots, des scrapers et des outils de monitoring. Pour le SEO, les logs donnent une vision du crawl beaucoup plus granulaire : fréquence de visite par URL, ratio 200/404 vu par Googlebot, pages jamais crawlées. Search Console dit « cette page n’est pas indexée » ; les logs disent « cette page n’a pas été crawlée depuis 45 jours, voilà pourquoi ».
Mon hébergeur ne donne pas accès aux logs. Que faire ?
Certains hébergements mutualisés n’exposent pas les logs par défaut. Plusieurs alternatives : demander explicitement à l’hébergeur l’activation des logs d’accès (souvent possible sur demande), utiliser un CDN comme Cloudflare qui génère ses propres logs de requêtes accessibles via l’API, ou implémenter un tag JavaScript qui enregistre les visites robots dans Google Analytics (moins précis mais possible). Sur les hébergements managés comme WP Engine ou Kinsta, les logs sont accessibles depuis le tableau de bord.
Comment savoir si c’est vraiment Googlebot dans mes logs et pas un imposteur ?
Google publie ses plages d’adresses IP officielles. La méthode de vérification recommandée par Google est le DNS inverse : effectuez un reverse DNS sur l’adresse IP (commande host sur Linux/Mac), vérifiez que le résultat contient « googlebot.com » ou « google.com », puis faites un DNS direct sur ce nom pour confirmer que l’IP correspond. Les scrapers qui usurpent l’user agent Googlebot ne peuvent pas falsifier ce DNS inverse. Screaming Frog Log File Analyser intègre cette vérification automatiquement.