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.

Processus d'analyse des logs serveur pour l'audit SEO.

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.

Règle pratique : si votre site compte plus de 10 000 URL, ou si la section « Détectée, actuellement non indexée » de la GSC ne cesse de grossir, l'analyse des logs est obligatoire, et non facultative.

Ce que l'analyse des logs apporte

100%

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

≤1s

Précision temporelle

Des horodatages à la seconde permettent de suivre les schémas de crawl par jour de la semaine et par heure

3+

Plusieurs bots, une seule source

Googlebot, Bingbot, Yandex et les autres : tous les crawlers dans un seul fichier, comparables sur une même vue

0

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 / plateformeChemin par défaut des logsRemarques
Nginx/var/log/nginx/access.logRotation 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 → LogsSouvent découpés par domaine. Raw Access disponible dans l'interface cPanel
Cloudflare Workers / EnterpriseLogpush API → S3, R2, GCSRéservé au forfait Enterprise. Pour Free/Pro : Workers Analytics Engine
AWS CloudFrontBucket S3 configuré dans Paramètres de distribution → LoggingJournaux générés toutes les 5 à 10 minutes, compressés en gzip
Google Cloud / GCSCloud Logging → export vers BigQuery ou GCSIdéal pour les gros volumes : requêtes SQL directement dans BigQuery
Exemple de code :
bash
# 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.log
Conseil sur la rotation : par défaut, logrotate conserve 7 à 14 jours de logs. Pour l'analyse SEO, il en faut au minimum 30. Augmentez rotate 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.

text
# 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
Comparaison des champs :
ChampPertinence SEOCe qu'il faut repérer
Adresse IPÉlevéePlages IP de Googlebot, Bingbot, Yandex : elles servent à filtrer les vrais crawlers
HorodatageÉlevéeFréquence de crawl, date de la dernière visite de certaines URL
Requête (méthode + URL)CritiqueURL crawlées : pages utiles, doublons, paramètres, chemins inexistants
Statut HTTPCritique200 (correct), 301/302 (redirections), 404 (liens morts), 500 (erreurs serveur)
Octets envoyésMoyenneTaille anormalement faible : signe d'une page vide ou d'une réponse factice
User-AgentCritiqueDistinguer 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.

bash
# 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 Googlebot
Ne vous fiez pas au seul User-Agent. Les spambots falsifient souvent la chaîne Googlebot. 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.

Métrique 1Fréquence de crawl

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 jours
Métrique 2Taux de réponses en erreur

Part 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 %
Métrique 3Part des redirections

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 bots
Métrique 4URL en doublon dans les logs

Un 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 contenu
Métrique 5Pages importantes sans crawl

Pages 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 jours
Métrique 6Pages indésirables dans le crawl

Pages 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 Googlebot

Outils 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

bash
# 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 -30

Screaming 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

python
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}')
BigQuery pour les grandes structures : lorsque les access logs atteignent des centaines de Go, l'analyse en local devient impraticable. Chargez-les dans BigQuery (GCS → BigQuery → requête planifiée) et lancez vos requêtes SQL. Analyser 1 To coûte environ 5 $.

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 logsCauseSolution
Beaucoup de 404 de GooglebotPages supprimées encore pointées par des liens externes ou internesRedirection 301 vers la page active la plus proche + suppression des liens internes cassés
URL paramétriques dans le crawlParamètres UTM, tris et sessions non bloqués dans le robots.txtDisallow 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 restructurationRéduire à un seul saut : mettre à jour tous les liens sortants
Pages /admin, /staging dans les logsSections techniques non bloquéesDisallow /admin/ dans le robots.txt + authentification HTTP sur l'environnement de préproduction
Réponses 5xx à GooglebotSurcharge du serveur lors des pics de trafic ou erreurs du backendOptimiser le TTFB, ajouter du cache, configurer une limitation du débit de requêtes du crawler
Page importante non crawléePas de liens internes, trop profonde dans la hiérarchie, absente du sitemapAjouter au sitemap + créer des liens internes depuis les pages clés
Doublons www / sans wwwAucune redirection 301 vers la version canonique du domaine301 du sans-www vers www (ou l'inverse) au niveau de nginx/Apache
robots.txt bloque les JS/CSS nécessairesDisallow /assets/ ou /static/ dans le modèleSupprimer le blocage des ressources critiques nécessaires au rendu
Exemple de code :
bash
# 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 -20

FAQ

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 ?
Au minimum tous les trimestres pour les sites stables. Après des changements majeurs (nouvelle structure de site, refonte, publication massive de contenu), faites-le immédiatement. Pour un e-commerce avec des dizaines de milliers de références et une génération active d'URL paramétriques, faites-le tous les mois. Si la GSC montre une baisse anormale de l'activité de crawl, faites-le sans attendre.
Ai-je besoin des logs si mon site est petit (moins de 500 pages) ?
Sur un petit site, la GSC suffit souvent. Mais si les positions ont chuté sans cause évidente, ou si de nouvelles pages mettent longtemps à apparaître dans l'index, les logs donnent la réponse plus vite que n'importe quel autre outil. Une analyse ponctuelle prend 30 minutes et vaut la peine d'être faite au moins une fois, comme audit d'étalonnage.
Comment distinguer le vrai Googlebot d'un imitateur ?
Vérification DNS en deux étapes : d'abord une recherche inverse de l'IP, qui doit se résoudre en *.googlebot.com ou *.google.com. Ensuite une recherche directe sur ce nom d'hôte, qui doit renvoyer la même IP. Les deux étapes sont obligatoires : le DNS inverse seul ne suffit pas, car n'importe qui peut configurer un enregistrement PTR.
La fréquence de crawl influe-t-elle directement sur le positionnement ?
La fréquence de crawl et le positionnement sont deux observations distinctes. Une page souvent crawlée n'est pas automatiquement plus forte, et une page rarement crawlée n'est pas automatiquement faible. Utilisez les logs pour comprendre le comportement de découverte et de nouveau crawl, puis analysez le positionnement avec d'autres indices issus de la recherche.
Que faire si Googlebot crawle trop agressivement et surcharge le serveur ?
Ajustez le taux de crawl dans la Google Search Console (Paramètres → Crawl rate limit). Pour des sections précises, utilisez Crawl-delay dans le robots.txt, mais Google ne promet pas officiellement de le respecter. Plus fiable : optimisez le TTFB et le cache pour que le serveur absorbe la charge sans avoir à restreindre le crawl.

Check it with SpiderHead

Free and local: run the audit on your own machine.

Try it