Crawl budget : guide pratique pour les grandes plateformes

Le budget de crawl correspond au nombre de pages que Googlebot accepte de crawler sur votre site sur une période donnée. Sur les petits sites, il est pratiquement illimité. Sur les plateformes qui comptent des millions d'URL, il devient une ressource stratégique : le robot le gaspille sur les filtres, la pagination, les gabarits vides et les pages de préproduction, au lieu de crawler les contenus prioritaires. Résultat : indexation retardée des nouveaux produits, couverture faible du catalogue et positions perdues.

zoom_in

Étape 1 : collecter et analyser les logs des crawlers

Les logs serveur sont la source de référence sur ce que Googlebot crawle réellement. L'analyse des logs révèle la fréquence réelle des requêtes, les sections que le robot ignore ou sur lesquelles il reste bloqué, et les réponses HTTP renvoyées par le serveur. Sans logs, toute optimisation repose sur des suppositions.

Extraire les requêtes de Googlebot depuis Nginx ou Apache

# Filter only Googlebot requests from the last 7 days
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn \
  | head -50

# HTTP status codes seen by Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# Top URLs returning 404 to Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '$9 == "404" {print $7}' \
  | sort | uniq -c | sort -rn | head -30

Pour analyser en détail de gros volumes de logs, utilisez des outils dédiés : Screaming Frog Log File Analyser, Semrush Log Analyser ou une pile ELK (Elasticsearch + Kibana). Ils regroupent automatiquement les URL par modèle et tracent l'évolution du taux de crawl dans le temps.

Étape 2 : Google Search Console et analyse des réponses du serveur

Google Search Console fournit des données de crawl agrégées, sans accès aux logs serveur. Le rapport Statistiques d'exploration est le point d'entrée principal. Il affiche le nombre moyen de requêtes par jour, la vitesse de chargement perçue et la répartition des codes de réponse.

• GSC → Paramètres → Statistiques d'exploration : graphique des requêtes de crawl, ventilation par type de fichier et par code de réponse. Repérez les pics de 404 et de 500, ainsi que les baisses après les déploiements.
• GSC → Indexation → Pages : nombre d'URL indexées et raisons de la non-indexation. « Détectée, actuellement non indexée » est un signal direct du budget de crawl.
• GSC → Inspection d'URL : vérification manuelle d'une page précise : date du dernier crawl et version que Googlebot a vue.
• GSC → Paramètres → Limite du taux d'exploration : vous pouvez limiter le taux de crawl si le robot surcharge le serveur. En général, ce n'est pas nécessaire : ne limitez que si vous constatez des problèmes de performance mesurables.

Sources de gaspillage du budget de crawl

Sur une grande plateforme, le robot perd du budget à travers six sources typiques. Identifiez chacune dans vos logs et estimez son volume : vous obtiendrez ainsi l'ordre de priorité des optimisations.

zoom_in

Paramètres d'URL et doublons : correction

Les URL paramétrées sont la principale source de gaspillage sur les plateformes e-commerce. Il n'existe pas de solution unique : la bonne réponse dépend de la nature du paramètre.

# robots.txt — blocking parametric URLs
User-agent: *

