Analyse des fichiers de logs serveur pour le SEO : guide complet
Comment analyser les logs de crawl, préserver le périmètre et distinguer l'activité des bots des affirmations sur le positionnement ou le trafic lorsque vous priorisez les corrections techniques.
Pourquoi analyser les fichiers de logs
Google Search Console n'affiche que des données agrégées, avec un délai de trois jours. Screaming Frog simule un navigateur, et non Googlebot. Les fichiers de logs du serveur web sont la seule source qui enregistre chaque requête réelle d'un robot de moteur de recherche : l'horodatage précis, l'URL, le code de statut de la réponse et l'adresse IP du crawler.
L'analyse des logs répond à des questions qu'aucun autre outil ne permet de résoudre : quelles pages Googlebot explore chaque heure et lesquelles il n'a pas visitées depuis des mois ; où le crawler rencontre des 404 et des 500 ; s'il existe des boucles de redirection infinies ; si le budget est gaspillé sur des doublons paramétriques ou sur des pages derrière un mur de connexion. Ces données sont exactement ce qu'il faut pour piloter en connaissance de cause la gestion du budget de crawl.
Ce que l'analyse des logs apporte
Requêtes réelles
Chaque requête HTTP d'un crawler est enregistrée dans le fichier de logs : ni échantillonnage, ni délai d'agrégation
Précision temporelle
Des horodatages à la seconde permettent de suivre les schémas de crawl par jour de la semaine et par heure
Plusieurs bots, une seule source
Googlebot, Bingbot, Yandex et les autres : tous les crawlers dans un seul fichier, comparables sur une même vue
Délai des données
Les logs sont disponibles immédiatement : inutile d'attendre un nouveau crawl ou la mise à jour du rapport GSC
Comment accéder aux fichiers de logs
Le chemin vers vos logs dépend du serveur web et de l'hébergeur. Sur la plupart des VPS et des serveurs dédiés, les fichiers de logs sont accessibles directement en SSH. Pour l'analyse, il faut généralement disposer des access logs des 30 à 90 derniers jours : cette période est assez longue pour révéler les schémas saisonniers, tout en restant à jour.
| Serveur / plateforme | Chemin par défaut des logs | Remarques |
|---|---|---|
| Nginx | /var/log/nginx/access.log | Rotation par logrotate. Archives : access.log.1, access.log.2.gz, etc. |
| Apache | /var/log/apache2/access.log (Debian/Ubuntu) ou /var/log/httpd/access_log (RHEL) | Le format peut être CLF ou Combined : vérifiez la directive LogFormat |
| cPanel / WHM | ~/access-logs/<domaine> ou Gestionnaire de fichiers → Logs | Souvent découpés par domaine. Raw Access disponible dans l'interface cPanel |
| Cloudflare Workers / Enterprise | Logpush API → S3, R2, GCS | Réservé au forfait Enterprise. Pour Free/Pro : Workers Analytics Engine |
| AWS CloudFront | Bucket S3 configuré dans Paramètres de distribution → Logging | Journaux générés toutes les 5 à 10 minutes, compressés en gzip |
| Google Cloud / GCS | Cloud Logging → export vers BigQuery ou GCS | Idéal pour les gros volumes : requêtes SQL directement dans BigQuery |
# Nginx: view the last 1000 lines of the access log
tail -n 1000 /var/log/nginx/access.log
# Size of the current log file
du -sh /var/log/nginx/access.log
# Decompress and merge rotated logs
zcat /var/log/nginx/access.log.*.gz | cat - /var/log/nginx/access.log > all_access.log
# Line count (≈ number of requests) in the merged file
wc -l all_access.logrotate 30 dans /etc/logrotate.d/nginx à l'avance : un log supprimé ne peut pas être récupéré.Structure d'un enregistrement : format CLF
La plupart des serveurs utilisent par défaut le Combined Log Format (CLF), une version étendue du Common Log Format. Voici les champs utiles à l'analyse SEO.
# Combined Log Format record (Nginx/Apache)
66.249.66.1 - - [19/May/2026:14:32:01 +0000] "GET /blog/seo-guide/ HTTP/1.1" 200 45231 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ └─ User-Agent
│ │ │ │ │ │ │ └───── Referer
│ │ │ │ │ │ └─────────── Bytes sent
│ │ │ │ │ └──────────────── HTTP status
│ │ │ │ └─────────────────────────────────────────── Request
│ │ │ └────────────────────────────────────────────────────────────────────────── Timestamp
│ │ └───────────────────────────────────────────────────────────────────────────── Auth user
│ └─────────────────────────────────────────────────────────────────────────────── Ident
└─────────────────────────────────────────────────────────────────────────────────────────── IP address| Champ | Pertinence SEO | Ce qu'il faut repérer |
|---|---|---|
| Adresse IP | Élevée | Plages IP de Googlebot, Bingbot, Yandex : elles servent à filtrer les vrais crawlers |
| Horodatage | Élevée | Fréquence de crawl, date de la dernière visite de certaines URL |
| Requête (méthode + URL) | Critique | URL crawlées : pages utiles, doublons, paramètres, chemins inexistants |
| Statut HTTP | Critique | 200 (correct), 301/302 (redirections), 404 (liens morts), 500 (erreurs serveur) |
| Octets envoyés | Moyenne | Taille anormalement faible : signe d'une page vide ou d'une réponse factice |
| User-Agent | Critique | Distinguer Googlebot des autres bots et des utilisateurs réels |
Filtrage : isoler les crawlers
Les logs bruts mélangent les requêtes des utilisateurs, les pings de monitoring, les spambots et les crawlers des moteurs de recherche. Pour l'analyse SEO, il faut extraire uniquement les robots des moteurs. Le moyen le plus fiable consiste à filtrer sur la chaîne User-Agent, puis à vérifier l'IP par DNS.
# Extract all Googlebot requests
grep -i 'googlebot' /var/log/nginx/access.log > googlebot.log
# Extract all SEO crawlers
grep -iE '(googlebot|bingbot|yandex|ahrefsbot|semrushbot|mj12bot)' \
/var/log/nginx/access.log > all_bots.log
# Count requests by crawler
grep -oiE '(googlebot|bingbot|yandexbot|ahrefsbot|semrushbot)' \
/var/log/nginx/access.log | sort | uniq -c | sort -rn
# Verify IP via reverse DNS (confirm it's the real Googlebot)
host 66.249.66.1
# Should return: crawl-66-249-66-1.googlebot.com
# Then forward DNS:
host crawl-66-249-66-1.googlebot.com
# Should return the same IP — then it's a legitimate GooglebotGooglebot. Pour un filtrage précis, vérifiez l'IP via un DNS inverse : le vrai Googlebot se résout en *.googlebot.com. Google publie ses plages d'IP officielles via l'API Special IP Addresses.Métriques SEO clés
Une fois le filtrage effectué, passez à l'analyse. Voici six métriques qui apportent le plus d'enseignements pour le moins d'efforts.
Nombre de visites de Googlebot sur une URL donnée pendant la période. Les pages à fort PageRank et mises à jour fréquemment sont crawlées plus souvent. Si une page importante n'a été visitée qu'une seule fois en 30 jours, Google la considère comme de faible valeur.
Objectif : pages clés ≥ une fois tous les 3 joursPart des 4xx et 5xx dans les requêtes de Googlebot. Les 404 gaspillent le budget de crawl. Les 500 signalent des problèmes systémiques. Un taux d'erreur élevé réduit la confiance de Google envers le site.
Référence : 4xx < 3 %, 5xx < 0,5 %Part des requêtes de Googlebot qui aboutissent à un 301 ou un 302. Les redirections consomment du budget et ralentissent la réindexation. Les chaînes de redirections (A → B → C) sont particulièrement néfastes.
Référence : 3xx < 10 % de toutes les requêtes des botsUn même contenu sous plusieurs URL : avec et sans www, avec et sans slash final, avec des paramètres UTM. Chaque variante est crawlée séparément, ce qui constitue une fuite directe du budget de crawl.
Objectif : une seule URL canonique par contenuPages clés (catégories, pages d'atterrissage, nouveaux articles) que Googlebot n'a jamais demandées en 30 jours. Cela indique un problème de maillage interne ou un blocage dans le robots.txt.
Objectif : 0 page importante sans crawl pendant 30 joursPages que Google crawle alors qu'il ne devrait pas : panneaux d'administration, pages de session, environnements de test, doublons paramétriques. Elles gaspillent le budget et présentent parfois un risque de sécurité.
Objectif : 0 URL sensible dans les logs de GooglebotOutils d'analyse
Trois outils couvrent 95 % des tâches d'analyse de logs : la ligne de commande pour les vérifications rapides, une interface spécialisée pour l'analyse approfondie, et Python ou BigQuery pour les gros volumes et l'automatisation.
Bash : analyse rapide sans installation
# Top 20 URLs Googlebot crawls most often
grep -i 'googlebot' access.log \
| awk '{print $7}' \
| sort | uniq -c | sort -rn | head -20
# Response status distribution for Googlebot
grep -i 'googlebot' access.log \
| awk '{print $9}' \
| sort | uniq -c | sort -rn
# URLs returning 404 to Googlebot
grep -i 'googlebot' access.log \
| awk '$9 == 404 {print $7}' \
| sort | uniq -c | sort -rn | head -50
# Googlebot request count by day
grep -i 'googlebot' access.log \
| awk '{print $4}' \
| cut -d: -f1 | tr -d '[' \
| sort | uniq -c
# Parametric URLs in Googlebot requests
grep -i 'googlebot' access.log \
| awk '{print $7}' \
| grep '?' \
| sort | uniq -c | sort -rn | head -30Screaming Frog Log File Analyser
Un outil payant (259 $ par an), mais indispensable pour une analyse régulière. Il charge le fichier de logs, l'analyse et produit des rapports : segmentation Bot/Browser, tableaux de bord des statuts, cartes de chaleur des crawls par répertoire et liste des pages sans crawl. Il prend en charge les formats Nginx, Apache, IIS, CloudFlare, Fastly et les CSV personnalisés.
Python : une analyse souple pour les gros fichiers
import re
from collections import Counter
LOG_PATTERN = re.compile(
r'(?P<ip>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] '
r'"(?P<method>\S+) (?P<url>\S+) \S+" '
r'(?P<status>\d{3}) (?P<size>\S+) '
r'"(?P<referer>[^"]*)" "(?P<ua>[^"]*)')
def parse_log(path: str, bot_pattern: str = 'googlebot') -> list[dict]:
entries = []
with open(path) as f:
for line in f:
m = LOG_PATTERN.match(line)
if not m:
continue
if bot_pattern.lower() not in m.group('ua').lower():
continue
entries.append({
'ip': m.group('ip'),
'url': m.group('url'),
'status': int(m.group('status')),
'ua': m.group('ua'),
})
return entries
entries = parse_log('access.log')
# Top 20 URLs by crawl frequency
url_counts = Counter(e['url'] for e in entries)
for url, count in url_counts.most_common(20):
print(f'{count:>6} {url}')
# 404 errors
errors = [e['url'] for e in entries if e['status'] == 404]
for url, count in Counter(errors).most_common(20):
print(f'{count:>6} 404 {url}')Motifs de crawl : ce qu'il faut repérer
Les métriques brutes n'ont aucun sens sans interprétation. Voici des motifs précis à rechercher dans les logs de Googlebot.
Motif 1 : crawlé mais non indexé
Googlebot visite régulièrement une page, mais elle n'apparaît jamais comme « Indexée » dans la GSC. Causes possibles : balise meta noindex, blocage par l'en-tête HTTP X-Robots-Tag, contenu pauvre, canonical pointant vers une autre page. Comparez la liste des URL régulièrement crawlées avec les pages indexées obtenues via l'API de la GSC : les écarts révèlent les pages problématiques.
Motif 2 : tempêtes de crawl
Un pic soudain de requêtes de Googlebot sur une courte période est souvent le signe d'URL générées à l'infini : facettes, URL de pagination avec paramètres, jetons de session dans les URL. Une tempête de crawl peut épuiser tout votre budget en quelques heures et faire peser une charge réelle sur le serveur. Représentez les requêtes sous forme d'histogramme par heure : les pics anormaux apparaissent immédiatement.
Motif 3 : nouvelles pages ignorées
Une nouvelle page a été créée il y a trois semaines, ajoutée au sitemap, mais les logs de Googlebot n'affichent aucune requête. Causes : aucun lien interne ne pointe vers la page, le sitemap n'est pas crawlé de nouveau par le bot, ou la page est située à un niveau d'imbrication trop profond. Vérifiez les nouvelles URL avec l'outil d'inspection de la GSC et recherchez la date de première apparition dans les logs.
Motif 4 : ressources qui bloquent le rendu
Googlebot demande non seulement les pages HTML, mais aussi les CSS, les JS et les images. Si des ressources critiques sont bloquées dans le robots.txt, le bot ne peut pas faire le rendu de la page et risque de la sous-évaluer. Vérifiez dans les logs quelle part des requêtes de Googlebot vise des ressources statiques, et si des fichiers JS indispensables sont bloqués.
Problèmes courants et solutions
| Problème dans les logs | Cause | Solution |
|---|---|---|
| Beaucoup de 404 de Googlebot | Pages supprimées encore pointées par des liens externes ou internes | Redirection 301 vers la page active la plus proche + suppression des liens internes cassés |
| URL paramétriques dans le crawl | Paramètres UTM, tris et sessions non bloqués dans le robots.txt | Disallow dans le robots.txt + canonical vers l'URL propre sur les pages elles-mêmes |
| Chaînes de redirections (A→B→C) | Redirections accumulées après une restructuration | Réduire à un seul saut : mettre à jour tous les liens sortants |
| Pages /admin, /staging dans les logs | Sections techniques non bloquées | Disallow /admin/ dans le robots.txt + authentification HTTP sur l'environnement de préproduction |
| Réponses 5xx à Googlebot | Surcharge du serveur lors des pics de trafic ou erreurs du backend | Optimiser le TTFB, ajouter du cache, configurer une limitation du débit de requêtes du crawler |
| Page importante non crawlée | Pas de liens internes, trop profonde dans la hiérarchie, absente du sitemap | Ajouter au sitemap + créer des liens internes depuis les pages clés |
| Doublons www / sans www | Aucune redirection 301 vers la version canonique du domaine | 301 du sans-www vers www (ou l'inverse) au niveau de nginx/Apache |
| robots.txt bloque les JS/CSS nécessaires | Disallow /assets/ ou /static/ dans le modèle | Supprimer le blocage des ressources critiques nécessaires au rendu |
# Detect redirect chains in logs
# Step 1: extract all URLs with 301/302 status for Googlebot
grep -i 'googlebot' access.log \
| awk '$9 ~ /^30[12]$/ {print $7}' | sort -u > redirects.txt
# Step 2: check if any of those URLs are also redirect sources
while read url; do
if grep -q "GET $url " redirects.txt 2>/dev/null; then
echo "CHAIN: $url"
fi
done < redirects.txt
# Find 5xx errors grouped by URL and hour
grep -i 'googlebot' access.log \
| awk '$9 ~ /^5/ {print $4" "$7}' \
| cut -d: -f1-2 \
| sort | uniq -c | sort -rn | head -20FAQ
Synthèse
L'analyse des fichiers de logs est l'audit SEO le plus fiable qui soit. La GSC présente des agrégats, Screaming Frog simule, alors que les logs enregistrent chaque décision réelle de Googlebot. Le processus est simple : récupérer les logs des 30 à 90 derniers jours → filtrer les crawlers par User-Agent avec une vérification DNS → calculer les six métriques clés → recouper avec l'index de la GSC → corriger les écarts.
Commencez par trois commandes Bash : les 20 URL les plus crawlées, la répartition des codes de statut et le top des 404. En une heure, vous disposerez d'une liste concrète d'actions : redirections à mettre en place, URL à bloquer dans le robots.txt, pages à ajouter au sitemap. Cela va plus vite et coûte moins cher qu'un audit payant : les données se trouvent déjà sur votre serveur.
À quelle fréquence analyser les fichiers de logs ?
Ai-je besoin des logs si mon site est petit (moins de 500 pages) ?
Comment distinguer le vrai Googlebot d'un imitateur ?
La fréquence de crawl influe-t-elle directement sur le positionnement ?
Que faire si Googlebot crawle trop agressivement et surcharge le serveur ?
Check it with SpiderHead
Free and local: run the audit on your own machine.



