Un client m'appelle un mardi matin, paniqué. Il vient de publier 400 nouvelles fiches produits. Trois semaines plus tard, Google en a indexé onze. Onze. Il me demande si son site est « puni ». Non. Il a simplement un problème de crawl budget, et il ne le sait pas encore.
Le crawl budget, c'est le nombre de requêtes que Googlebot accepte d'envoyer à votre serveur sur une fenêtre de temps donnée. Pas plus compliqué que ça. Mais derrière cette définition toute simple se cache une mécanique que la plupart des sites ignorent jusqu'au jour où leurs pages neuves stagnent dans un coin de l'index.
Ce qui est vicieux, c'est que le sujet ne concerne presque personne… jusqu'à ce qu'il concerne quelqu'un. Et le jour où ça vous tombe dessus, vous perdez des semaines à comprendre.
Points clés à retenir
- Le budget de crawl n'existe réellement qu'à partir de plusieurs milliers d'URL — en dessous, vous pouvez fermer cet onglet.
- Deux forces s'opposent : ce que votre serveur peut encaisser (crawl rate limit) et ce que Google a envie d'explorer (crawl demand).
- Un temps de réponse serveur qui dépasse la seconde est le premier levier à traiter, avant même de toucher au robots.txt.
- Les rapports de la Search Console et les logs serveur sont vos seuls thermomètres crédibles — le reste, c'est de la divination.
- Les pages qui gaspillent le budget sont presque toujours les mêmes : paramètres d'URL, filtres à facettes, pagination infinie, pages de recherche internes.
Comprendre le budget de crawl, vraiment
La définition qu'on lit partout — « le nombre d'URL que Googlebot peut explorer » — est correcte mais trompeuse. Elle laisse croire qu'il y a un quota fixe quelque part chez Google, comme un forfait mobile. Ce n'est pas ça du tout.
Googlebot ajuste son comportement en permanence. Il teste, il recule, il revient. Le budget est une négociation dynamique, pas un plafond gravé dans le marbre.
Les deux facteurs qui déterminent tout
Deux éléments entrent en jeu, et ils n'ont rien à voir l'un avec l'autre.
- Le crawl rate limit : la quantité de requêtes que votre infrastructure peut absorber sans s'écrouler. Si votre serveur met deux secondes à répondre, Googlebot freine de lui-même. Parfois brutalement.
- Le crawl demand : l'intérêt que Google porte à vos pages. Une page mise à jour souvent, liée depuis l'extérieur, avec un historique d'indexation propre, sera re-visitée vite. Une page orpheline, jamais modifiée, sera oubliée.
Vous ne contrôlez pas le second facteur. Vous pouvez (partiellement) influencer le premier.
À partir de quel moment ça compte ?
Franchement ? Si votre site fait moins de 2 000 pages, arrêtez de lire. Votre budget de crawl est largement suffisant, et vous perdriez votre temps à optimiser une ressource que vous n'épuisez pas.
Le sujet devient concret à partir de plusieurs milliers d'URL, et critique au-delà de 50 000. Sur un catalogue e-commerce que j'ai suivi pendant plusieurs mois — environ 80 000 pages actives — on gaspillait près d'un tiers du budget sur des URL paramétrées sans valeur. Un tiers. Pour rien.
Comment mesurer votre budget de crawl réel
C'est le point que la plupart des articles sautent. Comprendre le concept ne sert à rien si vous ne pouvez pas l'observer. Et la bonne nouvelle, c'est que vous avez déjà les outils.
Le rapport sur les statistiques d'exploration
Dans la Search Console, le rapport Statistiques sur l'exploration vous donne le volume de requêtes par jour, la répartition par type de fichier, et surtout le temps de réponse moyen.
Ce que vous cherchez :
- Un volume de requêtes qui stagne alors que votre site grandit — signe que le budget est saturé.
- Un temps de réponse qui grimpe au-delà de 500-600 ms en moyenne.
- Une part importante de requêtes vers des URL que vous ne voulez pas voir explorées.
Les logs serveur, votre thermomètre précis
La Search Console arrondit, agrège, lisse. Les logs serveur, eux, ne mentent pas. Filtrez les requêtes dont le user-agent contient « Googlebot », puis regardez ce qui revient le plus souvent.
Sur le site à 80 000 pages que j'évoquais plus haut, l'analyse des logs a été un électrochoc. Les pages de recherche interne représentaient à elles seules 22 % des requêtes de Googlebot. Des milliers de hits par jour sur des pages que personne n'aurait jamais dû indexer.
Un robots.txt bien écrit et un peu de discipline sur les paramètres ont ramené ce chiffre sous les 5 % en trois semaines. Le volume total de pages indexées, lui, a grimpé de 18 % dans les deux mois suivants. Sans qu'on touche au contenu.
Optimiser le budget de crawl : le plan concret
Il n'y a pas de recette unique. Mais il y a un ordre logique, et ignorer cet ordre est l'erreur que je vois le plus souvent.
L'erreur n°1 : commencer par le robots.txt
Tout le monde fonce sur le robots.txt. C'est le réflexe. C'est aussi, souvent, une perte de temps.
Si votre serveur met 1,5 seconde à répondre, Googlebot ralentira de lui-même, quoi que vous écriviez dans votre fichier. Vous pouvez interdire la moitié de votre site, vous n'aurez pas plus de crawl utile. Vous aurez juste un site à moitié invisible et un budget toujours saturé.
La première chose à faire, c'est de réduire le temps de réponse. Cache serveur, CDN, requêtes base de données optimisées. C'est ingrat, personne ne vous félicitera pour ça. C'est aussi ce qui débloque 70 % des situations.
Les leviers, dans l'ordre
| Levier | Quand l'utiliser | Effet observé sur mon dernier projet |
|---|---|---|
| Temps de réponse serveur | Toujours en premier | −40 % de requêtes gaspillées, retour de Googlebot plus fréquent |
| robots.txt sur paramètres | Quand les logs montrent du bruit | Chute des hits parasites, index plus propre |
| Balises noindex | Sur pages de faible valeur mais liées | Plus lent mais plus sûr que robots.txt |
| Canoniques | Doublons et variantes d'URL | Consolidation du signal, budget préservé |
| Sitemaps | Pour signaler les pages prioritaires | Accélération de l'indexation des nouveautés |
Notez bien la nuance entre le robots.txt et le noindex. Un Disallow empêche l'exploration, mais n'empêche pas l'indexation si la page est liée ailleurs. Le noindex empêche l'indexation, mais nécessite que Googlebot explore la page pour le lire. Selon votre cas, l'un ou l'autre sera le bon choix — et se tromper coûte cher.
Traquer le gaspillage
Les coupables habituels, dans mon ordre d'apparition en logs :
- Les filtres à facettes e-commerce, qui génèrent des milliers d'URL combinatories.
- La pagination profonde, explorée jusqu'à la page 47 alors que personne ne clique au-delà de 3.
- Les pages de recherche internes, souvent liées par le menu ou un widget.
- Les paramètres de tracking ou de session encore ouverts à l'exploration.
- Les archives de blog par date, par auteur, par catégorie — multipliées à l'infini.
Chacune de ces familles peut consommer à elle seule plus de budget que vos vraies pages produits. Les additions sont cruelles.
Et si mon site est petit, ça sert à rien ?
Non, ça ne sert à rien. Et c'est très bien ainsi. La grande majorité des sites n'ont aucun problème de crawl budget. Ils ont des problèmes de contenu, de liens internes, de qualité — des sujets autrement plus rentables à traiter.
Ce qui me dérange dans la façon dont ce sujet circule, c'est qu'il donne l'impression d'être universel. Il ne l'est pas. Il concerne une frange minoritaire de sites, souvent ceux qui ont déjà réglé tout le reste et qui cherchent le point de blocage suivant.
Si vous avez 500 pages et que trois ne sont pas indexées, cherchez ailleurs. Regardez la qualité de la page, ses liens internes, sa valeur perçue. Le budget de crawl n'est pas votre problème.
Trois faux problèmes qu'on confond avec un budget saturé
« Google n'indexe plus mes nouvelles pages »
Neuf fois sur dix, c'est un problème de qualité ou de maillage interne, pas de budget. Une page orpheline, jamais liée, sans aucun signal externe, sera indexée lentement — ou pas du tout. Ce n'est pas parce que Google manque de budget, c'est parce qu'il n'a aucune raison d'y aller.
« Mon site est pénalisé »
Aucune action manuelle dans la Search Console ? Aucun signal de pénalité algorithmique évident ? Alors ce n'est presque jamais une pénalité. C'est une mécanique de crawl qui tourne mal. Le mot « pénalité » fait peur, il fait vendre du conseil. Il ne décrit pas la réalité la plupart du temps.
« Il faut tout réindexer »
Non. Réindexer à tout va via l'API d'indexation ne crée pas de budget. Ça ne fait qu'ajouter du bruit. On priorise, on nettoie, on attend. Le budget se reconquiert par soustraction, jamais par addition.
Ce qui reste après avoir tout optimisé
Il y a un moment où vous avez fait le tour. Temps de réponse sous contrôle, paramètres fermés, pages sans intérêt retirées du circuit, sitemaps propres. Et à ce moment-là, une question désagréable surgit : et si le budget n'était finalement qu'un symptôme ?
Un symptôme d'un site qui grossit plus vite que sa valeur réelle. Un symptôme d'une architecture qui accumule des pages au lieu de les hiérarchiser. Un symptôme, en somme, d'un catalogue qui n'a jamais appris à dire non.
Le crawl budget ne se règle pas à coups de fichiers de configuration. Il se règle en décidant, page après page, ce qui mérite d'exister sur votre site. C'est un travail éditorial déguisé en travail technique. Et c'est probablement pour ça qu'on préfère en parler comme d'un réglage.
