Le crawl budget ne concerne-t-il vraiment que les très gros sites ?

Qu'est-ce que le crawl budget et pourquoi Google fixe ce seuil à un million d'URLs ?

Le crawl budget désigne le nombre de pages que Googlebot accepte d'explorer sur un site durant une période donnée. Ce quota dépend de deux facteurs principaux : la capacité du serveur à répondre rapidement sans surcharge, et l'intérêt que Google porte au contenu du site.

Martin Splitt fixe la barre à un million d'URLs comme seuil critique. En dessous, les sites disposent généralement d'un budget crawl largement suffisant pour que toutes leurs pages stratégiques soient régulièrement visitées. Au-delà, les mécanismes de priorisation de Google deviennent des contraintes réelles — certaines sections risquent d'être ignorées ou explorées avec des intervalles trop espacés.

Pourquoi tant de SEO s'inquiètent du crawl budget alors que leur site est loin du million de pages ?

Parce que le diagnostic est souvent mal posé. Beaucoup attribuent au crawl budget des problématiques qui relèvent en réalité de défauts techniques : temps de réponse serveur catastrophique, chaînes de redirections interminables, facettes et URLs à paramètres explosant artificiellement le nombre de pages exposées au crawl.

Google ne bloque pas le crawl de votre site de 50 000 fiches produits parce qu'il a décidé de rationner son budget. Il le ralentit parce que votre serveur répond en 2 secondes, ou parce que vous exposez 200 000 URLs générées par des filtres sans valeur ajoutée. Le problème n'est pas le quota — c'est l'infrastructure et l'architecture de l'information.

Quels sont les véritables indicateurs à surveiller en dessous du million d'URLs ?

Au lieu de fantasmer sur le crawl budget, concentrez-vous sur des métriques tangibles. Le taux de crawl des pages stratégiques dans la Search Console, la fréquence de passage de Googlebot sur vos nouvelles publications, les erreurs serveur 5xx détectées lors du crawl.

Si vos pages importantes sont explorées tous les jours ou plusieurs fois par semaine, et que vos nouveaux contenus sont indexés en quelques heures, vous n'avez pas de problème de crawl budget. Si au contraire des URLs clés restent ignorées pendant des semaines, cherchez du côté de l'architecture de maillage interne, des fichiers robots.txt ou sitemaps mal configurés, ou des signaux de qualité faibles qui freinent l'appétit de Google.

• Le crawl budget ne devient critique qu'au-delà du million d'URLs indexables
• En dessous de ce seuil, les ralentissements de crawl proviennent généralement de défauts techniques serveur ou d'une architecture de site défaillante
• Les vrais indicateurs à surveiller : taux de crawl des pages stratégiques, délai d'indexation des nouveaux contenus, erreurs serveur lors du crawl
• Optimiser le crawl budget sur un site de taille moyenne revient souvent à résoudre des problèmes de performances serveur, redirections en chaîne et facettes inutiles
• Prioriser la qualité de l'expérience Googlebot plutôt que la quantité de pages explorées

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Globalement, oui. Les audits terrain confirment que les sites entre 10 000 et 500 000 URLs souffrent rarement de restrictions de crawl budget au sens strict. Quand des pages stratégiques ne sont pas crawlées, l'explication se trouve presque toujours dans des signaux négatifs : pages orphelines sans maillage interne, contenus dupliqués en masse, réponses serveur poussives, directives noindex mal placées.

Là où ça coince, c'est que Martin Splitt ne précise pas combien de temps Google tolère ces défaillances avant de réduire activement le crawl. Un serveur qui renvoie régulièrement des erreurs 503 ou des temps de réponse > 3 secondes verra son crawl throttlé même sur un site de 20 000 pages. La nuance compte : Google ne dit pas que le crawl budget n'existe pas en dessous du million, il dit qu'il ne devrait pas être le facteur limitant — à condition que tout le reste soit propre.

Dans quels cas cette règle du million d'URLs ne s'applique-t-elle pas ?

Premier cas : les sites avec une vélocité de publication extrême. Un média d'actualité produisant 500 articles par jour peut atteindre 180 000 URLs par an, mais si Google ne crawle que toutes les 48h, les news perdent leur pertinence avant indexation. Ici, le problème n'est pas tant le volume total que la fréquence de crawl — et ça, Martin Splitt n'en parle pas.

