Analyse des fichiers logs et crawl budget

La plupart des outils SEO vous disent ce qui pourrait arriver à votre site. Les logs serveur vous disent ce qui est arrivé. Chaque fois que Googlebot récupère une URL, votre serveur écrit une ligne dans un fichier log — la vraie URL, le vrai code de statut, le vrai horodatage. Pas d’échantillonnage, pas d’estimations, pas de crawler tiers qui se fait passer pour Google. Si vous voulez savoir ce que les moteurs de recherche font réellement sur votre site, les logs sont la seule source de vérité.

Ce guide porte sur la lecture de cette vérité et sur la manière d’agir en conséquence. L’angle d’attaque est le crawl budget : la quantité finie de crawl que Google accepte de dépenser pour vous. Sur un petit site, le budget est en pratique infini et vous pouvez arrêter de lire après la prochaine section. Sur un grand site — un catalogue e-commerce, une marketplace, un site programmatique avec des centaines de milliers d’URL — le crawl budget est une contrainte forte, et les logs sont le moyen de trouver où il fuit.

🧑‍💻 Vue développeur : un fichier log n’est qu’un flux d’événements en append-only indexé par (timestamp, ip, method, url, status, user_agent). Tout ce qui se trouve dans ce guide est un GROUP BY ou une clause WHERE sur ce flux. Si vous avez déjà débogué un service à partir de ses logs d’accès, vous avez déjà le réflexe nécessaire pour le SEO basé sur les logs.

Ce qu’est le crawl budget

Le « crawl budget » n’est pas un nombre publié par Google. C’est le résultat émergent de deux forces que Google équilibre pour chaque site.

La limite de taux de crawl (crawl rate limit) est le plafond de la pression que Google exercera sur votre serveur. Googlebot est délibérément poli : si vos réponses ralentissent ou si vous commencez à renvoyer des erreurs 5xx, il se retire automatiquement pour éviter de faire tomber votre site. Un serveur rapide et en bonne santé relève le plafond ; un serveur lent ou instable le baisse. C’est le côté offre — la quantité de crawl que votre infrastructure peut absorber.

La demande de crawl (crawl demand) correspond à ce que Google veut crawler chez vous. Elle est portée par la popularité (les URL avec plus de liens et de trafic sont crawlées davantage) et par l’obsolescence (Google re-crawle les pages qu’il pense modifiées). Un site d’actualité avec des articles constamment mis à jour a une forte demande ; un site vitrine statique a une faible demande. C’est le côté demande — la quantité de crawl que votre contenu mérite réellement.

Le crawl budget effectif vaut à peu près min(rate limit, demand). Vous l’optimisez en augmentant les deux : servez rapidement (relevez la limite) et concentrez l’attention de Google sur les pages qui comptent (façonnez la demande).

Taille du site (URL indexables)	Le crawl budget est-il important ?
Moins de ~10 k	Presque jamais — Google crawle tout facilement
10 k–100 k	Parfois — surveillez-le si vous avez des paramètres d’URL ou une navigation à facettes
Plus de 100 k	Oui — c’est un levier majeur
Toute taille avec des pièges à crawl	Oui — un calendrier ou une explosion de filtres peut couler un petit site

⚠️ Note : la catastrophe de crawl budget la plus courante n’est pas un grand site — c’est un petit site avec un piège qui génère une infinité d’URL (un sélecteur de date, une combinaison de filtres non bornée). Google peut brûler la totalité de son budget à crawler 400 000 permutations de filtres inutiles pendant que vos 200 vraies pages produits deviennent obsolètes.

Logs serveur 101

Un log d’accès de serveur web, c’est une ligne par requête. Le format classique est le « combined log format » NCSA qu’Apache et Nginx émettent par défaut :

66.249.66.1 - - [22/Jun/2026:08:14:32 +0000] "GET /products/widget-42?color=red HTTP/1.1" 200 5123 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Une fois décodés, les champs qui vous intéressent pour le SEO sont :

Champ	Exemple	Pourquoi c’est important
IP client	`66.249.66.1`	Vérifier le vrai Googlebot (reverse DNS)
Horodatage	`22/Jun/2026:08:14:32`	Fréquence de crawl, fraîcheur
Méthode + URL	`GET /products/widget-42?color=red`	Ce qui a été crawlé ; gaspillage par paramètres
Code de statut	`200`	404, redirections, erreurs 5xx
Octets	`5123`	Taille du payload, poids de la réponse
User agent	`...Googlebot/2.1...`	Quel crawler a touché l’URL

