La plupart des guides sur le crawl budget empilent les techniques d’optimisation sans poser la question qui décide de tout : votre site a-t-il seulement un problème d’exploration ? La documentation de Google répond par un seuil chiffré, et ce seuil écarte l’immense majorité des sites. Autant le vérifier avant d’ouvrir le moindre chantier.
Le crawl budget, c’est quoi au juste ?
Le crawl budget désigne le volume d’URL que Googlebot accepte d’explorer sur un site pendant une période donnée. Il combine deux facteurs : la capacité d’exploration, plafonnée par la santé de votre serveur, et la demande d’exploration, dictée par la popularité et la fraîcheur de vos pages.
Google détaille ces deux composantes dans son guide « Gérer le budget d’exploration ». La capacité plafonne le nombre de connexions simultanées que Googlebot s’autorise : elle monte quand le serveur répond vite et sans erreur, elle redescend dès que les temps de réponse se dégradent. La demande dépend, elle, de l’intérêt que Google porte à vos URL : pages populaires, contenus fraîchement mis à jour, adresses découvertes via des liens.
Le budget n’est donc pas un quota fixe qu’on dépenserait. Il s’ajuste en continu. Un serveur rapide augmente la capacité disponible ; un inventaire noyé de doublons fait chuter la demande, Google apprenant au fil de ses visites que la plupart des URL n’apportent rien de neuf.
Votre site est-il concerné ?
Google fixe un périmètre explicite. Son guide vise deux profils : les sites d’environ un million de pages uniques ou plus dont le contenu bouge chaque semaine, et les sites de plus de 10 000 pages dont le contenu change chaque jour. Il ajoute une phrase que les guides français citent rarement : si vos pages semblent explorées le jour même de leur publication, vous n’avez pas besoin de vous en préoccuper.
En audit, nous voyons ce décalage tous les mois. Des sites B2B de 150 à 300 pages s’inquiètent de leur budget d’exploration alors que Googlebot pourrait parcourir tout leur inventaire plusieurs fois par jour. Sur ce profil, quand des pages restent hors index, la cause est ailleurs : contenu jugé faible, doublons internes, signaux contradictoires entre canonical et maillage. Un audit technique tranche la question en quelques jours, données à l’appui.
Le sujet devient sérieux pour les catalogues e-commerce à navigation à facettes, les marketplaces, les sites d’annonces et les médias à fort volume d’archives : tout site dont le nombre d’URL explorables dépasse de plusieurs ordres de grandeur le nombre de pages utiles.
L’erreur qu’on corrige le plus souvent : le noindex ne libère pas de budget
On lit partout qu’il faut poser un noindex sur les facettes et les pages sans valeur pour économiser l’exploration. En réalité, le noindex ne libère aucun budget de crawl. Pour lire la balise, Googlebot doit d’abord charger la page, donc dépenser une requête. Google le déconseille d’ailleurs dans son guide : le robot demandera quand même la page, puis la retirera de l’index en voyant la balise, ce qui gaspille du temps d’exploration.
La règle que nous appliquons : pour économiser l’exploration, on bloque en amont, dans le robots.txt, les motifs d’URL sans valeur (paramètres de tri, filtres, recherche interne). Le noindex garde son rôle, mais ailleurs : retirer de l’index une page qui doit rester explorable, pas assécher un gisement d’URL parasites.
Où part le budget : le cas e-commerce
Le gaspillage type se joue sur les catalogues e-commerce. Une navigation à facettes combine tri, filtres et pagination : trois filtres de dix valeurs et quatre options de tri suffisent à produire des milliers de combinaisons d’URL pour le même ensemble de produits, chaque combinaison étant ensuite multipliée par la pagination. Ajoutez la recherche interne laissée indexable, les variantes déclinées en adresses distinctes et les calendriers infinis : Googlebot passe l’essentiel de son temps sur des pages qu’aucun visiteur n’atteindra.
Sur les catalogues que nous auditons, le motif le plus fréquent reste ce bloc d’URL à paramètres qui gonfle les logs sans jamais convertir. Les principaux postes de gaspillage :
- Facettes et paramètres de tri ou de filtre : explosion d’URL à paramètres dans les logs. Remède prioritaire : blocage des motifs dans le robots.txt.
- Doublons non canonicalisés (variantes, HTTP contre HTTPS, casse d’URL) : plusieurs versions explorées, indexation instable. Remède : balise canonique et maillage interne pointant une seule version. Attention, la canonique consolide l’indexation, pas le crawl : les variantes restent explorées.
- Soft 404 (pages vides renvoyant un code 200) : signalées dans la Search Console, elles continuent d’être explorées et gaspillent le budget, comme le rappelle le guide de Google.
- Chaînes de redirections : chaque saut avant d’atteindre un code 200 consomme une requête. Remède : rediriger en un seul saut, corriger les liens internes.
- Recherche interne indexable : les URL de type /recherche?q= à bloquer via robots.txt.
- Sitemap pollué : URL en erreur ou dates lastmod incohérentes qui déclenchent des re-explorations inutiles.
Les leviers qui comptent, par ordre d’impact
Une fois le diagnostic posé, les correctifs se hiérarchisent. Par impact décroissant sur un gros site :
- Bloquer les URL sans valeur au bon endroit. Le robots.txt coupe l’exploration en amont sur les paramètres de tri, les filtres et la recherche interne. C’est le levier le plus direct.
- Éliminer soft 404, erreurs serveur et chaînes de redirections. Renvoyer les bons codes, rediriger en un saut, mettre à jour les liens internes qui pointent encore vers d’anciennes adresses. Sur les sites qui ont enchaîné les refontes, ce nettoyage libère à lui seul une part visible du crawl.
- Accélérer le serveur. Google l’indique : si le site répond vite un moment, sa limite de capacité monte et le robot ouvre davantage de connexions. Les 5xx et les délais d’attente produisent l’effet inverse. Sur un gros catalogue, le temps de réponse des pages HTML est un chantier à part entière.
- Tenir le sitemap propre, avec un lastmod fiable. Google recommande d’indiquer la vraie date de dernière modification : cela l’aide à prioriser les contenus récents plutôt qu’à revisiter tout l’inventaire. Un sitemap qui liste des URL en erreur brouille le signal.
- Réduire la profondeur. Une URL enfouie à huit clics de l’accueil est découverte tard et revisitée rarement. Les pages reliées depuis des hubs forts sont explorées plus souvent que les quasi-orphelines.
Ce qui ne sert à rien
Trois demandes reviennent souvent et ne produisent aucun effet mesurable. Soumettre ses URL en masse dans la Search Console ne déclenche pas une exploration durable de l’inventaire. La directive crawl-delay du robots.txt est ignorée : Google précise que cette règle non standard n’est pas traitée par ses robots. Enfin, être exploré plus souvent ne garantit pas un meilleur classement : Google indique qu’une vitesse d’exploration accrue n’entraîne pas nécessairement de meilleures positions. L’exploration conditionne l’entrée dans l’index ; le classement se joue après.
Lire ses statistiques d’exploration
Le point d’entrée est le rapport Statistiques d’exploration de la Search Console. Il donne le volume de requêtes quotidien de Googlebot, le temps de réponse moyen, la répartition par code de réponse, par type de fichier et par objectif (découverte ou actualisation). Trois signaux méritent l’œil : une chute du volume de requêtes, une hausse du temps de réponse moyen, une montée des codes 5xx ou des soft 404. Ce sont les marqueurs d’un serveur qui plafonne ou d’un inventaire qui se pollue.
Au-delà d’une certaine taille, ce rapport ne suffit plus : il agrège les totaux et n’affiche que des exemples d’URL. L’analyse des logs serveur reste la seule source exhaustive pour savoir quelles URL Googlebot visite, à quelle fréquence et avec quels codes. Croiser les hits du robot avec la liste des pages utiles fait ressortir le gaspillage en quelques requêtes. Un crawler comme Screaming Frog complète le tableau en simulant le parcours du robot, révélant chaînes de redirections et URL paramétrées avant même que Googlebot ne les rencontre.
Questions fréquentes
À quelle fréquence Googlebot doit-il explorer mon site ?
Il n’existe pas de fréquence idéale. Google explore souvent les sites dont le contenu important change souvent, quelle que soit leur taille, et espace ses passages sur les pages stables. Une page rarement revisitée n’est pas un problème si elle ne change pas. Surveillez plutôt les variations brutales de volume dans vos statistiques d’exploration.
Le crawl budget s’applique-t-il à Bing ou aux robots d’IA comme GPTBot ?
Le terme « budget d’exploration » vient de Google et décrit le comportement de Googlebot. Les autres robots, de Bingbot aux crawlers d’IA comme GPTBot ou ClaudeBot, explorent selon leurs propres règles et ne publient pas d’équivalent documenté. Les principes de fond, serveur rapide et peu d’URL parasites, leur profitent aussi, mais le cadre chiffré reste propre à Google.
Bloquer une page dans le robots.txt la désindexe-t-elle ?
Non. Une URL bloquée peut rester dans l’index si d’autres pages pointent vers elle, souvent affichée sans description. Le robots.txt empêche l’exploration, pas l’indexation. Pour sortir une page de l’index, il faut la laisser explorable puis lui appliquer un noindex, ou passer par l’outil de suppression de la Search Console.
Combien de temps avant que Google explore une nouvelle page ?
Cela varie de quelques heures à plusieurs semaines, selon la popularité du site, la profondeur de la page et la qualité du maillage. Sur un petit site sain, la publication du jour est souvent explorée dans la journée. L’inspection d’URL de la Search Console permet de demander une exploration, sans garantie de délai.
Vous gérez un catalogue volumineux et vos statistiques d’exploration racontent une histoire que vous n’arrivez pas à lire ? Parlez-en avec un consultant Getknown : nous établissons d’abord si le crawl budget est votre vrai sujet, avant de proposer le moindre chantier.
Article rédigé par Yonel Sasson, Getknown, agence SEO et GEO.