Crawl budget : mythe ou réalité pour votre site

Un site e-commerce de 80 000 URLs dont seulement 35 000 sont indexées. Côté Search Console, le rapport de couverture affiche "Discovered – currently not indexed" sur des milliers de fiches produits stratégiques. Le réflexe : "c'est un problème de crawl budget". Dans 90 % des cas, c'est un raccourci dangereux qui masque le vrai problème.

Ce que Google entend réellement par "crawl budget"

Google a défini le concept dans un article de janvier 2017, puis l'a mis à jour plusieurs fois. La définition officielle décompose le crawl budget en deux mécaniques distinctes : le crawl rate limit et le crawl demand.

Le crawl rate limit est la fréquence maximale à laquelle Googlebot peut crawler un site sans dégrader l'expérience utilisateur. Il est déterminé par la capacité de réponse du serveur. Si votre serveur répond en 50 ms en moyenne, Googlebot peut se permettre de lancer des dizaines de requêtes simultanées. Si le temps de réponse grimpe à 2 secondes, Googlebot réduit le débit pour ne pas surcharger l'infrastructure.

Le crawl demand représente "l'envie" de Google de crawler vos pages. Une URL populaire, fréquemment mise à jour, avec beaucoup de backlinks entrants, génère une demand forte. Une page orpheline, jamais linkée, avec du contenu thin, génère une demand quasi nulle — même si votre serveur pourrait encaisser 1 000 requêtes/seconde.

Le crawl budget réel est le minimum des deux : min(crawl_rate_limit, crawl_demand).

Source officielle : Google Search Central — Crawl budget management

Quand le crawl budget n'est pas votre problème

Gary Illyes de Google l'a dit explicitement : si votre site fait moins de quelques milliers de pages, le crawl budget n'est probablement pas un sujet. Googlebot peut crawler des centaines de pages par jour sur un petit site sans la moindre friction.

Si vos pages ne sont pas indexées, les causes les plus fréquentes sont ailleurs :

• Contenu de qualité insuffisante (thin content, pages quasi-dupliquées)
• Problèmes de rendu JavaScript (le HTML servi ne contient pas le contenu que vous pensez)
• Canonicals mal configurées qui pointent vers d'autres pages
• Directives noindex accidentelles injectées par un plugin ou une logique métier

Vérifiez ces pistes avant d'attaquer le crawl budget. Vous pouvez tester ce que Google voit réellement pour écarter rapidement l'hypothèse d'un problème de rendu.

Quand le crawl budget devient un vrai problème : scénario concret

Prenons un cas réel fréquent. Un marketplace B2B avec 120 000 URLs indexables :

• 45 000 fiches produits
• 30 000 pages de catégorie (dont 18 000 générées par la navigation facettée)
• 12 000 pages vendeur
• 35 000 URLs parasites : pages de recherche interne indexables, filtres à paramètres, paginations profondes

Le site tourne sur une application Next.js en SSR, hébergée sur un cluster de 4 instances. Temps de réponse moyen : 320 ms. Le crawl de Googlebot observé dans les logs serveur : environ 8 000 pages/jour.

À ce rythme, il faut 15 jours pour que Googlebot parcourt l'ensemble du site. Sauf que 35 000 de ces URLs sont des impasses — des pages de résultats de recherche interne, des combinaisons de filtres absurdes (couleur=bleu&taille=XL&marque=tous), des paginations vers des listings vides.

Résultat : les 45 000 fiches produits stratégiques ne sont crawlées en moyenne qu'une fois toutes les 6 semaines. Les nouvelles fiches mettent 3 à 4 semaines avant d'être indexées. Sur un marché concurrentiel, c'est une éternité.

Voici les données observées dans les logs :

Segment d'URL	Nombre d'URLs	Crawl Googlebot/jour	Fréquence de crawl
Fiches produits	45 000	1 200	~1× / 37 jours
Catégories légitimes	12 000	800	~1× / 15 jours
Facettes parasites	18 000	3 500	~1× / 5 jours
Recherche interne	15 000	1 800	~1× / 8 jours
Pages vendeur	12 000	500	~1× / 24 jours
Pagination profonde	20 000	200	~1× / 100 jours

Le constat est brutal : 66 % du crawl quotidien est gaspillé sur des URLs sans valeur SEO. C'est un cas où le crawl budget est un vrai problème — pas parce que Googlebot ne crawle "pas assez", mais parce qu'il crawle les mauvaises pages.

Diagnostiquer le gaspillage de crawl : outils et méthodologie

