Les logs serveur sont des fichiers générés automatiquement par le serveur web (Apache, Nginx, IIS) qui enregistrent chronologiquement chaque requête HTTP reçue — qu’elle provienne d’un utilisateur humain, d’un bot de moteur de recherche ou de tout autre agent. En SEO, l’analyse des logs est la seule source de vérité absolue sur le comportement réel de Googlebot sur un site, sans échantillonnage ni intermédiaire.
• Les logs serveur enregistrent chaque requête HTTP.
• Googlebot laisse des traces dans les logs serveur.
• L’analyse de logs révèle le comportement réel du crawler.
• Le budget crawl se mesure précisément via les logs serveur.
• Les codes de réponse HTTP sont documentés dans les logs serveur.
• Les logs serveur complètent les données de Google Search Console.
Structure d’une ligne de log
Chaque entrée de log suit un format standardisé, le plus courant étant le Combined Log Format d’Apache :
66.249.66.1 – – [17/02/2026:14:32:05 +0100] « GET /page-exemple/ HTTP/1.1 » 200 15234 « – » « Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) »
Cette ligne contient : l’adresse IP du client (ici une IP Google), la date et heure de la requête, la méthode HTTP et l’URL demandée, le code de réponse HTTP (200, 301, 404, 500…), la taille de la réponse en octets, et le User-Agent qui identifie le client (Googlebot, Bingbot, navigateur utilisateur, etc.).
Informations exploitables en SEO
Fréquence de crawl par URL — Identifier quelles pages Googlebot visite le plus souvent et lesquelles sont ignorées. Une page stratégique rarement crawlée signale un problème de maillage interne, de profondeur ou de priorité perçue par Google.
Codes de réponse HTTP — Détecter en temps réel les erreurs 4xx et 5xx servies à Googlebot, les chaînes de redirections 301/302, les soft 404 (pages qui renvoient un code 200 mais affichent un contenu vide ou d’erreur), et les réponses lentes.
Budget crawl réel — Calculer précisément le nombre de requêtes Googlebot par jour, par section du site, par type de page. Identifier le gaspillage de budget crawl sur des pages sans valeur SEO (pages de paramètres, filtres à facettes, pages de pagination profondes, ressources CSS/JS).
Pages orphelines crawlées — Croiser les URLs présentes dans les logs avec celles du sitemap et du crawl technique pour repérer les pages que Googlebot découvre via des sources externes mais qui ne sont pas liées en interne.
Temps de réponse serveur (TTFB) — Mesurer le temps de réponse réel du serveur pour chaque requête Googlebot. Un TTFB élevé impacte directement le crawl rate et peut amener Google à réduire la fréquence d’exploration.
Identification des bots — Distinguer les vrais crawlers (vérifiables par reverse DNS) des faux bots qui usurpent le User-Agent de Googlebot, souvent à des fins de scraping ou d’attaque.
Analyse de logs : méthodologie
L’analyse brute des logs est impraticable manuellement sur des sites de volume — un site e-commerce moyen génère plusieurs dizaines de Go de logs par mois. Le workflow standard consiste à filtrer les logs pour isoler uniquement les requêtes Googlebot (et vérifier l’authenticité via reverse DNS sur les IP 66.249.x.x et 64.233.x.x), puis à agréger les données par URL, code de réponse, fréquence et temporalité. Le croisement avec les données de crawl technique (Screaming Frog) et d’indexation (GSC) produit une vision complète du cycle crawl → indexation.
Distinction avec le Tracking JavaScript
Contrairement aux outils d’analytics (Google Analytics) qui dépendent de l’exécution d’un script côté navigateur (client-side), les logs serveurs capturent l’activité côté serveur (server-side). Puisque la majorité des robots d’exploration n’exécutent pas systématiquement le JavaScript lors du crawl initial, les logs sont le seul moyen de monitorer leur passage.
Formats de logs courants
- Apache → access.log (Combined Log Format ou Custom Log Format)
- Nginx → access.log (format configurable dans nginx.conf)
- IIS → Logs au format W3C dans C:\inetpub\logs\LogFiles
- CDN / WAF → Cloudflare, Sucuri, AWS CloudFront génèrent leurs propres logs qu’il faut récupérer séparément (attention : un CDN peut masquer les requêtes directes au serveur origin)
Outils de diagnostic d’un log
- Screaming Frog Log Analyzer → Outil dédié à l’analyse SEO des logs serveur, avec segmentation par bot, code de réponse, fréquence de crawl, et croisement avec les données de crawl technique
- Oncrawl → Plateforme cloud d’analyse de logs avec dashboards SEO préconstruits et intégration GSC
- ELK Stack (Elasticsearch + Logstash + Kibana) → Solution open source pour l’ingestion, l’indexation et la visualisation de gros volumes de logs en temps réel
- GoAccess → Analyseur de logs en ligne de commande, léger et rapide, utile pour un diagnostic rapide en SSH
- Scripts Python custom → Parsing avec pandas ou re pour des analyses sur mesure, idéal pour les sites volumineux nécessitant un traitement spécifique
- AWStats / Matomo (logs) → Analyseurs classiques mais moins orientés SEO technique
Bonnes pratiques
La rotation des logs doit être configurée pour conserver un historique suffisant (minimum 90 jours, idéalement 6 à 12 mois) sans saturer l’espace disque — logrotate sous Linux est l’outil standard. Les logs doivent être stockés de manière sécurisée car ils contiennent des adresses IP (données personnelles au sens du RGPD). Pour les sites derrière un CDN ou un reverse proxy, il est essentiel de configurer le header X-Forwarded-For pour conserver l’IP réelle du client dans les logs du serveur origin.
Besoin d’un accompagnement ?
Analyser vos logs serveur — identifier le comportement réel de Googlebot, détecter le gaspillage de budget crawl et croiser les données avec la Search Console — demande une méthodologie rigoureuse et des outils adaptés. Notre agence SEO Lyonnaise réalise des audits de logs complets pour optimiser l’exploration de votre site par les moteurs de recherche.
Entités liées (→ définitions dédiées)
→ Crawl · Budget crawl · Googlebot · TTFB · Redirection 301 · Pages orphelines · Maillage interne · Robots.txt · Google Search Console · Rendering · Soft 404. HTTP