Analyser les fichiers logs serveur

Pourquoi les logs font ce que les autres outils ne font pas

Screaming Frog simule un crawl. La Google Search Console vous donne des statistiques agrégées. Les logs, eux, enregistrent chaque requête HTTP reçue par votre serveur, quel que soit l'émetteur. Googlebot, Bingbot, GPTBot, un utilisateur ordinaire, un script malveillant : tout laisse une trace.

C'est la différence entre lire un rapport de visite et regarder les images de la caméra de surveillance. Les outils SEO classiques vous montrent ce que Google a décidé d'indexer. Les logs vous montrent ce que Google a exploré, dans quel ordre, à quelle fréquence, et avec quel résultat.

Concrètement, les logs permettent de répondre à des questions que aucun autre outil ne peut traiter :

• Googlebot crawle-t-il mes pages importantes régulièrement, ou perd-il son temps ailleurs ?
• Quelles URLs génèrent des erreurs 404 ou 5xx lors du crawl ?
• Y a-t-il des pages orphelines qui ne sont jamais visitées ?
• Mes redirections 301 sont-elles toutes résolues en une étape, ou forment-elles des chaînes ?
• Des bots tiers (IA, scrapers) consomment-ils une part significative de ma bande passante ?

Lire un fichier log : le format CLF

Les serveurs Apache et Nginx écrivent leurs logs dans le Combined Log Format (CLF), un standard dérivé du Common Log Format d'origine. Chaque ligne correspond à une requête HTTP. Voici un exemple réel :

66.249.79.84 - - [16/Apr/2026:09:14:22 +0200] "GET /crawl-budget/ HTTP/1.1" 200 18342 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Chaque champ a une signification précise :

Les fichiers logs se trouvent par défaut dans /var/log/apache2/access.log (Apache) ou /var/log/nginx/access.log (Nginx). Ils sont souvent compressés et rotatifs : access.log pour le fichier courant, access.log.1.gz, access.log.2.gz... pour les archives.

Les codes HTTP à surveiller en priorité

La colonne "code de réponse" est la première chose à analyser en masse. La distribution idéale d'un site en bonne santé devrait être écrasante sur les 200.

Identifier et vérifier Googlebot

N'importe qui peut envoyer une requête avec l'user-agent Googlebot. Le spoofing est trivial. Pour confirmer qu'une requête vient bien des serveurs de Google, la seule méthode fiable est la vérification DNS double, documentée dans la Search Console.

1. Reverse DNS lookup

   Prenez l'IP de la requête suspecte et faites une résolution DNS inversée. Sous Linux :

   nslookup 66.249.79.84

   Le résultat doit retourner un hostname se terminant par .googlebot.com ou .google.com (par exemple crawl-66-249-79-84.googlebot.com). Si ce n'est pas le cas, la requête est frauduleuse.

2. Forward DNS (confirmation)

   Prenez le hostname obtenu à l'étape précédente et résolvez-le en IP :

   nslookup crawl-66-249-79-84.googlebot.com

   Cette IP doit correspondre à l'IP de départ. Si les deux concordent, la requête est authentique.

Les plages d'IP officielles de Googlebot sont publiées par Google (googlebot.json). Vous pouvez les comparer automatiquement pour filtrer les faux bots à grande échelle.

Les patterns à chercher en priorité

1. Distribution du crawl par URL

La première question à poser : sur quelles pages Googlebot concentre-t-il ses visites ? Sur un site sain, les pages stratégiques (accueil, pages de catégories, pages à fort potentiel) devraient dominer. Si des URLs générées par des filtres, des paramètres de session ou des pages de pagination basse consomment la majorité du budget, c'est un signal d'alarme.

Pour extraire le top 50 des URLs crawlées par Googlebot :

grep "Googlebot" access.log \
  | awk '{print $7}' \
  | sed 's/\?.*//g' \
  | sort | uniq -c | sort -rn \
  | head -50

2. Volume d'erreurs 404 et 5xx

Pour obtenir la distribution des codes de réponse en une commande :

awk '{print $9}' access.log | sort | uniq -c | sort -rn

Pour lister les URLs les plus fréquemment en 404 lors du crawl de Googlebot :

grep "Googlebot" access.log \
  | grep " 404 " \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn \
  | head -20

3. Chaînes de redirections

Une chaîne de redirections (A redirige vers B qui redirige vers C) force Googlebot à effectuer plusieurs requêtes pour atteindre une seule destination. Sur un site avec des milliers de pages migrées, c'est souvent là que disparaît une part importante du crawl budget.

# Volume total de redirections dans les logs
grep "Googlebot" access.log | grep " 301 " | wc -l
grep "Googlebot" access.log | grep " 302 " | wc -l

4. Fréquence de crawl par page

La fréquence à laquelle Googlebot revisite une page est un signal indirect de l'importance qu'il lui accorde. Sur un site bien structuré :

• La page d'accueil est crawlée plusieurs fois par jour
• Les pages catégories importantes, plusieurs fois par semaine
• Les pages de contenu récent, plusieurs fois par mois
• Les pages peu liées ou de faible qualité, quelques fois par an

Si une page que vous considérez stratégique n'apparaît qu'une ou deux fois dans 90 jours de logs, c'est le signe qu'elle est mal maillée, trop lente, ou perçue comme peu pertinente.