Analyse des logs serveur

L'outil le plus fiable reste l'analyse de logs. Screaming Frog Log File Analyser, ou un pipeline ELK (Elasticsearch, Logstash, Kibana), vous donne la vision exacte de ce que Googlebot a crawlé.

Extraire les hits Googlebot depuis des logs Apache ou Nginx :

# Extraire les requêtes Googlebot des logs Nginx sur les 7 derniers jours
zcat /var/log/nginx/access.log.*.gz | \
  grep -i "googlebot" | \
  awk '{print $7}' | \
  sort | uniq -c | sort -rn | head -50

# Variante : compter les hits Googlebot par répertoire d'URL
zcat /var/log/nginx/access.log.*.gz | \
  grep -i "googlebot" | \
  awk '{print $7}' | \
  sed 's/\?.*//g' | \
  awk -F'/' '{print "/"$2"/"$3}' | \
  sort | uniq -c | sort -rn | head -30

Ce script vous donne immédiatement le top des répertoires crawlés. Si /search/, /filter/ ou /tag/ dominent le classement, vous avez identifié la fuite.

Search Console : rapport d'exploration

Le rapport "Paramètres d'exploration" et les "Statistiques d'exploration" dans Search Console fournissent des données complémentaires :

• Nombre total de requêtes d'exploration par jour : la tendance sur 90 jours révèle si Googlebot augmente ou réduit sa présence.
• Temps moyen de téléchargement : s'il dépasse 500 ms, votre crawl rate limit est probablement bridé.
• Réponses par type de code HTTP : un volume élevé de 301/302 ou 404 indique que Googlebot perd du temps sur des redirections ou des pages mortes.

Screaming Frog pour la cartographie

Un crawl Screaming Frog en mode "spider" avec un user-agent Googlebot vous donne la structure de liens internes telle que Googlebot la perçoit. Configurez-le pour respecter le robots.txt et activez le rendu JavaScript si votre site en dépend.

Le point clé : croisez les données du crawl Screaming Frog (pages découvertes via linking interne) avec les données de logs (pages réellement crawlées par Google). L'écart révèle deux catégories de problèmes :

1. Pages dans le crawl SF mais absentes des logs : pages mal linkées ou trop profondes, que Googlebot ne découvre jamais.
2. Pages dans les logs mais absentes du crawl SF : URLs découvertes via le sitemap ou des backlinks externes, potentiellement des pages orphelines.

Les leviers techniques pour optimiser le crawl budget

Robots.txt : le premier filtre

