Un site de 40 000 URL, dont 38 000 ne reçoivent jamais un visiteur. Et pourtant, chaque nuit, Googlebot y consacre une partie de son temps. C'est le premier truc que j'ai regardé quand un client e-commerce est venu me voir avec un problème d'indexation qui traînait depuis huit mois : combien de requêtes par jour dans le rapport d'exploration, et sur quelles URL elles tombaient. Réponse : 70 % sur des pages de filtres à paramètres, 12 % sur les fiches produits. Le budget d'exploration n'était pas insuffisant. Il était gaspillé.
Comprendre le crawl budget, ce n'est pas apprendre une définition. C'est savoir lire une facture. Votre serveur paie en temps CPU et en bande passante, Google paie en attention. Tant que la facture reste raisonnable, personne ne s'en occupe. Le jour où un catalogue grossit ou qu'un site change de plateforme, la note arrive.
Points clés à retenir
- Le crawl budget ne devient un problème qu'à partir de plusieurs milliers de pages réellement accessibles, et surtout quand beaucoup d'entre elles ne servent à rien.
- Deux curseurs seulement : ce que votre serveur accepte de supporter (crawl rate limit) et ce que Google juge utile d'explorer (crawl demand).
- Le rapport d'exploration de la Search Console donne la seule métrique qui compte au quotidien : le temps de réponse moyen du serveur aux requêtes de Googlebot.
- Bloquer une URL dans robots.txt n'empêche pas son indexation : cela empêche seulement de lire un noindex posé dessus. Erreur classique, dégâts durables.
- Sur un site mal structuré, un tiers du budget part souvent sur des paramètres d'URL, des pages de recherche internes et des paginations vides.
Le crawl budget, ou pourquoi Google ne passe pas partout
Googlebot n'explore pas un site en une nuit. Il en explore un morceau, revient, recommence. Le volume de pages aspirées sur une période donnée, c'est le crawl budget. La documentation de Google le découpe en deux notions et c'est là que tout se joue.
Le crawl rate limit : ce que votre serveur encaisse
Google ajuste la fréquence de ses visites en fonction de la santé de votre hébergement. Un serveur qui répond en 200 ms se fait visiter plus souvent qu'un serveur qui met trois secondes ou qui renvoie des erreurs 500 en rafale. C'est mécanique.
J'ai vu un hébergement mutualisé saturé faire chuter le rythme d'exploration d'un site de 12 000 pages en dessous de 300 requêtes par jour. Trois jours après une migration vers un serveur correctement dimensionné, on repassait au-dessus de 2 000. Aucun changement de contenu, aucune modification technique. Juste du CPU et de la latence.
Ordre de grandeur utile : tant que le temps de réponse moyen aux requêtes de Googlebot reste sous quelques centaines de millisecondes, vous n'êtes pas le goulot d'étranglement. Au-delà d'une seconde régulière, commencez à chercher ailleurs que dans votre balisage.
Le crawl demand : ce que Google juge utile d'explorer
Le second curseur dépend de la popularité, de la fraîcheur, du maillage interne et de la qualité perçue. Une page sans lien entrant, sans visite, sans mise à jour, n'a aucune raison d'être visitée souvent. Google la visitera une fois, puis l'oubliera.
Franchement, ce second critère est celui que la plupart des équipes techniques ignorent, parce qu'il ne se règle pas dans un fichier de configuration. Il se règle dans l'architecture du site et dans le maillage.
À partir de quand faut-il vraiment s'en préoccuper
Question qu'on me pose à chaque audit : « mon site fait 800 pages, je dois optimiser mon crawl budget ? » Non. Un site de quelques centaines ou même quelques milliers d'URL correctement liées est exploré intégralement en quelques jours sans effort.
Le sujet devient concret quand trois conditions se croisent :
- Le volume de pages accessibles dépasse largement ce que Google explore réellement chaque jour.
- Une part significative de ces pages n'a aucune valeur (paramètres, tri, recherche interne, doublons).
- Des pages importantes changent souvent et mettent des semaines à être réexplorées.
Si une seule de ces trois lignes vous concerne, vous pouvez refermer l'onglet. Si les trois se cumulent, vous avez un vrai chantier.
Un cas typique que j'ai rencontré sur une place de marché : 26 000 URL indexables, dont 19 000 générées par des combinaisons de filtres. Les fiches produits principales étaient réexplorées tous les 12 à 15 jours alors qu'elles changeaient de prix chaque matin. Le budget n'était pas trop petit. Il finançait du néant.
Mesurer avant de toucher à quoi que ce soit
Avant d'écrire la moindre ligne dans robots.txt, il faut un relevé. Sans chiffres de départ, vous ne saurez jamais si vos changements ont servi à quelque chose. Et croyez-moi, on se raconte vite des histoires.
Le rapport « Statistiques d'exploration » de la Search Console suffit pour 90 % du diagnostic. Trois chiffres à relever :
- Le total de requêtes par jour, à comparer au nombre d'URL réellement importantes sur le site.
- Le temps de réponse moyen aux requêtes de Googlebot, avec une alerte mentale au-delà de 500 ms.
- La répartition par code de réponse et par type de fichier — c'est là que les surprises apparaissent.
Sur un audit récent, la répartition des codes de réponse a révélé que 31 % des requêtes recevaient un code 404 ou 301 en chaîne. Autrement dit : un tiers du budget brûlait dans des redirections et des pages mortes. Le correctif n'a pas consisté à « optimiser » quoi que ce soit, mais à nettoyer les liens internes pointant vers des URL obsolètes. En cinq semaines, la part de requêtes en erreur est descendue sous 8 %. Et la fréquence de réexploration des fiches produits a presque doublé.
Un détail que je vérifie systématiquement : le rapport montre aussi les URL explorées les plus fréquemment. Si une page de connexion, une page de recherche interne ou un panier figurent dans le top, votre budget fuit par un trou évident.
Les leviers techniques qui changent réellement les choses
Une fois le relevé fait, deux ou trois actions suffisent dans la majorité des cas. Le piège, c'est de tout empiler en même temps et de ne plus rien comprendre.
Noindex ou robots.txt : le piège dans lequel tout le monde tombe
Voilà la confusion la plus coûteuse du domaine. Mettre une URL en Disallow dans robots.txt empêche Googlebot de l'explorer. Mais un moteur qui n'explore pas une page ne peut pas lire la balise noindex qu'elle contient. Résultat : la page peut rester indexée pendant des mois, sur la seule base de liens externes, sans que vous puissiez corriger le tir.
La règle que j'applique sans exception : pour retirer une page de l'index, on la laisse explorable et on pose un noindex. Pour économiser du budget sur des zones vraiment inutiles (recherche interne, panier, tunnel de commande), alors seulement on bloque dans robots.txt.
| Besoin | noindex | robots.txt (Disallow) |
|---|---|---|
| Retirer une page de l'index | Oui, méthode recommandée | Non : bloque la lecture du noindex |
| Économiser du budget sur des URL sans valeur | Fonctionne mais consomme quand même une visite | Oui, efficace immédiatement |
| Masquer une section du crawl sans la désindexer | Non pertinent | Oui |
| Garder la main sur un contenu qui change de statut | Oui, réversible rapidement | Non, effets de bord longs à corriger |
Paramètres d'URL, facettes et pagination
Les filtres à facettes sont le premier poste de gaspillage sur les catalogues. Chaque combinaison de critères génère une URL unique, souvent indexable, presque toujours sans valeur. La bonne approche n'est pas de bloquer en masse, mais de laisser ouvertes les combinaisons réellement recherchées et de fermer le reste avec un noindex, follow.
La pagination mérite un traitement à part. Les pages 2, 3, 4 d'une liste sont rarement visitées par les internautes, mais elles constituent le seul chemin pour découvrir les fiches profondes. Si vous les bloquez, vous coupez le maillage. Si vous les laissez, elles consomment du budget utile. Mon parti pris : garder les paginations explorables mais leur donner une priorité basse, et surtout s'assurer que les fiches produits sont atteignables par d'autres chemins (catégories, liens croisés, sitemap).
Sitemap et maillage interne
Le sitemap XML ne fait pas grimper le budget, mais il oriente ce qui reste. Un sitemap qui liste 40 000 URL dont 38 000 sans valeur est un signal dilué. Un sitemap resserré sur les pages qui changent et qui comptent, tenu à jour, sert de feuille de route.
Le maillage reste le levier le plus sous-estimé. Une fiche produit accessible en trois clics depuis la page d'accueil sera explorée deux à trois fois plus souvent qu'une fiche à huit clics de profondeur. J'ai mesuré la différence sur un catalogue de pièces détachées : les références remontées dans des blocs de liens contextuels passaient d'une réexploration mensuelle à une réexploration hebdomadaire. Sans aucune action technique lourde.
Trois erreurs que j'ai commises, pour que vous les évitiez
La première est embarrassante. Sur un premier projet, j'ai bloqué tout un répertoire de filtres dans robots.txt pour « libérer du budget ». Six mois plus tard, ces pages étaient toujours dans l'index, parfois avec des descriptions obsolètes. Il a fallu tout débloquer, attendre des semaines, poser des noindex, puis attendre encore. Leçon retenue.
Deuxième erreur : avoir optimisé sans mesurer. J'ai resserré un sitemap en étant persuadé que le crawl s'améliorerait. Aucune amélioration, parce que le problème était ailleurs, dans des redirections en chaîne. Sans relevé initial, j'ai perdu trois semaines à corriger la mauvaise chose.
Troisième : avoir sous-estimé l'hébergement. Un serveur lent bride mécaniquement le crawl rate, et aucun réglage SEO ne compense ça. Quand un client me dit « Google ne passe plus », je regarde d'abord l'uptime et le temps de réponse.
Un plan d'action en quatre étapes
Si vous voulez une séquence simple à dérouler :
- Relever trois semaines de données d'exploration avant toute modification, et noter le temps de réponse moyen.
- Identifier les URL qui consomment du budget sans valeur : paramètres, recherche interne, paniers, redirections en chaîne, 404 internes.
- Traiter par ordre de coût : corriger les liens internes d'abord (gratuit, effet immédiat), poser des noindex ensuite, bloquer en dernier recours seulement.
- Revérifier quatre à six semaines plus tard, en comparant les mêmes métriques.
Un mois suffit à voir bouger un temps de réponse ou une répartition de codes de réponse. L'effet sur la fréquence de réexploration des pages clés prend plus longtemps : comptez deux à trois cycles avant de conclure.
Ce qu'il faut garder en tête
Le crawl budget n'est pas un réglage à optimiser, c'est un symptôme. Quand il devient un problème, c'est presque toujours qu'une autre décision a été mal prise en amont : une architecture qui génère des milliers d'URL sans contenu, un hébergement sous-dimensionné, une migration bâclée, un sitemap jamais relu.
La question utile n'est donc pas « comment augmenter mon crawl budget ». C'est : « pourquoi Google consacre-t-il du temps à des pages dont je ne veux pas ? » Tant que vous n'avez pas de réponse nette à cette question, tout ce que vous ajouterez par-dessus ne sera qu'un pansement. Et les pansements sur un crawl qui fuit, ça se décolle en trois semaines.