# Sort and filter parameters
Disallow: /*?sort=
Disallow: /*?order=
Disallow: /*?filter=
Disallow: /*?color=
Disallow: /*?size=

# Pagination deeper than page 3 (Allow/Disallow approach)
Disallow: /*?page=
Allow: /*?page=1
Allow: /*?page=2
Allow: /*?page=3

# Session and tracking parameters
Disallow: /*?sessionid=
Disallow: /*?token=
Disallow: /*?ref=
Disallow: /*?utm_

# Preview and drafts
Disallow: /*?preview=
Disallow: /*?draft=

Filtres, facettes et pagination

La navigation à facettes est le cas le plus complexe. Elle crée une explosion combinatoire d'URL : 10 filtres de 5 valeurs chacun peuvent générer plus d'un million de combinaisons. L'objectif est de conserver les facettes utiles (marque et catégorie) et de bloquer les combinaisons inutiles.

1. Identifiez les facettes utiles : pages à fort trafic organique ou à contenu SEO unique (par exemple /catalog/nike/ avec un texte propre à la marque). Gardez-les dans l'index, avec une canonical auto-référente.
2. Ajoutez un noindex + follow aux combinaisons peu utiles : la page est rendue (les liens sont suivis), mais n'entre pas dans l'index. Utilisez <meta name="robots" content="noindex, follow"> dans le gabarit dès qu'il y a plus d'une facette active.
3. Interdisez les paramètres purement techniques : tri, couleur, taille, lorsqu'ils n'ont aucune valeur SEO. Bloquez-les via robots.txt.
4. Facettes chargées en AJAX : si les facettes se chargent en JavaScript sans se refléter dans l'URL, le robot ne voit aucune URL supplémentaire. Le problème est ainsi réglé au niveau de l'architecture.

Pagination : canonical ou Disallow

La stratégie de pagination optimale dépend de l'échelle : jusqu'à 10 pages, autorisez le crawl et ajoutez une canonical vers la page 1 sur les pages 2 et suivantes. Pour des centaines de pages de pagination, utilisez Disallow au-delà de la page 3 à 5. Un défilement infini sans paramètre d'URL est traité comme une page unique par le robot : c'est bon pour le budget.

Pages temporaires : webinaires, maquettes, démos

Les pages temporaires drainent discrètement le budget des plateformes dont les équipes marketing sont actives. Pages de webinaires, maquettes de démonstration, pages d'aperçu pour les clients, variantes de tests A/B : elles apparaissent vite et restent souvent indéfiniment, en consommant le budget de crawl en silence.

• meta robots noindex : ajoutez <meta name="robots" content="noindex, nofollow"> au gabarit de toutes les pages temporaires. Le robot visite la page, lit la directive et exclut l'URL de l'index. C'est la méthode la plus simple lorsque vous avez accès aux gabarits.
• En-tête HTTP X-Robots-Tag : si les pages temporaires n'ont pas de gabarit HTML dédié (par exemple des PDF ou des fichiers générés), utilisez l'en-tête de réponse HTTP : X-Robots-Tag: noindex, nofollow.
• Disallow par préfixe de chemin : si les pages temporaires se trouvent sous des préfixes de chemin prévisibles, bloquez-les dans robots.txt. Cela ne retire pas une URL déjà indexée, mais les nouvelles URL ne seront pas crawlées.
• Authentification HTTP : pour la préproduction et les pages d'aperçu, c'est la seule méthode d'isolement complet et fiable. Googlebot n'a pas d'identifiants et ne crawlera pas la page.

# robots.txt — patterns for temporary pages
User-agent: *

# Webinars and events
Disallow: /webinars/
Disallow: /events/draft-
Disallow: /landing/test-

# Mockups and previews
Disallow: /_preview/
Disallow: /mockups/
Disallow: /demo/

# A/B tests and experiments
Disallow: /*?variant=
Disallow: /*?experiment=
Disallow: /*?ab_test=

# Template preview parameters
Disallow: /*?preview=
Disallow: /*?draft=
Disallow: /*?revision=

Index de sitemaps à grande échelle

Avec des millions d'URL, un sitemap XML unique n'est pas praticable : il est limité à 50 000 URL et 50 Mo. Un index de sitemaps est un fichier de sommaire qui pointe vers des sitemaps enfants. Il permet de structurer les priorités et d'orienter le budget là où il est le plus utile.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <!-- Priority sections — crawled first -->
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-05-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-categories.xml</loc>
    <lastmod>2026-05-15</lastmod>
  </sitemap>
  <!-- Lower-priority sections -->
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-05-10</lastmod>
  </sitemap>
  <!-- Do NOT include noindex pages or duplicates! -->
</sitemapindex>

• Répartissez les sitemaps par type de contenu : produits, catégories, blog, pages statiques, chacun dans un fichier séparé. Vous verrez ainsi les statistiques d'indexation par section dans la GSC.
• Gardez lastmod honnête : lastmod signale au robot la fraîcheur du contenu. Indiquez la date de la dernière modification réelle, pas la date du jour, sinon le robot cessera de se fier à ce signal.
• Excluez les URL bloquées : les pages en noindex ou en Disallow ne doivent pas figurer dans le sitemap, car elles envoient des signaux contradictoires au robot.
• Limite par sitemap enfant : chaque fichier enfant est limité à 50 000 URL ou 50 Mo (compressé). Découpez en plusieurs parties au-delà : sitemap-products-1.xml, sitemap-products-2.xml.

Configuration du serveur et limitation de débit

Le serveur influence le budget de crawl dans les deux sens : des réponses lentes poussent Googlebot à réduire son intensité de crawl, tandis que les erreurs 5xx obligent le robot à attendre et à gaspiller du temps en nouvelles tentatives. Optimiser le serveur améliore directement l'efficacité du crawl.

# Nginx: return 429 when any crawler sends too many requests
limit_req_zone $http_user_agent zone=crawlers:10m rate=10r/s;

location / {
    limit_req zone=crawlers burst=20 nodelay;
    limit_req_status 429;
    # ... other settings
}

Indicateurs clés et suivi

Le budget de crawl exige un suivi continu : un déploiement peut exposer par accident des milliers de nouvelles URL paramétrées. Mettez en place un tableau de bord hebdomadaire et une revue mensuelle des indicateurs suivants.

• Hebdomadaire : comparez les requêtes de crawl dans la GSC entre la semaine en cours et la précédente. Un pic soudain signale de nouveaux doublons introduits par un déploiement récent.
• Mensuel : vérifiez dans la GSC → Pages la mention « Détectée, actuellement non indexée ». Une hausse alors que la taille du site reste stable signale un problème de budget de crawl.
• Après chaque déploiement majeur : lancez Screaming Frog sur le site et contrôlez le nombre d'URL uniques. Comparez-le au relevé précédent.
• Trimestriel : analyse complète des logs sur 30 jours. Recherchez les nouveaux modèles d'URL paramétrées introduits par le code mis à jour.
• Alertes : configurez une notification si les réponses 5xx dépassent 1 % de l'ensemble des requêtes de Googlebot sur une même journée.

Gains rapides et feuille de route

L'optimisation du budget de crawl n'est pas une tâche ponctuelle, c'est un processus. Découpez le travail entre les gains rapides (effet en 1 à 2 semaines) et les changements structurels (1 à 3 mois).

Liste de contrôle des gains rapides

• noindex ajouté à tous les gabarits de pages temporaires (webinaires, maquettes, démos)
• Disallow pour ?preview=, ?draft=, ?sessionid=, ?utm_ dans robots.txt
• Canonical vers les URL propres sur toutes les pages paramétrées (tri, pagination à partir de la page 2)
• Pages en noindex et en Disallow retirées du sitemap
• Index de sitemaps découpé par section, avec des lastmod fiables
• Chaînes de redirections réduites à un seul saut
• 404 dans les logs de Googlebot inférieurs à 5 % : liens morts supprimés
• Tableau de bord de suivi hebdomadaire configuré dans la GSC

FAQ