Le fichier robots.txt reste le levier le plus direct pour empêcher Googlebot de gaspiller son temps. Attention : Disallow n'empêche pas l'indexation (une URL bloquée par robots.txt peut apparaître dans l'index si des liens pointent vers elle). Mais il empêche le crawl, ce qui est exactement l'objectif ici.

# robots.txt — Exemple pour un e-commerce avec facettes parasites
User-agent: Googlebot

# Bloquer les pages de recherche interne
Disallow: /search
Disallow: /recherche

# Bloquer les combinaisons de filtres facettés
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*?sort=
Disallow: /*&color=
Disallow: /*&size=
Disallow: /*&sort=

# Bloquer la pagination profonde (au-delà de page 5)
# Note : impossible nativement dans robots.txt, nécessite un pattern matching limité
# Alternative : gérer via meta robots noindex + nofollow sur les pages > 5

# Autoriser le CSS/JS (essentiel pour le rendu)
Allow: /assets/
Allow: /_next/

Sitemap: https://www.marketplace-b2b.com/sitemap-index.xml

Un piège classique : bloquer /assets/ ou les fichiers JS/CSS dans robots.txt. Googlebot ne peut alors plus rendre vos pages, ce qui dégrade potentiellement l'indexation de tout le site. Vérifiez toujours avec le test d'URL en direct de Search Console après modification du robots.txt.

Balises meta robots et X-Robots-Tag

Pour les URLs que vous ne pouvez pas bloquer proprement via robots.txt (par exemple, des paramètres dynamiques complexes), les directives meta robots offrent un contrôle plus fin. La combinaison noindex, follow permet à Googlebot de crawler la page (et de suivre les liens qu'elle contient) sans l'ajouter à l'index.

Pour les fichiers non-HTML (PDFs, flux JSON), utilisez le header HTTP X-Robots-Tag :

# Configuration Nginx : X-Robots-Tag sur les résultats de recherche interne
location /search {
    add_header X-Robots-Tag "noindex, nofollow" always;
    proxy_pass http://app_backend;
}

# Noindex sur les pages de pagination au-delà de la page 3
location ~ ^/category/.+/page/([4-9]|[1-9][0-9]+)$ {
    add_header X-Robots-Tag "noindex, follow" always;
    proxy_pass http://app_backend;
}

Le trade-off : noindex n'empêche pas Googlebot de crawler la page. Il la visite, constate le noindex, et la retire de l'index. Le crawl est quand même consommé. C'est pourquoi le robots.txt est préférable pour les gros volumes de pages parasites — il bloque le crawl en amont.

Architecture de liens internes et profondeur de crawl

Googlebot suit un modèle de crawl basé sur la profondeur et la popularité des liens. Une page à 1 clic de la homepage sera crawlée bien plus fréquemment qu'une page à 6 clics de profondeur.

Pour un catalogue produit volumineux, la pagination classique crée un problème mathématique simple : si une catégorie contient 2 000 produits affichés par 20, il faut 100 pages de pagination. La page 100 est à 100 clics de la première page de catégorie. Googlebot l'abandonnera probablement en route.

Solutions techniques concrètes :

1. Pagination à accès rapide : ajoutez des liens vers les pages intermédiaires (page 10, 20, 30...) pour réduire la profondeur maximale.

2. Sitemap exhaustif et segmenté : le sitemap ne remplace pas le linking interne, mais il offre un chemin alternatif de découverte.

<!-- sitemap-products-electronics.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.marketplace-b2b.com/produit/capteur-pression-industriel-sp400</loc>
    <lastmod>2026-02-28</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
  </url>
  <url>
    <loc>https://www.marketplace-b2b.com/produit/variateur-frequence-vf200</loc>
    <lastmod>2026-02-25</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
  </url>
  <!-- ... 5000 URLs max par fichier sitemap -->
</urlset>

Segmentez vos sitemaps par type de contenu (produits, catégories, pages vendeurs) pour faciliter le suivi dans Search Console. Le rapport "Sitemaps" vous indiquera exactement combien d'URLs soumises sont indexées par segment.

3. Hubs de liens internes : créez des pages intermédiaires qui agrègent les liens vers vos pages profondes. Une page "Tous les capteurs industriels" qui link vers les 200 fiches produits de cette sous-catégorie réduit la profondeur moyenne de 6 à 3 clics.

Temps de réponse serveur : le goulot d'étranglement ignoré

C'est probablement le levier le plus sous-estimé. Google a explicitement documenté que le crawl rate limit s'ajuste en fonction de la réponse serveur. Un site qui répond en 100 ms sera crawlé avec beaucoup plus d'agressivité qu'un site qui met 1,5 seconde par requête.

Reprenons le scénario de notre marketplace. Avec un TTFB moyen de 320 ms, Googlebot crawle environ 8 000 pages/jour. Si l'équipe technique réduit le TTFB à 120 ms (via mise en cache, optimisation des requêtes DB, CDN pour les assets), le crawl quotidien peut grimper à 15 000-20 000 pages/jour — sans aucune autre modification.

Vérifiez votre TTFB spécifiquement pour Googlebot. Le user-agent Googlebot ne bénéficie pas toujours du cache CDN si celui-ci est configuré pour ne cacher que les requêtes avec certains headers. Testez :

# Simuler une requête Googlebot et mesurer le TTFB
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
  -H "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://www.marketplace-b2b.com/produit/capteur-pression-industriel-sp400

# Comparer avec une requête utilisateur standard
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0" \
  https://www.marketplace-b2b.com/produit/capteur-pression-industriel-sp400

Si l'écart est significatif, votre couche de cache ou votre CDN traite Googlebot différemment — un problème plus fréquent qu'on ne le croit, notamment avec les CDN qui appliquent du bot management agressif.

Côté performance serveur, l'optimisation des images et la gestion du lazy loading impactent aussi indirectement le crawl : des pages plus légères se servent plus vite, et Googlebot passe moins de temps sur le rendu.

Les erreurs classiques qui gaspillent le crawl budget

Chaînes de redirections

Une chaîne A → B → C → D force Googlebot à effectuer 4 requêtes HTTP pour atteindre la page finale. Multipliez par 5 000 URLs redirigées et vous venez de gaspiller 15 000 crawls pour rien.

Auditez vos redirections régulièrement. Screaming Frog détecte nativement les chaînes de redirections. Corrigez-les pour pointer directement vers la destination finale.

Pages soft 404

Une page qui retourne un code 200 mais affiche "Aucun résultat" ou un contenu vide est une soft 404. Google la détecte souvent, mais pas toujours immédiatement. En attendant, Googlebot la recrawle périodiquement, gaspillant du budget sur une page sans contenu.

Renvoyez un vrai code 404 ou 410 quand une page n'a plus de contenu. Google traite les 410 (Gone) comme un signal plus fort que le 404 pour retirer rapidement une URL de l'index.

Paramètres d'URL non maîtrisés

Les UTM, les paramètres de tracking, les IDs de session — autant de variations d'URL que Googlebot peut percevoir comme des pages distinctes. Assurez-vous que chaque page avec paramètres possède une balise canonical pointant vers l'URL propre.

Sitemaps contenant des URLs non indexables

Un sitemap qui référence des URLs en 404, en redirection, ou avec une directive noindex envoie un signal contradictoire à Googlebot. Nettoyez vos sitemaps pour ne contenir que des URLs retournant un 200, sans directive noindex, avec un canonical auto-référent.

Monitorer le crawl dans la durée

Le crawl budget n'est pas un problème que vous réglez une fois. Les sites vivants génèrent en permanence de nouvelles URLs (nouveaux produits, nouvelles pages de filtre, nouveau contenu éditorial). Sans surveillance continue, les régressions s'accumulent silencieusement.

Les signaux à surveiller :

• Ratio pages crawlées/jour dans Search Console : une baisse progressive indique soit un problème de performance serveur, soit une perte de crawl demand.
• Taux de pages "Discovered – currently not indexed" : s'il augmente, le crawl ou la qualité perçue pose problème.
• Apparition de nouvelles URLs parasites dans les logs : un déploiement peut accidentellement rendre indexables des milliers de pages de filtres.

Un outil de monitoring SEO technique comme SEOGard détecte automatiquement ces régressions — une directive meta robots qui disparaît après un déploiement, un canonical qui change, des pages qui passent soudainement en 404. Sur un site de 50 000 pages, vérifier manuellement n'est pas une option viable.

Le cas spécifique du JavaScript et du crawl

Les sites en SPA (React, Vue, Angular) sans SSR posent un défi particulier pour le crawl budget. Googlebot utilise un service de rendu basé sur Chrome headless, mais ce rendu est coûteux en ressources côté Google. Google a documenté que le rendu JavaScript est différé — la page est d'abord crawlée en HTML brut, puis placée dans une file d'attente pour le rendu.

Ce double passage (crawl + render) consomme effectivement plus de "budget" qu'une page HTML statique ou pré-rendue en SSR. Sur un site de grande envergure, le passage au SSR ou au SSG (Static Site Generation) peut significativement accélérer l'indexation.

Pour vérifier si Google rend correctement vos pages JavaScript, l'outil "Inspection d'URL" de Search Console montre le HTML rendu tel que Google le voit. Comparez-le avec le HTML source pour identifier les écarts. L'article sur ce que Google voit réellement sur votre site détaille cette méthodologie.

Quand ne PAS optimiser le crawl budget

Le crawl budget est un sujet séduisant parce qu'il donne l'impression de contrôler un paramètre technique "secret". En réalité, l'optimiser sur un site de 500 pages est une perte de temps.

Ne vous préoccupez pas du crawl budget si :

• Votre site fait moins de 10 000 pages indexables
• Votre ratio pages indexées / pages soumises dans Search Console dépasse 90 %
• Le rapport "Statistiques d'exploration" montre un crawl stable ou en croissance
• Vos pages stratégiques apparaissent rapidement dans l'index après publication (< 48h)

Concentrez vos efforts sur la qualité du contenu, la performance technique (Core Web Vitals, LCP, INP), et l'architecture de l'information. Ce sont des leviers qui ont un impact mesurable sur le ranking, quelle que soit la taille de votre site.

Le crawl budget devient un vrai sujet à partir du moment où vous avez un grand site (10K+ pages) avec un ratio d'indexation faible et où l'analyse des logs confirme un gaspillage sur des URLs non stratégiques. Sans ces trois conditions réunies, le crawl budget reste un mythe pour votre site — un concept théoriquement réel mais pratiquement non limitant.

Le vrai enjeu n'est pas que Googlebot crawle plus, c'est qu'il crawle mieux. Nettoyez les URLs parasites, accélérez vos réponses serveur, structurez votre linking interne, et surveillez les régressions en continu. Le crawl budget se résout rarement par une action unique — c'est un travail d'hygiène technique permanent.