Deuxième cas : les architectures avec plusieurs sous-domaines ou versions internationales mal gérées. Google alloue son budget par hostname. Si vous fragmentez vos 300 000 pages sur 15 sous-domaines techniques sans logique SEO, chaque sous-domaine se retrouve avec un budget réduit — et certaines sections peuvent être sous-crawlées même si le total reste sous le million.

Troisième cas — et c'est là que ça devient gênant : Google reste évasif sur la définition exacte de ce million. URLs découvertes, URLs dans le sitemap, URLs indexées, URLs en canonical ? La réponse change tout. [À vérifier] Un site avec 200 000 pages canoniques mais 2 millions d'URLs facettées exposées au crawl entre-t-il dans la catégorie des "très gros sites" ?

Quelles nuances faut-il apporter à cette position officielle ?

Google simplifie volontairement pour éviter que chaque webmaster de blog WordPress ne se prenne la tête avec le crawl budget. Mais cette simplification masque des réalités plus complexes. Le crawl budget est une résultante de plusieurs facteurs : popularité du site, autorité perçue, freshness des contenus, santé technique, signaux utilisateurs.

Deux sites de 500 000 pages n'auront pas le même traitement. Un média de référence avec un trafic énorme et des backlinks solides bénéficiera d'un crawl plus généreux qu'un annuaire de faible qualité gonflé artificiellement. Dire que le crawl budget n'est pas un problème en dessous du million, c'est vrai pour un site techniquement irréprochable et doté d'une autorité forte. Pour les autres ? Le seuil réel peut être bien plus bas.

Que faut-il faire concrètement si mon site compte moins d'un million de pages ?

D'abord, arrêtez d'optimiser pour un problème qui n'existe probablement pas. Trop de SEO perdent du temps à disséquer les logs serveur pour traquer le moindre passage de Googlebot, alors que leur vrai sujet est ailleurs : contenus faibles, cannibalisation de mots-clés, structure de silos bancale.

Ensuite, investissez sur ce qui compte vraiment : la santé technique du serveur. Un hébergement capable de répondre en moins de 500ms même sous charge, une gestion propre des caches, des CDN bien configurés. Google crawle plus généreusement un site rapide et stable qu'un site lent, même si ce dernier a peu de pages.

Quelles erreurs éviter pour ne pas créer artificiellement un problème de crawl ?

Première erreur classique : exposer des facettes et filtres sans limite via le maillage interne ou les sitemaps. Vous transformez 10 000 fiches produits en 300 000 URLs combinatoires que Googlebot va essayer d'explorer, diluant ainsi son attention. Résultat : les pages stratégiques sont moins souvent crawlées, non par manque de budget global, mais par mauvaise allocation de ce budget.

Deuxième erreur : négliger le fichier robots.txt et les directives noindex/nofollow. Des sections entières du site peuvent être bloquées par accident, créant l'illusion d'un crawl insuffisant alors que c'est vous qui fermez la porte. Inversement, laisser Google explorer des milliers de pages de recherche interne vides ou de tags sans contenu gaspille du temps de crawl pour rien.

Comment vérifier que mon site ne souffre pas d'un problème de crawl déguisé ?

Ouvrez la Search Console, section Statistiques d'exploration. Regardez le nombre de requêtes crawl par jour, la moyenne des temps de réponse, le taux d'erreurs serveur. Si ces métriques sont stables et que vos pages clés apparaissent régulièrement dans les logs, vous êtes tranquille.

Ensuite, analysez vos logs serveur — pas pour traquer obsessionnellement chaque bot, mais pour identifier des anomalies. Des sections ignorées pendant des semaines ? Un crawl concentré sur des URLs sans valeur ? Ce sont des symptômes d'architecture défaillante, pas de crawl budget insuffisant. Corrigez le maillage, nettoyez les sitemaps, renforcez les signaux internes vers les pages importantes.

• Auditez la performance serveur : temps de réponse < 500ms, taux d'erreurs 5xx proche de zéro
• Identifiez et bloquez les facettes inutiles générant des URLs combinatoires sans valeur ajoutée
• Vérifiez que vos pages stratégiques sont crawlées régulièrement via la Search Console et les logs serveur
• Nettoyez les sitemaps pour ne soumettre que les URLs indexables et à forte valeur
• Renforcez le maillage interne vers les contenus prioritaires pour guider l'allocation du crawl
• Surveillez le délai d'indexation des nouveaux contenus : s'il dépasse 48h pour des pages importantes, creusez les causes techniques