5. Les crawl traps

Un crawl trap est une structure d'URLs qui génère un nombre théoriquement infini de pages uniques : un calendrier avec des archives infinies, une boutique avec des filtres combinables (taille + couleur + marque + prix...), des paramètres de session dans les URLs. Pour les détecter :

# URLs contenant des paramètres, triées par volume
grep "Googlebot" access.log \
  | grep -E "\?[a-z]" \
  | awk '{print $7}' \
  | grep -oP '(?<=\?)[^"]+' \
  | cut -d'&' -f1 \
  | sort | uniq -c | sort -rn \
  | head -20

Les outils pour analyser les logs

La ligne de commande est puissante mais chronophage. Pour une analyse régulière ou sur de gros volumes, plusieurs outils existent.

Pour la plupart des analyses SEO courantes, Screaming Frog Log File Analyser est le point de départ le plus accessible. Pour les sites de grande taille ou les analyses répétées, un script Python sur mesure offre plus de contrôle.

Exemple de script Python pour parser les logs

Ce script basique extrait les informations essentielles d'un fichier access.log et produit un récapitulatif exploitable :

import re
from collections import Counter

LOG_FILE = '/var/log/nginx/access.log'
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>\d+) '
    r'"[^"]*" "(?P<ua>[^"]*)"'
)

status_counts = Counter()
googlebot_urls = Counter()
errors_5xx = []

with open(LOG_FILE, encoding='utf-8', errors='ignore') as f:
    for line in f:
        m = LOG_PATTERN.match(line)
        if not m:
            continue
        status = m.group('status')
        url    = m.group('url').split('?')[0]  # sans paramètres
        ua     = m.group('ua')

        status_counts[status] += 1

        if 'Googlebot' in ua:
            googlebot_urls[url] += 1

        if status.startswith('5'):
            errors_5xx.append((m.group('time'), url, status))

print("=== Distribution des codes HTTP ===")
for code, count in status_counts.most_common():
    print(f"  {code} : {count:,}")

print("\n=== Top 20 URLs crawlées par Googlebot ===")
for url, count in googlebot_urls.most_common(20):
    print(f"  {count:4d}x  {url}")

print(f"\n=== Erreurs 5xx ({len(errors_5xx)} au total) ===")
for time, url, status in errors_5xx[:10]:
    print(f"  [{time}] {status} {url}")

Ce que vous faites avec les résultats

L'analyse des logs n'a de valeur que si elle débouche sur des actions. Voici les décisions les plus fréquentes :

1. Bloquer les URLs sans valeur dans le robots.txt

   Si les logs montrent que Googlebot passe 60 % de son temps sur des URLs de filtres, de tri ou de pagination profonde que vous ne voulez pas indexer, bloquez-les via le fichier robots.txt. L'objectif est que chaque requête de crawl porte sur une URL que vous souhaitez voir indexée.

2. Corriger les redirections en chaîne

   Identifiez les 301 vers d'autres 301 et mettez à jour les redirections pour qu'elles pointent directement vers la destination finale. Sur un site migré, c'est souvent là que se trouvent des dizaines de requêtes inutiles par page.

3. Réparer ou supprimer les 404 fréquemment crawlés

   Une URL en 404 qui apparaît régulièrement dans les logs de Googlebot reçoit encore des liens depuis quelque part (interne ou externe). Retrouvez la source via le champ "référent", mettez à jour le lien ou ajoutez une redirection.

4. Améliorer le maillage des pages sous-crawlées

   Les pages absentes des logs ou visitées une seule fois en 90 jours ont probablement trop peu de liens internes. Renforcez leur maillage interne depuis des pages déjà bien crawlées.

5. Bloquer les bots parasites

   Si des crawlers IA (GPTBot, ClaudeBot, PerplexityBot) ou des scrapers non identifiés consomment une part significative de votre bande passante, vous pouvez les bloquer via le robots.txt ou directement au niveau du serveur (règles Nginx/Apache basées sur le user-agent).

Cas d'usage : surveiller une migration

La migration d'un site est le moment où l'analyse de logs est la plus précieuse. Dans les semaines qui suivent la mise en ligne :

• Vérifier que les anciennes URLs ne génèrent plus de 404 : chaque ancienne URL encore crawlée doit retourner un 301 vers sa nouvelle équivalente, pas un 404.
• Mesurer la progression du recrawl : le ratio crawls sur nouvelles URLs / crawls sur anciennes URLs doit progresser chaque semaine.
• Détecter les soft 404 : sur une nouvelle architecture, des gabarits peuvent répondre 200 sur des URLs inexistantes. Les logs révèlent ces cas par la taille de réponse identique sur des dizaines d'URLs.
• Comparer la fréquence de crawl avant/après : une migration réussie ne doit pas réduire la fréquence de crawl des pages importantes. Une chute significative indique un problème de signal (liens internes cassés, canonical erroné, performance dégradée).

Sources et références

• Google Search Central : vérifier l'authenticité de Googlebot
• Google Search Central : gérer le crawl budget sur les grands sites
• Screaming Frog Log File Analyser
• GoAccess - Visual Web Log Analyzer