Obtenir les logs est le vrai obstacle. L’endroit où ils se trouvent dépend de votre stack :

Nginx/Apache auto-hébergé — /var/log/nginx/access.log, tourné quotidiennement via logrotate. Le cas le plus simple ; il suffit de les scp.
Load balancers cloud — l’ALB d’AWS écrit les logs d’accès dans S3 ; les load balancers GCP écrivent dans Cloud Logging. Vous les activez par listener.
Derrière un CDN — c’est le piège. Si vous êtes derrière Cloudflare, Fastly ou CloudFront, Googlebot touche le edge du CDN, pas votre origine. Vos logs d’origine ne voient que les cache misses, ils sous-comptent donc gravement le crawl. Il vous faut les logs du CDN.
Cloudflare en particulier — utilisez Logpush pour streamer en continu les logs de requêtes HTTP vers R2 (ou S3, ou un sink externe). C’est la configuration canonique pour un site hébergé sur Cloudflare et nous la détaillons dans la section Cloudflare ci-dessous.

💡 Astuce : collectez au moins 30 jours de logs avant de tirer des conclusions. Le schéma de crawl de Googlebot sur une seule journée est bruité ; sur un mois, les schémas de gaspillage deviennent incontestables. Visez une fenêtre glissante que vous pouvez re-interroger.

Analyser Googlebot

Avant de faire confiance à la moindre ligne de log attribuée à « Googlebot », vérifiez-la. La chaîne user-agent est trivialement falsifiable — scrapers et concurrents se font régulièrement passer pour Googlebot afin de contourner les limites de taux. Compter de faux hits Googlebot comme du crawl budget vous enverra courir après des fantômes.

Vérifiez avec le reverse + forward DNS. Les vraies IP de Googlebot se résolvent en reverse vers googlebot.com ou google.com, et ce nom d’hôte doit se résoudre en forward vers la même IP. Les usurpateurs contrôlent le user agent, mais pas le DNS de Google.

# Reverse lookup : l'IP revendique-t-elle un nom d'hôte Google ?
host 66.249.66.1
# -> 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

# Forward lookup : ce nom d'hôte se résout-il vers la même IP ?
host crawl-66-249-66-1.googlebot.com
# -> crawl-66-249-66-1.googlebot.com has address 66.249.66.1   ✓ verified

Si vous ne voulez pas faire de DNS par IP, Google publie les plages d’IP de ses crawlers en JSON à https://developers.google.com/static/search/apis/ipranges/googlebot.json — comparez l’IP client à ces CIDR hors ligne.

Une fois que vous faites confiance aux données, posez-leur quatre questions.

Qu’est-ce qui est crawlé ? Regroupez les hits par URL et regardez le haut de la liste. Sur un site sain, les URL les plus crawlées sont vos pages les plus importantes. Si vos URL les plus crawlées sont des variantes ?sessionid= ou des permutations de filtres, c’est la fuite numéro un.

À quelle fréquence les pages clés sont-elles crawlées ? Récupérez l’horodatage du dernier crawl de vos pages stratégiques. Si votre page de catégorie principale a été récupérée pour la dernière fois il y a 18 jours, Google la croit obsolète ou sans importance — c’est un problème de fraîcheur.

Où le budget est-il gaspillé ? C’est le cœur de l’analyse de logs. Les suspects habituels :

Schéma de gaspillage	À quoi ça ressemble dans les logs	Cause typique
URL à paramètres	Beaucoup de hits vers `?sort=`, `?utm_`, `?sessionid=`	Paramètres de tracking, tri, identifiants de session
Contenu dupliqué	Même contenu sous `/p/123` et `/products/widget`	Plusieurs routes vers une même page
Chaînes de redirection	Séquences `301 -> 301 -> 200`	Migrations empilées sur des migrations
Tempêtes de 404 / 410	Fort volume de `404` vers les bots	Liens morts, produits supprimés encore liés
Soft 404	`200` sur des pages réellement « introuvables »	Résultats de recherche vides, articles épuisés
Navigation à facettes	URL combinatoires `?color=&size=&brand=`	Filtres sans contrôle du crawl

Un triage rapide que vous pouvez exécuter sur un log brut avec seulement le shell :

# Top 20 des URL crawlées par tout ce qui se prétend Googlebot
grep -i googlebot access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn | head -20

# Distribution des codes de statut pour Googlebot — le ratio 4xx/5xx est votre signal de gaspillage
grep -i googlebot access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

