Méthodes et workflows
Budget de crawl : à partir de quand faut-il s'en préoccuper ?
En bref. Presque jamais en dessous de quelques milliers d'URL. Google indique lui-même que la gestion du budget d'exploration concerne surtout les sites de plus d'un million de pages, ou de plus de dix mille pages changeant fréquemment. En dessous, un problème d'indexation vient presque toujours du contenu et non de la capacité d'exploration. S'en préoccuper trop tôt détourne d'un vrai problème éditorial pendant des mois.
Le budget de crawl est le sujet technique le plus souvent invoqué à tort. Il désigne la capacité d'exploration qu'un moteur alloue à un site, fonction de la santé du serveur et de l'intérêt estimé du contenu. Google précise dans sa page sur la gestion du budget d'exploration que ce guide s'adresse aux très gros sites, et que la plupart des éditeurs n'ont pas à s'en soucier.
Cet article donne le seuil à partir duquel le sujet devient réel, la façon de reconnaître un vrai problème, et les gaspillages qui valent la peine d'être supprimés quand c'est le cas.
De quoi parle-t-on exactement ?
De deux notions distinctes que Google combine, et qu'il est utile de séparer parce qu'elles ne se corrigent pas de la même façon.
La limite de capacité d'exploration est le nombre de requêtes simultanées que le robot s'autorise sans dégrader votre serveur. Elle monte si le serveur répond vite, elle baisse s'il ralentit ou renvoie des erreurs. C'est une contrainte technique.
La demande d'exploration est l'appétit du moteur pour votre site : la fréquence à laquelle il juge utile de revenir. Elle dépend de la popularité des URL, de leur fraîcheur et de la valeur perçue du site. C'est un jugement.
La distinction est décisive. Un serveur rapide n'augmente la fréquence de passage que si la demande suit ; investir dans l'infrastructure pour être mieux exploré, sur un site que le moteur juge peu intéressant, ne produit rien.
Quel seuil rend le sujet réel ?
Trois situations, et seule la dernière justifie un chantier dédié.
| Taille du site | Le budget de crawl est-il un sujet ? | Où chercher en cas de problème |
|---|---|---|
| Moins de 1 000 URL | Non, jamais | Le contenu, ou un blocage technique explicite |
| 1 000 à 10 000 URL | Rarement, sauf navigation à facettes | La qualité éditoriale, puis les URL parasites |
| Plus de 10 000 URL changeant souvent | Oui | Les gaspillages d'exploration, journaux serveur à l'appui |
| Catalogue à filtres, quelle que soit la taille apparente | Oui, souvent | Les combinaisons de paramètres, qui multiplient les URL réelles |
La dernière ligne est la plus piégeuse. Un catalogue de 800 produits avec cinq filtres combinables peut générer des centaines de milliers d'URL distinctes. La taille apparente du site n'a alors aucun rapport avec le nombre d'adresses que le robot découvre.
Comment savoir si vous avez réellement un problème ?
Trois vérifications, dans cet ordre. Aucune ne demande d'outil payant, mais la troisième demande l'accès aux journaux du serveur.
Le délai d'indexation de vos nouvelles pages. S'il se compte en jours, votre capacité d'exploration est suffisante, quelle que soit la taille du site. S'il dépasse plusieurs semaines et s'allonge, le signal mérite attention.
Le rapport de statistiques d'exploration dans la Search Console. Il montre le nombre de requêtes par jour, le temps de réponse moyen et les codes retournés. Une chute du volume corrélée à une hausse du temps de réponse indique une limite de capacité ; un volume stable pointe ailleurs.
Les journaux serveur. C'est la seule preuve. Ils montrent ce que le robot explore réellement, et la découverte typique est brutale : la moitié de la capacité consommée par des URL à paramètres qui ne devraient jamais être explorées.
Si les deux premières vérifications sont saines, le problème n'est pas là. Retournez au diagnostic d'indexation : notre article sur les pages non indexées détaille les six causes possibles, dont une seule relève de l'exploration.
Les cinq gaspillages classiques
Quand le problème est réel, il vient presque toujours de l'une de ces cinq sources. Elles se traitent dans cet ordre, du plus au moins rentable.
- La navigation à facettes. Chaque combinaison de filtres crée une URL, et le nombre de combinaisons croît de façon exponentielle. C'est de loin le premier poste sur un site marchand.
- Les paramètres de suivi. Les identifiants de campagne, de session ou de tri créent autant de variantes d'une même page. Une balise canonique consolide les signaux mais n'empêche pas l'exploration.
- La pagination sans fin. Des listes paginées sur des centaines de pages, souvent sans contenu propre au-delà de la troisième.
- Les chaînes de redirections. Chaque saut est une requête consommée. Sur un site ayant connu plusieurs migrations, les chaînes de trois ou quatre sauts sont courantes.
- Les pages d'erreur molles. Une page « aucun résultat » qui renvoie un code 200 est explorée comme une page normale, indéfiniment.
Un crawler d'audit repère les cinq en un passage. C'est l'usage qui justifie le mieux ce type d'outil sur un gros catalogue.
Que faire exactement, une fois le gaspillage identifié ?
Les outils disponibles ne font pas la même chose, et les confondre est la deuxième erreur du sujet, après celle de s'en préoccuper trop tôt.
Bloquer dans robots.txt empêche l'exploration, donc économise réellement de la capacité. C'est le bon outil pour les combinaisons de filtres et les paramètres de tri. Attention : une URL bloquée peut rester affichée dans les résultats si le moteur la connaît par ailleurs.
Poser une directive noindex retire la page de l'index mais suppose que le robot la lise pour voir la directive. Cela ne fait donc économiser aucune capacité, au contraire. C'est le bon outil quand vous voulez qu'une page reste accessible mais invisible en recherche.
Poser une canonique consolide les signaux vers l'URL de référence sans réduire l'exploration. C'est le bon outil pour les paramètres de suivi sur des pages par ailleurs légitimes.
La combinaison à éviter absolument : bloquer dans robots.txt une URL portant une directive noindex. Le robot ne lira jamais la directive, et la page pourra rester indexée indéfiniment.
Ce qui améliore l'exploration sans toucher au budget
Trois leviers agissent sur la demande d'exploration plutôt que sur la capacité, et ils profitent aux sites de toute taille.
Réduire la profondeur de clic. Une page à deux clics de l'accueil est explorée bien plus souvent qu'une page à cinq clics. C'est une question d'architecture, pas de budget, et c'est le levier le plus efficace sur un site moyen.
Supprimer les pages orphelines. Une page qu'aucun lien interne n'atteint dépend entièrement du sitemap pour être découverte, ce qui la place en bas de la file. Le maillage interne est ce qui signale l'importance d'une page.
Publier régulièrement. Un site qui change souvent est revisité plus souvent. C'est un cercle vertueux, et il explique pourquoi un site actif voit ses nouvelles pages indexées en heures là où un site dormant attend des semaines.
Ces trois leviers relèvent de la structure et de l'éditorial, pas de la technique serveur. C'est cohérent avec le constat de départ : sur la grande majorité des sites, ce qu'on prend pour un problème d'exploration est un problème d'architecture ou de contenu.
Le budget de crawl vaut-il pour les robots d'IA ?
Le principe est le même, avec deux différences pratiques.
D'abord, les robots des moteurs de réponse explorent souvent moins profondément que Googlebot, et se concentrent sur ce qu'ils atteignent facilement. Une page profonde et mal maillée a donc encore moins de chances d'être vue par eux que par un moteur classique, ce qui renforce l'intérêt de réduire la profondeur de clic.
Ensuite, plusieurs d'entre eux ne rendent pas le JavaScript. Un contenu qui n'apparaît qu'après exécution d'un script est invisible pour eux, indépendamment de toute question de capacité. C'est un critère de notre diagnostic de citabilité, et une limite que les sites en framework moderne découvrent souvent tard.
Le contrôle d'accès, lui, se joue entièrement dans robots.txt, et les conséquences d'un blocage diffèrent selon la famille de robot. Nous détaillons cet arbitrage dans autoriser ou bloquer les robots IA.
Conclusion
En dessous de quelques milliers d'URL, le budget de crawl n'est pas votre problème. Google le dit lui-même, et s'en préoccuper trop tôt fait passer des mois à optimiser une contrainte qui ne mord pas, pendant que la vraie cause, éditoriale, reste intacte. Vérifiez d'abord le délai d'indexation de vos nouvelles pages : s'il se compte en jours, passez à autre chose.
Quand le sujet est réel, la navigation à facettes est presque toujours le premier poste. Un crawler d'audit la met en évidence en un passage, et les journaux serveur confirment.
Comparer les crawlers d'audit technique
Questions fréquentes
À partir de combien de pages le budget de crawl compte-t-il ?
Google indique que le sujet concerne surtout les sites de plus d'un million de pages, ou de plus de dix mille pages changeant fréquemment. En dessous, un problème d'indexation vient presque toujours du contenu ou d'un blocage technique explicite, pas de la capacité d'exploration.
Comment savoir si mon budget de crawl est insuffisant ?
Regardez le délai d'indexation de vos nouvelles pages : s'il se compte en jours, la capacité suffit. S'il dépasse plusieurs semaines et s'allonge, ouvrez le rapport de statistiques d'exploration de la Search Console, puis vos journaux serveur, qui sont la seule preuve de ce que le robot explore réellement.
Faut-il bloquer les pages inutiles dans robots.txt ou en noindex ?
Bloquer dans robots.txt économise réellement de la capacité d'exploration ; une directive noindex n'en économise aucune puisque le robot doit lire la page pour la voir. Ne combinez jamais les deux : le robot ne lira jamais la directive et la page pourra rester indexée.
Sources
- Large site owner's guide to managing your crawl budget (Google Search Central)
- Introduction to robots.txt (Google Search Central)
- Block Search indexing with noindex (Google Search Central)
- Overview of Google crawlers and fetchers (Google Search Central)
Cet article fait partie du dossier Automatiser ses tâches SEO avec l'IA, qui réunit tous nos articles sur le sujet.