Crawl budget : comment l'optimiser pour les gros sites
Comment Google définit le crawl budget, comment le mesurer avec les logs et Search Console, et quelles directives appliquer à un e-commerce aux millions d'URL.

Le crawl budget, ou budget d’exploration, correspond à l’ensemble des URL que Google peut et veut explorer sur un site dans un laps de temps donné. Pour la grande majorité des sites, ce n’est pas un sujet : Google explore sans difficulté quelques milliers de pages. Il devient critique sur les gros sites, typiquement les catalogues e-commerce qui génèrent des centaines de milliers, voire des millions d’URL par le jeu des filtres, des tris et des paramètres. Ce guide explique comment Google définit ce budget, comment le mesurer, et quelles directives appliquer pour que Googlebot passe son temps sur les pages qui comptent.
01Crawl budget : définition selon Google
Le crawl, ou exploration, est l’étape où un robot (un crawler) télécharge les pages d’un site pour les découvrir ou les mettre à jour. L’indexation vient ensuite : Google analyse la page et décide de la conserver ou non dans son index. Le crawl budget se situe en amont : une page qui n’est jamais explorée ne peut pas être indexée.
On confond parfois crawling et scraping. Le crawling consiste à parcourir des pages en suivant des liens pour les découvrir et les mettre à jour, comme le fait un moteur de recherche. Le scraping consiste à extraire des données précises d’une page (prix, coordonnées, textes) pour les réutiliser ailleurs. Un même robot peut faire les deux, mais seul le premier relève du crawl budget au sens de Google.
Dans sa documentation sur la gestion du budget d’exploration, désormais regroupée sur son site consacré au crawling et mise à jour le 22 juillet 2026, Google définit le crawl budget comme « l’ensemble des URL que Google peut et veut explorer ». Deux composantes le déterminent :
- La limite de capacité d’exploration : elle borne le temps total pendant lequel votre serveur maintient des connexions ouvertes pour Google, en tenant compte du nombre de connexions parallèles et de leur durée. Si le serveur répond vite et sans erreur, la limite augmente ; s’il ralentit ou renvoie des erreurs, elle diminue.
- La demande d’exploration : pour Googlebot, elle varie selon la taille du site, sa fréquence de mise à jour, la qualité et la pertinence des pages par rapport aux autres sites. Google cite notamment l’inventaire perçu, la popularité et la fraîcheur des contenus.
Précision importante apportée par cette documentation : la limite de capacité est partagée entre tous les robots de Google. Chaque robot, par exemple AdsBot ou celui de Google Shopping, a sa propre demande, et une forte demande de l’un peut réduire la capacité disponible pour les autres. Autrement dit, le budget n’est pas un quota fixe attribué à votre site, mais un équilibre dynamique entre ce que votre serveur supporte et ce que Google juge utile d’explorer.
02Qui doit vraiment s’en préoccuper ?
Google donne lui-même des ordres de grandeur, en précisant qu’il s’agit d’estimations et non de seuils exacts. Son guide s’adresse :
- aux grands sites de plus d’un million de pages uniques dont le contenu change modérément, environ une fois par semaine ;
- aux sites moyens ou grands, à partir de 10 000 pages uniques, dont le contenu change très rapidement, chaque jour ;
- aux sites dont une grande partie des URL apparaît comme « Détectée, actuellement non indexée » dans Search Console.
Un site vitrine de 200 pages ou un blog de 1 000 articles n’a donc pas de problème de crawl budget au sens strict. S’il a des pages non indexées, la cause est ailleurs : qualité, doublons, maillage, directives techniques. C’est le sujet de notre guide sur l’indexation Google et les raisons pour lesquelles vos pages ne sont pas indexées.
À l’inverse, un e-commerce de 50 000 produits peut exposer plusieurs millions d’URL si chaque combinaison de filtres (couleur, taille, prix, marque, tri) produit une adresse distincte. C’est ce volume d’URL explorables, bien plus que le nombre de produits, qui crée le problème.
Quelques symptômes doivent vous alerter, même sous les seuils indiqués par Google :
- de nouvelles fiches produits ou de nouveaux articles mettent plusieurs semaines à apparaître dans les résultats ;
- des prix ou des disponibilités modifiés restent affichés dans leur ancienne version dans Google ;
- le volume de pages « Détectée, actuellement non indexée » augmente régulièrement ;
- les logs montrent que Googlebot passe l’essentiel de son temps sur des URL de filtres, de tri ou de paramètres.
03Mesurer et estimer son crawl budget
Le rapport Statistiques d’exploration
Dans Search Console, le rapport Statistiques d’exploration (dans les paramètres de la propriété) couvre les 90 derniers jours. Il affiche le nombre total de requêtes d’exploration, le volume téléchargé et le temps de réponse moyen, puis les ventile par code de réponse, type de fichier, objectif (découverte de nouvelles URL ou actualisation d’URL connues) et type de Googlebot. La section sur l’état de l’hôte signale les problèmes de récupération du robots.txt, de résolution DNS et de connexion au serveur.
Trois signaux méritent une attention particulière : une hausse du temps de réponse moyen, une part importante de requêtes vers des URL en erreur ou redirigées, et une proportion de découverte très faible sur un site qui publie beaucoup.
L’analyse de logs serveur
Le rapport Search Console donne une vue agrégée. Les logs serveur montrent précisément quelles URL Googlebot demande, à quelle fréquence et avec quel résultat. Sur un gros site, c’est l’outil de diagnostic principal. Après avoir vérifié que les requêtes proviennent bien de Google (vérification DNS inverse ou plages d’adresses IP publiées par Google), segmentez les URL explorées par gabarit et répondez à quatre questions :
- Quelle part du crawl va aux pages stratégiques (catégories, fiches produits) et quelle part aux URL de filtres, de tri, de recherche interne ou de paramètres de suivi ?
- Quelles pages importantes ne sont jamais ou rarement explorées ?
- Combien de requêtes aboutissent à des 3xx, 4xx ou 5xx ?
- Combien de temps s’écoule entre la publication d’une page et sa première exploration ?
Un calcul simple pour estimer le cycle d’exploration
Il n’existe pas de formule officielle, mais une estimation utile consiste à diviser le nombre d’URL que vous souhaitez voir explorées par le nombre moyen de pages explorées par jour, lu dans les Statistiques d’exploration ou dans les logs. Si un catalogue compte 400 000 URL utiles et que Googlebot en explore 20 000 par jour, dont la moitié sur des URL inutiles, il faut en théorie 40 jours pour repasser sur l’ensemble des pages utiles. Supprimer ce gaspillage ramènerait ce cycle à environ 20 jours, et le réduire de moitié à environ 27 jours, sans que Google explore davantage. Cet indicateur reste approximatif, car Google ne répartit pas son exploration de façon uniforme, mais il parle aux équipes et permet de suivre les progrès.
Pour piloter dans la durée, suivez un petit tableau de bord de cinq indicateurs : nombre de requêtes de Googlebot par jour, part des requêtes vers des URL utiles, part des codes autres que 200, temps de réponse moyen, et délai médian entre la publication d’une page et sa première exploration. Ces cinq chiffres suffisent à savoir si vos actions produisent un effet.
04Optimiser le crawl d’un gros site e-commerce
1. Maîtriser la navigation à facettes
Google consacre une page de documentation dédiée aux URL de navigation à facettes, mise à jour en décembre 2025, et rappelle que leur exploration coûte souvent beaucoup de ressources. Ses recommandations :
- Si les combinaisons de filtres n’ont pas vocation à être indexées, bloquez leur exploration avec des règles disallow dans le robots.txt, ou utilisez des fragments d’URL, que Google n’explore généralement pas.
- Les balises canonical et l’attribut nofollow sont jugés en général moins efficaces sur le long terme pour limiter ce crawl.
- Si certaines facettes doivent être indexables (par exemple « chaussures de running femme »), utilisez le séparateur standard « & », gardez un ordre de filtres constant, évitez les filtres en double et renvoyez un code 404 quand une combinaison ne donne aucun résultat.
La bonne pratique consiste à sélectionner quelques combinaisons correspondant à une vraie demande de recherche, à leur donner une URL propre et du contenu dédié, et à fermer l’exploration de toutes les autres. Notre guide pratique du robots.txt pour contrôler le crawl de Google détaille la syntaxe des règles et les pièges à éviter.
2. Supprimer les URL inutiles et les doublons
- Paramètres de suivi (campagnes, identifiants de session) : ils ne doivent pas apparaître dans les liens internes.
- Tris et affichages (par prix, par nouveauté, nombre de produits par page) : une seule version explorable par liste.
- Recherche interne : ses pages de résultats n’ont généralement pas à être explorées.
- Variantes de produit : une URL canonique par produit, les variantes étant gérées sans multiplier les adresses explorables quand elles n’ont pas de demande propre.
3. Soigner les codes HTTP et les redirections
Renvoyez un 404 ou un 410 pour les pages définitivement supprimées, éliminez les soft 404 (pages vides ou « produit indisponible » renvoyant un code 200), évitez les chaînes de redirections et mettez à jour les liens internes vers l’URL finale. Pour un produit retiré du catalogue, la redirection vers un produit équivalent ou la catégorie parente n’a de sens que si elle sert réellement l’internaute.
4. Accélérer le serveur et exploiter le cache HTTP
La limite de capacité dépend de la santé du serveur. Un temps de réponse réduit permet à Google d’explorer davantage sans surcharger l’infrastructure. Google recommande aussi de prendre en charge les requêtes conditionnelles : un code 304 Not Modified indique qu’une page n’a pas changé, ce qui évite de retransférer son contenu. En cas de surcharge ponctuelle due à Googlebot, des codes 503 ou 429 temporaires ralentissent l’exploration ; ils ne doivent pas rester en place au-delà d’un ou deux jours, sous peine de voir des URL retirées de l’index.
Pensez aussi aux robots qui ne sont pas ceux de Google. Robots d’outils SEO, robots d’IA et scrapers consomment eux aussi des ressources serveur. Ils n’entament pas directement le budget que Google vous accorde, mais s’ils dégradent le temps de réponse, la limite de capacité accordée à Googlebot peut baisser. Les logs permettent de mesurer leur poids ; le robots.txt ou des règles au niveau du serveur ou du CDN permettent ensuite de décider, robot par robot, de ce que vous autorisez.
5. Tenir des sitemaps propres et un maillage clair
Les sitemaps doivent lister uniquement les URL canoniques, indexables et en 200, avec une date de dernière modification fiable. Sur un gros catalogue, découpez-les par type de page pour suivre leur taux d’indexation séparément. Le maillage interne, lui, oriente la demande d’exploration : une fiche produit accessible en trois clics depuis une catégorie bien liée sera explorée plus souvent qu’une fiche uniquement présente dans le sitemap. Notre guide consacré au sitemap XML, à sa structure, aux erreurs fréquentes et à son automatisation complète ce point.
6. Gérer les produits épuisés et les contenus saisonniers
Un catalogue vit : produits en rupture, fins de série, collections saisonnières. Chaque choix a un effet sur le crawl :
- Rupture temporaire : conservez la page en 200, indiquez la disponibilité dans le contenu et dans les données structurées, proposez des alternatives. Supprimer puis recréer la page gaspille du crawl et fait perdre l’historique.
- Retrait définitif sans équivalent : un 404 ou un 410 permet à Google de cesser progressivement de demander l’URL.
- Retrait avec produit de remplacement : une redirection permanente vers le nouveau modèle, et la mise à jour des liens internes.
- Pages saisonnières (soldes, fêtes) : gardez une URL pérenne mise à jour chaque année plutôt que de créer une nouvelle adresse à chaque saison.
05Ce qu’il ne faut pas faire
- Utiliser noindex pour économiser du budget : Google doit toujours explorer la page pour lire la directive. Le noindex règle un problème d’indexation, pas de crawl.
- Bloquer temporairement des sections dans le robots.txt pour « libérer » du budget : Google précise qu’il ne réaffecte pas ce budget à d’autres pages, sauf si votre site atteint déjà sa limite de capacité.
- Bloquer des ressources nécessaires au rendu (CSS, JavaScript) : Google ne peut plus afficher correctement les pages.
- Compter sur la directive crawl-delay : Google ne la prend pas en charge, et l’outil de limitation de la vitesse d’exploration de Search Console a été retiré le 8 janvier 2024.
- Bloquer par robots.txt des pages déjà indexées que vous voulez désindexer : Google ne pourra plus lire leur noindex. Désindexez d’abord, bloquez ensuite si nécessaire.
- Confondre fréquence de crawl et classement : explorer plus souvent une page ne la fait pas mieux classer. L’objectif est que les pages utiles soient découvertes et actualisées à temps, pas de maximiser un volume de requêtes.
06Automatiser le suivi du crawl
Sur un gros site, le crawl budget se pilote dans la durée. Quelques automatisations suffisent à détecter les dérives avant qu’elles ne coûtent du trafic :
- Traitement quotidien des logs : filtrez les requêtes de Googlebot vérifiées, agrégez-les par gabarit et par code HTTP, et stockez le résultat dans une base ou un Google Sheet.
- Alerte sur la part de gaspillage : un workflow n8n peut calculer chaque jour la proportion de requêtes vers des URL de filtres, de paramètres ou en erreur, et envoyer une alerte si elle dépasse le niveau habituel.
- Suivi de la découverte : comparez chaque jour les nouvelles URL publiées (depuis le CMS ou le sitemap) avec leur première apparition dans les logs, pour mesurer le délai de découverte.
- Contrôle de l’indexation : croisez ces données avec l’état d’indexation d’un échantillon de pages clés via l’API d’inspection d’URL de Search Console, dans la limite de ses quotas.
Exemple illustratif : après la mise en ligne d’un nouveau filtre « promotion », l’alerte signale que la part des requêtes de Googlebot vers les URL de filtres passe en quelques jours d’environ 20 % à plus de la moitié. L’équipe ajoute une règle disallow sur le nouveau paramètre et retire ce filtre des liens explorables. Sans suivi automatisé, la dérive aurait pu passer inaperçue pendant des semaines.
Le crawl budget n’est pas une variable que l’on augmente à volonté. C’est une ressource que l’on protège : moins d’URL inutiles, un serveur rapide, des signaux clairs sur les pages qui comptent. Pour intégrer ce chantier dans votre stratégie globale de référencement, notre page SEO présente l’ensemble de la démarche.
- Google Crawling Infrastructure : Gestion du budget d’exploration - définition du crawl budget, limite de capacité partagée entre les robots de Google, sites concernés, noindex et robots.txt sans effet sur la réaffectation du budget, code 304.
- Google Crawling Infrastructure : Gestion des URL de navigation à facettes - blocage par robots.txt, séparateur « & », ordre constant des filtres et code 404 pour les combinaisons sans résultat.
- Google Crawling Infrastructure : Réduire la vitesse d’exploration de Google - codes 500, 503 ou 429 à ne pas maintenir plus d’un ou deux jours, sous peine de retrait d’URL de l’index.
- Aide Search Console : Rapport Statistiques d’exploration - données des 90 derniers jours ventilées par réponse, type de fichier, objectif et type de Googlebot, avec l’état de l’hôte.
- Search Engine Land : Googlebot crawl rate tool is now gone - retrait de l’outil de limitation de la vitesse d’exploration de Search Console en janvier 2024.
