- →Le budget de crawl n'est pas une valeur unique : c'est la rencontre entre une capacité (votre serveur, votre temps de chargement) et une demande (la valeur perçue de vos pages). On agit sur l'une ou sur l'autre, jamais sur « le budget » en bloc.
- →Google Search Console donne la tendance, les logs serveur donnent la vérité. Tant que vous n'avez pas vu la répartition réelle des requêtes de Googlebot par code HTTP et par type d'URL, vous optimisez à l'aveugle.
- →Renvoyer un 304 sur les pages inchangées, via ETag ou Last-Modified, est le levier le plus rentable et le moins pratiqué : la documentation Google de novembre 2025 en a fait un chapitre entier.
- →Les bots IA sont devenus une ligne du budget serveur : Cloudflare a mesuré une hausse de 305 % des requêtes GPTBot entre mai 2024 et mai 2025, contre 96 % pour Googlebot. Vos logs doivent les séparer.
- →Bloquer une URL dans robots.txt n'économise pas de budget d'indexation : l'URL reste connue, elle n'est simplement plus lue. Pour la sortir de l'index, il faut au contraire qu'elle soit explorée.
- →En dessous de quelques milliers d'URL, le budget de crawl n'est presque jamais le facteur limitant. Les sites qui souffrent vraiment sont ceux à facettes, à paramètres et à pagination profonde.
Ce que Google alloue vraiment
Le budget de crawl est un raccourci de vocabulaire pour désigner le produit de deux quantités que Google documente séparément : la capacité d'exploration, plafond que Googlebot s'impose pour ne pas dégrader votre serveur, et la demande d'exploration, c'est-à-dire l'intérêt qu'il a à revenir sur vos URL. La première dépend de votre infrastructure et de vos temps de réponse. La seconde dépend de la popularité de vos pages, de leur fraîcheur et de la qualité globale du site. Un site rapide mais sans valeur sera peu exploré : la capacité est là, la demande manque. Un site lent mais très demandé sera exploré quand même, par à-coups, avec des délais de découverte qui s'allongent.
La conséquence opérationnelle tient en une phrase : on n'optimise pas « le budget de crawl », on choisit laquelle des deux variables on déplace. Réduire le TTFB et servir des réponses compressées augmente la capacité. Supprimer les pages creuses, resserrer l'architecture et gagner en autorité augmente la demande. Les deux leviers ne se remplacent pas, et un consultant qui promet d'« optimiser le crawl » sans dire lequel des deux il vise vend du vent.
Une courte mise en bouche vidéo, utile pour caler le vocabulaire avant d'entrer dans la mécanique :
Troisième point, celui que la plupart des articles écrasent : explorer n'est pas indexer. Googlebot peut lire une page tous les trois jours et ne jamais la retenir, ou l'indexer au premier passage et ne plus jamais revenir. Le crawl est une condition nécessaire, pas suffisante. Dans Search Console, une URL classée « Explorée, actuellement non indexée » n'est pas un problème de budget, c'est un verdict de qualité. Inversement, une page jamais découverte parce qu'elle est à sept clics de la home et absente du plan de site XML est bien, elle, un problème d'exploration. Confondre les deux diagnostics fait perdre des semaines.
La mécanique en 2026 : cache, HTTP/2 et bots IA
Google a mis à jour sa documentation d'exploration le 20 novembre 2025, en y ajoutant des chapitres sur la mise en cache HTTP, les en-têtes ETag et Last-Modified, HTTP/1.1 et HTTP/2, la compression et la gestion du taux de crawl. Ce n'est pas de la cosmétique documentaire : cela dit noir sur blanc où se trouvent les vrais leviers serveur. Une page inchangée qui renvoie un 304 au lieu d'un 200 complet libère de la capacité pour le reste du site. C'est le geste le plus rentable et, d'après ce qu'on observe en audit, le moins souvent implémenté correctement sur les CMS français.
Deuxième changement à ne pas rater côté infrastructure : depuis le 31 mars 2026, Google a déplacé les fichiers JSON de plages IP de ses crawlers de /search/apis/ipranges/ vers /crawling/ipranges/, au motif que ces plages couvrent désormais plus que les seuls robots de Search. Toute liste d'autorisation WAF ou tout script de vérification automatique de Googlebot pointant sur l'ancienne adresse finira par bloquer le vrai Googlebot ou laisser passer un imposteur. Vérifiez cette ligne dans votre configuration avant de chercher ailleurs pourquoi votre fréquence d'exploration a chuté.
Troisième évolution, la plus structurante : les robots ne sont plus seulement ceux des moteurs. Cloudflare a mesuré, entre mai 2024 et mai 2025, une hausse de 18 % du trafic global de crawlers, avec 305 % de requêtes GPTBot supplémentaires contre 96 % pour Googlebot. La même source rapporte qu'en juin 2025, Google explorait environ 14 fois par visiteur envoyé, contre un ratio de 1 700 pour 1 chez OpenAI et 73 000 pour 1 chez Anthropic. Autrement dit, une part croissante de votre capacité serveur est consommée par des agents qui ne vous renvoient presque personne. Le Web Almanac 2025, publié le 15 janvier 2026 à partir des données HTTP Archive, confirme la réaction des éditeurs : GPTBot apparaît dans environ 4,5 % des fichiers robots.txt desktop contre 2,9 % en 2024, et dans 20,9 % de ceux du top 1 000. Arbitrer n'est pas trivial : bloquer protège l'infrastructure mais réduit l'exposition dans les moteurs de réponse.
Un détail qui évite de perdre du temps : Google a clarifié le 15 juin 2026 que llms.txt n'est pas utilisé par Google Search et n'a aucun effet, positif ou négatif, sur la visibilité. Ce n'est ni un contrôle d'exploration ni un levier d'indexation. Restent les vrais outils : robots.txt, les en-têtes, le sitemap et l'architecture. Enfin, le rendu JavaScript reste une taxe réelle sur la capacité : chaque URL qui exige un passage par le moteur de rendu coûte plusieurs fois une page HTML servie telle quelle, sujet traité en détail dans notre entrée sur le SEO des sites en JavaScript.
Mesurer le crawl : Search Console puis logs serveur
Le rapport Statistiques d'exploration de Search Console est le point de départ obligatoire : volume de requêtes par jour, temps de réponse moyen, répartition par code de réponse, par type de fichier et par objectif (découverte contre actualisation). Il a trois limites qu'il faut connaître avant d'en tirer des conclusions : la fenêtre est glissante sur quatre-vingt-dix jours, les données sont agrégées au niveau de la propriété, et aucune URL individuelle n'est exportable. Il donne une tendance, pas un diagnostic.
L'explication officielle du rapport par Google, qui vaut mieux que n'importe quelle paraphrase :
Le diagnostic, lui, se fait dans les logs, et c'est exactement ce que la plupart des contenus qui rankent sur ce sujet n'abordent jamais. L'analyse des journaux serveur est la seule méthode qui montre, URL par URL, ce que Googlebot a réellement demandé, à quelle fréquence, avec quel code et quel temps de réponse. La barrière d'entrée est basse : le Log File Analyser de Screaming Frog est gratuit jusqu'à 1 000 lignes de log et un projet, et coûte 99 £ par utilisateur et par an en version complète, avec vérification des bots, URL les plus et les moins explorées, fréquence de crawl et détection des URL orphelines. Le SEO Spider, à 199 £ par an, sert ensuite à croiser cette liste avec la structure réelle du site.
Ce qu'on regarde en priorité dans ces données : la part des requêtes de Googlebot qui atterrit sur du HTML indexable renvoyant 200. Quand cette part descend sous la moitié, il y a une fuite, et elle est presque toujours localisable en trois requêtes. Ensuite, la fréquence d'exploration des pages qui comptent commercialement, comparée à celle des pages de service. Enfin, la liste des URL explorées mais absentes du crawl structurel : ce sont vos orphelines, et Google les connaît mieux que votre maillage interne.
Crawl, maillage et netlinking : la demande se fabrique
La demande d'exploration n'est pas une fatalité, elle se construit. Une page reçoit des visites de Googlebot proportionnellement aux chemins qui y mènent, internes comme externes. Un lien éditorial posé sur un média lui-même exploré plusieurs fois par jour raccourcit mécaniquement le délai de découverte d'une page neuve, et prolonge la fréquence de repassage sur la cible. C'est un effet secondaire du netlinking rarement mis en avant, alors qu'il est mesurable dans les logs dans les jours qui suivent la mise en ligne d'un lien.
Une enquête Editorial.Link menée en 2025 auprès de 518 professionnels du SEO plaçait le digital PR en tête des tactiques d'acquisition de liens, cité par 48,6 % des répondants. L'intérêt pour le crawl est direct : ces liens vivent sur des pages fréquemment mises à jour et fréquemment explorées, donc ils transmettent aussi de l'attention robot, pas seulement de l'autorité. Quand nous calibrons une campagne sur nos propres médias, nous regardons systématiquement la fréquence de crawl des pages hôtes avant leur métrique d'autorité, et c'est aussi le critère que nous exposons dans le catalogue de médias que nous opérons en propre.
Côté interne, les principes n'ont pas changé mais leur poids augmente avec la taille du site : profondeur de clic maîtrisée, pagination qui ne crée pas de labyrinthe, liens contextuels vers les pages profondes depuis les pages fortes. Un sitemap propre aide à la découverte, il ne remplace jamais un maillage. Et si l'arbitrage porte sur le coût, la comparaison entre un chantier d'architecture et une campagne de liens se pose en euros : nos tarifs publics par palier existent justement pour que ce calcul soit faisable sans passer par un devis.
Ce qui consomme le budget inutilement
Le premier gouffre, de très loin, ce sont les paramètres d'URL : facettes de filtrage, tris, identifiants de session, calendriers infinis. Un catalogue de 5 000 produits génère sans effort plusieurs centaines de milliers d'URL combinatoires, toutes explorables, toutes quasi identiques. La balise canonical résout le problème d'indexation, pas celui d'exploration : Google doit lire la page pour voir la canonique. Sur les combinaisons sans valeur, le blocage dans robots.txt est le bon outil, à condition d'accepter que ces URL restent connues.
Deuxième poste : les erreurs et les détours. Les 404 en masse issues d'un ancien catalogue, les 500 intermittents qui font baisser la capacité pour tout le site, les chaînes de redirections où chaque saut est une requête. Une chaîne à quatre sauts multiplie par quatre le coût d'accès à la destination, et Googlebot abandonne au-delà d'un certain nombre. Les soft 404, elles, sont pires que les vraies : elles renvoient 200, donc elles restent dans la file d'exploration indéfiniment.
Troisième piège, plus subtil : croire qu'interdire fait économiser. Une URL bloquée dans robots.txt n'est plus lue, donc sa balise noindex ne sera jamais vue, et elle peut rester indexée sans description. Pour désindexer, il faut au contraire laisser explorer. À l'inverse, bloquer les fichiers CSS et JavaScript nécessaires au rendu dégrade la compréhension de la page sans économiser grand-chose. Enfin, un sitemap qui déclare une date de dernière modification fausse à chaque déploiement décrédibilise le signal : Google apprend vite à l'ignorer, et vous perdez le seul moyen simple de dire ce qui a vraiment changé.
Mythes tenaces et arbitrage de priorités
Trois idées reçues survivent à tout. Que le crawl budget ne concernerait que les très gros sites : faux dans le principe, vrai dans la pratique pour un site éditorial de quelques centaines d'URL bien maillées, où le facteur limitant est la qualité du contenu, pas l'accès. Que le taux d'exploration serait une valeur fixe : il varie en continu selon vos temps de réponse et vos codes d'erreur, et une panne de deux jours se paie en semaines de récupération. Que ce serait la première chose à optimiser : dans une liste de priorités honnête, cela arrive après l'architecture, le contenu et l'autorité, sauf sur un site à facettes où c'est le premier sujet.
La mise au point de Google sur ces croyances vaut d'être regardée en entier :
Dernier point méthodologique, et il coûte cher quand on l'oublie : le tableau de bord Google Search Status recense huit mises à jour de classement documentées entre mars 2025 et juin 2026, dont plusieurs core updates de plus de deux semaines. Ces mises à jour ne sont pas des changements de crawl, mais elles polluent toute corrélation naïve entre une courbe d'exploration et une courbe de trafic. Avant de conclure qu'une optimisation de budget de crawl a produit un gain de visibilité, vérifiez qu'aucune fenêtre de déploiement algorithmique ne recouvre votre période de mesure. Sinon vous attribuerez à votre robots.txt ce qui appartient à un core update.
Nautilinks opère un réseau de médias éditoriaux. Articles écrits en interne, mentions de transparence respectées, mix d'ancres calibré.
Questions fréquentes
À partir de quelle taille de site le budget de crawl devient-il un vrai sujet ?
Le seuil ne se lit pas en nombre de pages utiles mais en nombre d'URL accessibles. Un site de 800 articles bien maillés ne rencontre jamais le problème. Un catalogue de 3 000 références avec filtres à facettes peut exposer 400 000 URL et saturer sa capacité. La bonne question est donc le ratio entre URL explorables et URL que vous souhaitez voir indexées. Au-delà d'un facteur dix, l'audit de crawl passe devant le reste.
Faut-il bloquer les bots IA pour préserver la capacité serveur ?
C'est un arbitrage, pas une évidence. Cloudflare a mesuré en juin 2025 des ratios crawl/visite de 1 700 pour 1 chez OpenAI et 73 000 pour 1 chez Anthropic, contre environ 14 pour 1 chez Google : la charge est réelle et le retour direct quasi nul. Mais bloquer réduit la présence dans les moteurs de réponse. La position raisonnable consiste à séparer les bots dans vos logs, mesurer la charge effective, puis décider par famille plutôt que par une règle globale.
Le rapport Search Console suffit-il ou faut-il vraiment passer par les logs ?
Search Console montre le volume, le temps de réponse et la répartition par code, sur quatre-vingt-dix jours glissants et sans détail par URL. Cela suffit pour détecter une anomalie, jamais pour la localiser. Dès qu'il faut savoir quelles URL mangent le budget, seuls les logs répondent. Le Log File Analyser de Screaming Frog est gratuit jusqu'à 1 000 lignes, ce qui permet de tester la méthode sur un échantillon avant d'engager 99 £ par an.
Renvoyer des 304 change-t-il réellement quelque chose ?
Oui, et c'est le levier le plus sous-exploité. La documentation d'exploration mise à jour par Google le 20 novembre 2025 consacre une section entière à la mise en cache HTTP, aux en-têtes ETag et Last-Modified et à la compression. Une page inchangée qui répond 304 coûte une fraction d'un 200 complet. Sur un site de plusieurs dizaines de milliers d'URL dont la majorité ne bouge pas entre deux passages, la capacité libérée se voit dans les logs en quelques jours.
Un fichier llms.txt aide-t-il à orienter l'exploration ?
Non, du moins pas chez Google. La clarification publiée le 15 juin 2026 indique que llms.txt n'est pas utilisé par Google Search et n'a aucun effet, positif ou négatif, sur la visibilité ou le classement. Rien n'interdit de le maintenir pour d'autres systèmes, mais il ne constitue ni un contrôle d'exploration ni un signal d'indexation. Les instruments qui agissent réellement restent robots.txt, les en-têtes HTTP, le sitemap et la structure de liens.
Des backlinks peuvent-ils augmenter la fréquence d'exploration d'une page ?
Ils augmentent la demande d'exploration, ce qui est une part du budget. Un lien posé sur une page elle-même explorée plusieurs fois par jour raccourcit le délai de découverte et prolonge la fréquence de repassage sur la cible : l'effet est visible dans les logs dans la semaine qui suit. C'est pourquoi la fréquence de crawl du média hôte mérite d'être vérifiée au même titre que ses métriques d'autorité avant d'acheter quoi que ce soit.
Testez vos connaissances
Quiz : Crawl budget
1/3De quelles deux composantes le budget de crawl résulte-t-il, selon la documentation Google ?