Si 30 % des requêtes de Googlebot renvoient 404 ou touchent des URL chargées en ?, environ un tiers de votre crawl budget part à la poubelle.

Optimiser le crawl budget

Une fois que les logs vous indiquent où sont les fuites, vous les colmatez. La boîte à outils est réduite, mais chaque outil a un rôle précis — utiliser le mauvais, c’est comme ça qu’on désindexe accidentellement son site.

Bloquez à la source avec robots.txt. Interdire un chemin empêche Google de le crawler du tout, ce qui est exactement ce que vous voulez pour le gaspillage de crawl budget comme la recherche interne, les ordres de tri et les paramètres de tracking. Notez que Disallow ne retire pas une URL de l’index si elle est liée ailleurs — cela arrête seulement la récupération.

User-agent: *
Disallow: /search
Disallow: /*?sort=
Disallow: /*?sessionid=
Disallow: /cart

Consolidez les doublons avec rel=canonical. Quand le même contenu vit à plusieurs URL (variantes paramétrées, liens taggés pour le tracking), pointez-les toutes vers une seule URL canonique. Google regroupera les signaux et préférera crawler la canonical.

<link rel="canonical" href="https://example.com/products/widget-42" />

Gardez les pages à faible valeur hors de l’index avec noindex. Pour les pages qui doivent rester crawlables pour les utilisateurs mais ne devraient pas concourir dans la recherche — archives de tags maigres, queues de pagination — utilisez une balise meta robots noindex. Important : ne combinez pas noindex avec un Disallow dans robots.txt, car si Google ne peut pas crawler la page, il ne peut pas voir le noindex.

Les deux corrections structurelles à plus fort impact :

Éliminez les pièges à crawl. La navigation à facettes et les calendriers infinis sont les incinérateurs de budget classiques. Une UI de filtres avec 6 facettes de 10 valeurs chacune génère un million de combinaisons d’URL, dont aucune ne mérite d’être indexée. Corrigez en servant des liens de filtres que les bots ne suivront pas (formulaires POST, ou rel=nofollow plus Disallow sur le paramètre), et bornez le calendrier infini pour que /events/2099/12 renvoie un 404 au-delà d’un horizon raisonnable.

Réparez les chaînes de redirection et les soft 404. Chaque saut dans une chaîne 301 -> 301 -> 200 est une récupération gaspillée et une petite perte de link equity ; aplatissez les chaînes pour que chaque ancienne URL pointe directement vers la destination finale en un seul saut. Pour les soft 404 — des pages qui semblent vides mais renvoient 200, comme des produits épuisés ou des recherches sans résultat — renvoyez un vrai 404/410 afin que Google cesse de les re-crawler comme s’il s’agissait de contenu actif.

💡 Astuce : après avoir déployé vos correctifs, les logs sont aussi votre outil de vérification. Re-récupérez une semaine de hits Googlebot et confirmez que les URL à paramètres et les 404 ont chuté, et que les crawls de vos pages stratégiques ont augmenté. Le crawl budget libéré des déchets est redistribué vers vos bonnes pages — vous pouvez le voir se produire.

Outillage

Vous pouvez aller loin avec grep, awk et sort, mais à l’échelle vous voudrez quelque chose d’interrogeable.

BigQuery est le cheval de trait des grands sites. Chargez les logs dans une table et l’analyse de crawl devient du SQL simple sur des milliards de lignes :

SELECT
  REGEXP_EXTRACT(url, r'^[^?]+') AS path,   -- strip query string
  COUNT(*)                       AS hits,
  COUNTIF(status >= 400)         AS errors
FROM `logs.googlebot`
WHERE _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY path
ORDER BY hits DESC
LIMIT 50;

Screaming Frog Log File Analyser est l’option sans code : glissez-y des fichiers logs bruts, pointez-le vers votre crawl, et il croise les deux pour que vous puissiez voir les URL crawlées-mais-absentes-du-crawl (« orphelines ») et les pages importantes-mais-rarement-crawlées. Idéal pour des audits ponctuels.

Un parser maison vaut le coup pour les analyses récurrentes que vous voulez maîtriser. Une ligne de combined log est suffisamment régulière pour être parsée avec un seul motif :

import re
from collections import Counter

# Matches: ip ... "METHOD url HTTP/x" status bytes "ref" "ua"
LINE = re.compile(
    r'(?P<ip>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] '
    r'"(?P<method>\S+) (?P<url>\S+) [^"]+" '
    r'(?P<status>\d{3}) (?P<bytes>\S+) "[^"]*" "(?P<ua>[^"]*)"'
)

paths, statuses = Counter(), Counter()

with open("access.log", encoding="utf-8", errors="replace") as fh:
    for line in fh:
        m = LINE.match(line)
        if not m or "googlebot" not in m["ua"].lower():
            continue
        path = m["url"].split("?", 1)[0]   # group by path, ignore params
        paths[path] += 1
        statuses[m["status"]] += 1

print("Top crawled paths:")
for path, n in paths.most_common(20):
    print(f"{n:6d}  {path}")

print("\nStatus distribution:", dict(statuses))

Lancez cela sur un mois de logs et vous obtenez, en quelques secondes, les mêmes réponses qu’un outil coûteux — les chemins les plus crawlés et le ratio d’erreurs qui quantifie votre gaspillage.

🧑‍💻 Angle Cloudflare

Si votre site est sur Cloudflare, vos logs d’origine sont aveugles à la majeure partie du crawl — Googlebot touche surtout des réponses mises en cache au edge. La solution, c’est Logpush : un pipeline managé qui streame les logs de requêtes HTTP depuis le edge de Cloudflare vers un sink de votre choix. Le sink le moins cher et le plus favorable au SEO est R2, le stockage objet compatible S3 de Cloudflare, sans frais d’egress.

La forme de la configuration :

Dans le dashboard Cloudflare, allez dans Analytics & Logs -> Logpush et créez un job pour le dataset HTTP requests.
Choisissez R2 comme destination et sélectionnez les champs dont vous avez besoin : ClientIP, ClientRequestURI, EdgeResponseStatus, ClientRequestUserAgent, EdgeStartTimestamp, CacheCacheStatus.
Logpush dépose des batches JSON gzippés dans votre bucket R2 toutes les quelques minutes.

Interrogez ensuite les logs directement — par exemple avec R2 SQL / une session DuckDB sur les fichiers exportés :

-- Top URIs fetched by Googlebot, last 7 days, with error ratio
SELECT
  ClientRequestURI                                     AS uri,
  COUNT(*)                                             AS hits,
  SUM(CASE WHEN EdgeResponseStatus >= 400 THEN 1 ELSE 0 END) AS errors
FROM read_json_auto('r2://my-logs/http/2026/06/*.json.gz')
WHERE lower(ClientRequestUserAgent) LIKE '%googlebot%'
GROUP BY uri
ORDER BY hits DESC
LIMIT 50;

Parce que Logpush inclut CacheCacheStatus, vous obtenez aussi un super-pouvoir de crawl budget que l’origine ne pourra jamais vous donner : vous pouvez voir quelles URL crawlées sont servies depuis le cache (hit) par rapport à celles qui forcent une récupération à l’origine (miss/expired). Des taux de miss élevés de Googlebot sur des pages importantes signifient que votre cache au edge n’aide pas le crawler — une opportunité de tuning qui renvoie directement à la couche Build, où vivent la mise en cache et la configuration du edge.

💡 Astuce : configurez le job Logpush pour capturer également les métadonnées de bots vérifiés si vous avez l’add-on Bot Management — Cloudflare vérifie Googlebot pour vous, vous pouvez donc sauter la danse du reverse DNS et filtrer plutôt sur un flag de confiance.

Points clés à retenir

✅ Décidez si le crawl budget vous concerne réellement : sous ~10 k URL propres, ignorez-le ; au-delà de 100 k ou avec un piège à crawl, traitez les logs comme un levier majeur.
✅ Obtenez de vrais logs au edge — si vous êtes derrière un CDN, envoyez Cloudflare Logpush vers R2 plutôt que de vous fier à des logs d’origine qui ratent les crawls mis en cache.
✅ Vérifiez Googlebot par reverse + forward DNS (ou plages d’IP) avant de faire confiance à la moindre ligne « Googlebot » de vos logs.
✅ Quantifiez le gaspillage : mesurez la part des hits Googlebot allant vers des URL à paramètres, des 404, des chaînes de redirection et des soft 404.
✅ Colmatez les fuites avec le bon outil — robots.txt pour stopper le crawl, canonical pour consolider, noindex pour désindexer, et des corrections structurelles pour la navigation à facettes et les pièges de calendrier.
✅ Bouclez la boucle : re-récupérez les logs après avoir déployé les correctifs et confirmez que le gaspillage a baissé pendant que les crawls de vos pages stratégiques ont augmenté.