Budget de crawl : ce que c’est, pourquoi ça compte, et comment arrêter de le gaspiller

par Francis Rozange | Mar 27, 2026 | SEO

Catégorie : SEO | Temps de lecture : 18 minutes | Dernière mise à jour : avril 2026

Le budget de crawl fait partie de ces concepts SEO qui génèrent beaucoup de discussions, le plus souvent inutiles pour la grande majorité des sites. John Mueller, chez Google, est sans détour : « À mon avis, le budget de crawl est surévalué. La plupart des sites n’ont jamais à s’en préoccuper. » Gary Illyes, qui avait signé le billet original de Google sur le budget de crawl en 2017, a confirmé en 2025 que le seuil du million de pages au-delà duquel le sujet devient pertinent n’a pas bougé. Si votre site compte moins de 100 000 pages, Mueller a explicitement déclaré que c’est « généralement insuffisant pour affecter le budget de crawl ». Mais pour les gros sites e-commerce, les sites avec navigation à facettes, les portails à URL paramétriques ou les sites avec un historique de migrations, le budget de crawl peut devenir le goulot d’étranglement invisible qui explique pourquoi vos pages ne remontent pas dans Google malgré un bon contenu. Cet article explique ce qu’est réellement le budget de crawl selon l’équipe Google, quand il compte vraiment, et comment cesser de le gaspiller.

Ce qu’est vraiment le budget de crawl (selon Google)

Le concept de budget de crawl n’est pas né chez Google. C’est la communauté SEO qui l’a inventé, et Google a fini par adopter une définition pour s’aligner sur la conversation extérieure. Gary Illyes l’a expliqué sur le podcast Search Off the Record : « Pendant longtemps, nous disions que le concept de budget de crawl n’existait pas chez nous. Et c’était vrai. Nous n’avions rien qui puisse signifier ça en interne. Et puis, comme les gens en parlaient, nous avons essayé de mettre quelque chose dessus. » La définition retenue par Google est « le nombre d’URL que Googlebot peut et est prêt à explorer pour un site donné ». Elle dépend de deux facteurs qui se combinent : la limite de fréquence de crawl et la demande de crawl. La limite de fréquence, c’est le nombre maximum de connexions simultanées que Googlebot ouvrira sur votre serveur sans le déranger. Si votre serveur répond vite, Googlebot crawle plus de pages dans la même fenêtre. S’il est lent ou qu’il renvoie des erreurs, Googlebot lève le pied pour ne pas saturer le serveur. La demande de crawl, c’est l’envie qu’a Google d’explorer votre site, en fonction de la popularité et de la fraîcheur de votre contenu, de la fréquence des mises à jour, et de l’importance perçue de vos URL. Un site d’actualité qui publie des dizaines d’articles par jour aura une demande de crawl beaucoup plus élevée qu’un site brochure qui change une fois par trimestre.

Quand le budget de crawl compte vraiment

Les seuils confirmés par Google

Selon la documentation officielle de Google, le budget de crawl est vraiment pertinent dans deux cas : les sites de plus d’un million de pages uniques mises à jour au moins une fois par semaine, et les sites de plus de 10 000 pages qui changent chaque jour. Gary Illyes a confirmé en 2025 que le seuil du million n’a pas bougé depuis 2020. Mueller, de son côté, a confirmé que 100 000 URL « n’est généralement pas assez pour affecter le budget de crawl ». Pour 99 pour cent des sites professionnels, ce qui ressemble à un problème de budget de crawl est en réalité un problème de qualité de contenu, de maillage interne ou de vitesse serveur. Si votre site fait 5 000 pages et que certains contenus ne sont pas indexés, ne regardez pas le budget de crawl en premier. Vérifiez plutôt la valeur réelle du contenu pour l’utilisateur, son rattachement par des liens depuis des pages d’autorité, et l’absence de problèmes techniques (balise noindex, balise canonique pointant ailleurs, réponses serveur lentes).

Les signes d’un vrai problème de budget de crawl

L’indicateur le plus fiable d’un vrai problème de budget de crawl, c’est un nombre croissant de pages dans le rapport Couverture de Google Search Console sous « Détectées, actuellement non indexées ». Ce statut signifie que Google a trouvé l’URL (par votre sitemap ou par des liens internes) mais qu’il a décidé de ne pas la crawler tout de suite. Si ce nombre est important et qu’il monte, vous avez peut-être un vrai sujet à creuser. Autres signaux : des pages neuves qui mettent des semaines voire des mois à apparaître dans l’index alors qu’elles sont dans votre sitemap et bien maillées, des pages importantes qui affichent une version en cache datée (recrawl peu fréquent), des logs serveur qui montrent Googlebot passant l’essentiel de son temps sur des URL à faible valeur plutôt que sur votre contenu important. Allez voir vos statistiques de crawl dans Google Search Console, sous Paramètres puis Statistiques de crawl. Vous y verrez le nombre de pages crawlées par jour, le temps de réponse moyen et la répartition de l’activité de crawl sur votre site. Si votre temps de réponse moyen dépasse 500 ms, corriger la vitesse serveur doit passer en premier, parce que c’est ce qui augmente directement le nombre de pages que Googlebot peut traiter dans son enveloppe de temps.

Les quatre grands gouffres à budget de crawl (selon Google)

Dans l’épisode « 2025 Wrapped » du podcast Search Off the Record, Gary Illyes et Martin Splitt ont passé en revue les données internes Google sur les problèmes de crawl les plus fréquents. La grande majorité de ces problèmes viennent de pièges structurels qui consomment les ressources de Googlebot sur des URL inutiles, et quatre patterns concentrent l’essentiel des dégâts.

Navigation à facettes

La navigation à facettes, ce sont les options de filtrage et de tri sur les pages catégorie d’un e-commerce. C’est la part la plus importante du gaspillage de budget de crawl rapportée à l’équipe Google. Quand une page catégorie permet de filtrer par couleur, taille, prix, marque, matière, et de trier par popularité, prix ou note, chaque combinaison crée une URL unique. Une seule catégorie avec 10 couleurs, 8 tailles, 5 marques et 3 options de tri peut générer des milliers de variantes d’URL, qui affichent globalement les mêmes produits dans un ordre légèrement différent. Googlebot tente de crawler chacune de ces URL, et il consomme du budget sur des pages quasi dupliquées qui n’ajoutent aucune valeur. Le correctif consiste à bloquer ces URL via des règles robots.txt sur les motifs de paramètres (par exemple Disallow: /*?color= ou Disallow: /*?sort=) et à pointer toutes les variantes en canonique vers l’URL propre de la catégorie. Sur WooCommerce, c’est à configurer soigneusement, parce que WooCommerce génère des URL filtrables par défaut sans contrôle de crawl approprié.

Paramètres d’action

Les paramètres d’action sont les paramètres d’URL générés par les actions utilisateur que Googlebot ne devrait jamais crawler : URL d’ajout au panier, URL de liste de souhaits, URL de comparateur, autres paramètres transactionnels. Illyes a glissé : « Ce que Googlebot ne fait pas, c’est faire les courses sur Internet. Il n’achètera pas votre sweat à capuche bizarre. » Pourtant, chaque milliseconde que Googlebot passe à crawler une URL d’ajout au panier est du budget perdu pour indexer une fiche produit ou un article de blog. Bloquez ces URL dans robots.txt avec des règles type Disallow: /*?add-to-cart= et Disallow: /*?wishlist=. La plupart des plateformes e-commerce génèrent ces paramètres par défaut, et la plupart des sites ne pensent jamais à les bloquer parce qu’ils n’apparaissent pas dans la navigation visible.

Identifiants de session

Bien que ce soit une pratique dépassée, les identifiants de session ajoutés aux URL représentent encore une part significative des problèmes de crawl. Quand votre site colle un identifiant de session unique sur chaque URL (du type ?sid=12345), Googlebot traite chaque session comme une page unique. Cela crée une masse énorme de contenu quasi dupliqué qui dilue la valeur de la page principale et gaspille le budget de crawl sur des URL temporaires et inutiles. Une gestion de session moderne doit reposer sur les cookies, pas sur les paramètres d’URL. Si votre site est encore sur des identifiants de session en URL, c’est une dette technique à régler quel que soit votre budget de crawl, parce qu’elle crée aussi des problèmes de contenu dupliqué qui pèsent directement sur le classement.

Espaces infinis (widgets calendrier, plugins événements)

Les espaces infinis sont des URL générées par des widgets calendrier, des sélecteurs de date ou des paginations qui permettent à Googlebot d’enchaîner les « suivant » sans fin. Si un widget de calendrier produit une URL valide pour chaque mois jusqu’à l’an 3000, Googlebot peut tenter de tout crawler. Illyes a évoqué des cas où des plugins déposaient ces pièges infinis sur chaque chemin du site, enfermant le crawler dans une boucle de contenu vide qui épuisait le budget avant d’atteindre les pages utiles. Auditez votre site pour identifier toute fonctionnalité qui génère une série infinie d’URL, et bloquez ces motifs dans robots.txt.

L’enseignement 2025 de Gary Illyes : la vitesse compte plus que la taille

L’enseignement le plus important du podcast 2025 d’Illyes, c’est que la vitesse serveur compte plus que le volume de pages pour le budget de crawl. « Si vous faites des appels de base de données coûteux, ça va peser lourd sur le serveur », a-t-il rappelé. Un site de quelques centaines de milliers de pages plombé par des requêtes SQL lentes, un rendu dynamique mal calibré ou une configuration serveur médiocre peut souffrir davantage en crawlabilité qu’un site statique de plus d’un million de pages. Améliorer le temps de réponse serveur peut multiplier sensiblement votre taux de crawl quotidien, parce que Googlebot peut demander plus de pages par minute quand chaque réponse arrive plus vite. Cela rejoint la hiérarchie de priorités de notre guide d’optimisation de la vitesse de site : régler le TTFB en premier, parce que des réponses serveur rapides bénéficient à la fois aux utilisateurs et à Googlebot. Illyes a aussi précisé que ce n’est pas le crawl qui consomme le plus de ressources chez Google : « Ce n’est pas le crawl qui mange les ressources. C’est l’indexation et potentiellement la diffusion, ou ce que vous faites avec la donnée quand vous la traitez. » Concrètement, même si Googlebot crawle votre page, si le contenu est faible, lent à rendre ou redondant, Google peut décider de ne pas l’indexer, et le crawl est perdu des deux côtés.

Comment optimiser votre budget de crawl

Régler la vitesse serveur d’abord

À la lumière de l’enseignement 2025 d’Illyes, la bonne hiérarchie pour l’optimisation du budget de crawl est : vitesse serveur d’abord, qualité du contenu ensuite, volume d’URL en troisième. Réduisez votre temps de réponse serveur (TTFB) sous 200 ms pour les pages en cache et sous 600 ms pour les pages dynamiques. À elle seule, cette amélioration peut faire bondir le nombre de pages que Googlebot crawle chaque jour. Utilisez LiteSpeed ou Nginx plutôt qu’Apache, activez un cache côté serveur, optimisez vos requêtes SQL et déployez un CDN.

Nettoyer votre robots.txt

Votre fichier robots.txt est l’outil principal pour dire à Googlebot ce qu’il ne doit pas crawler. Utilisez des règles disallow pour bloquer les motifs d’URL qui gaspillent du budget : paramètres de navigation à facettes, paramètres d’action (add-to-cart, wishlist, comparator), résultats de recherche interne, dossiers admin et staging, espaces infinis type calendriers et dates, versions imprimables ou PDF des pages. Soyez précis dans vos disallow. Une règle type Disallow: /*?* bloque toutes les URL paramétrées, ce qui peut emporter des pages légitimes. Ciblez plutôt des paramètres précis : Disallow: /*?color=, Disallow: /*?sort=, Disallow: /*?sid=. Souvenez-vous que robots.txt bloque le crawl, pas l’indexation. Si une URL bloquée a des liens externes qui pointent vers elle, Google peut quand même indexer l’URL (en l’affichant sans description), même s’il ne peut pas crawler le contenu. Pour les pages qui ne doivent pas du tout apparaître dans la recherche, utilisez une balise meta noindex, en plus du robots.txt ou à la place. Notre guide sitemaps XML et robots.txt détaille les motifs qui comptent vraiment pour WordPress et WooCommerce.

Optimiser votre sitemap XML

Votre sitemap XML doit être une liste choisie de vos pages importantes, pas un déversement exhaustif de toutes les URL du site. N’incluez que les pages que vous voulez voir indexées : pages de contenu principales, pages produit, pages catégorie, articles de blog. Excluez ce qui ne doit pas remonter dans les résultats : pages d’admin, archives minces, paginations, vues filtrées, et toute page en noindex. Gardez votre sitemap à jour. Si vous ajoutez ou modifiez du contenu, le sitemap doit refléter ces changements. La plupart des plugins SEO WordPress (Yoast, Rank Math, AIOSEO) génèrent et mettent à jour le sitemap automatiquement. Soumettez-le dans Google Search Console et vérifiez régulièrement le rapport sitemap pour confirmer que Google y accède et que le nombre d’URL soumises correspond à peu près au nombre d’URL indexées.

Corriger les chaînes de redirection

Une chaîne de redirection apparaît quand l’URL A redirige vers B, qui redirige vers C, qui aboutit enfin à la page cible. Chaque saut consomme une requête de crawl sans rien rendre d’indexable. Google a indiqué qu’il suit jusqu’à 10 redirections successives, mais chacune d’elles gaspille du budget et ajoute de la latence. Crawlez votre site avec Screaming Frog et repérez les chaînes de plus d’un saut. Réparez-les en pointant la première redirection directement vers la destination finale. Identifiez et corrigez aussi les liens internes qui pointent vers des URL redirigées plutôt que vers la cible définitive. Notre guide sur les redirections 301 et migrations de site détaille la procédure complète.

Maîtriser le contenu dupliqué

Le contenu dupliqué gaspille du budget de crawl parce que Googlebot crawle plusieurs URL qui servent toutes le même contenu. Sources fréquentes de duplication : versions HTTP et HTTPS d’une même page, versions www et non-www, URL avec et sans slash final, variantes par paramètres, pages d’archives paginées. Utilisez des redirections 301 pour résoudre les variantes de protocole et de www (un site doit toujours résoudre sur une seule version canonique). Utilisez des balises canoniques pour le contenu qui existe légitimement sur plusieurs URL (un produit dans plusieurs catégories). Utilisez meta noindex pour le contenu qui doit exister pour les utilisateurs mais pas pour les moteurs (archives par tag ou par date dans WordPress).

Gérer les crawlers IA

Une préoccupation grandissante en 2025 et 2026, c’est l’arrivée massive des crawlers IA. Des bots comme GPTBot (OpenAI), ClaudeBot (Anthropic) et toute une grappe d’autres crawlers d’entraînement ou de récupération consomment désormais des ressources serveur significatives. Les rapports bots de Cloudflare publiés en 2025 montrent que les crawlers IA pèsent une part substantielle de la bande passante sur de nombreux sites, parfois équivalente ou supérieure aux moteurs traditionnels. Si vos logs serveur révèlent un trafic crawler IA important, envisagez de bloquer les crawlers d’entraînement (type GPTBot) tout en gardant ouverts les crawlers de récupération qui peuvent citer votre contenu dans les recherches IA. La distinction est importante : tout bloquer protège votre bande passante mais peut réduire votre visibilité dans la recherche pilotée par IA. Une approche sélective bloque les bots d’entraînement et garde les bots de récupération qui apportent du trafic. Notre guide pour contrôler l’accès des crawlers IA détaille les user-agents à bloquer, à autoriser ou à limiter en débit.

Surveiller le budget de crawl : outils et techniques

Statistiques de crawl Google Search Console

Google Search Console fournit des statistiques de crawl sous Paramètres puis Statistiques de crawl. Le rapport montre le nombre total de requêtes de crawl par jour, le temps de réponse moyen et la part de chaque code HTTP de réponse. Un rapport sain affiche une activité de crawl quotidienne stable (sans à-coups violents), un temps de réponse moyen sous 500 ms, une forte part de réponses 200 (OK) et un minimum de 404, 500 ou redirections. Si votre taux de crawl baisse dans le temps sans changement de votre côté, ça peut indiquer que Google réduit sa demande à cause de signaux de qualité ou de problèmes de performance serveur. Surveillez aussi le rapport Couverture, en particulier les catégories « Détectées, actuellement non indexées » et « Explorées, actuellement non indexées ». La première signale des pages que Google a trouvées mais qu’il a choisi de ne pas crawler (potentiel problème de budget de crawl), la seconde des pages qu’il a crawlées mais choisi de ne pas indexer (problème de qualité de contenu, pas de budget de crawl).

Analyse des logs serveur

Pour comprendre en détail comment Googlebot interagit avec votre site, analysez les logs d’accès du serveur. Ils montrent chaque requête de Googlebot, l’URL exacte crawlée, le code de réponse renvoyé, l’heure de chaque requête et la fréquence des visites par section du site. Des outils comme Screaming Frog Log Analyzer, Oncrawl, ou même des scripts maison, parsent ces logs et révèlent si Googlebot passe son temps sur votre contenu important ou s’il s’enferme dans des motifs d’URL à faible valeur. Si vos logs montrent Googlebot crawlant des milliers d’URL de navigation à facettes pendant qu’il touche à peine vos nouveaux articles de blog, vous avez un vrai problème de répartition du budget de crawl, qu’il faut traiter avec des règles robots.txt et un meilleur maillage interne. L’analyse des logs révèle aussi l’activité des crawlers IA : repérez les user-agents type GPTBot, ClaudeBot, CCBot et autres pour mesurer combien de ressources ils consomment et savoir si en bloquer une partie libérerait de la capacité pour Googlebot.

Quand ne pas se préoccuper du budget de crawl

Si votre site fait moins de 10 000 pages, le budget de crawl n’est presque jamais votre problème. Même jusqu’à 100 000 pages, Mueller a confirmé que Google encaisse ce volume sans contrainte. Si vos nouvelles pages sont indexées en un jour ou deux après publication, votre budget de crawl va bien. Si la catégorie « Détectées, actuellement non indexées » ne grossit pas dans Search Console, votre budget de crawl va bien. Concentrez votre énergie sur la qualité du contenu, la vitesse, le maillage interne et les fondamentaux qui ont un impact bien plus large sur le classement. L’erreur la plus courante en SEO est d’imputer un problème d’indexation au budget de crawl alors que le vrai sujet est un contenu mince, dupliqué ou non maillé depuis des pages importantes. Google ne refuse pas de crawler vos pages à cause d’une limite de budget sur un petit site. Il refuse d’indexer des pages qui n’atteignent pas son seuil de qualité.

Conclusion

Le budget de crawl est un vrai concept technique qui compte pour les sites larges et complexes. Mais pour la grande majorité du web, il est, comme le dit Mueller, surévalué. La hiérarchie correcte pour optimiser le budget de crawl, c’est : régler la vitesse serveur en premier (parce que des réponses rapides permettent à Googlebot de crawler plus en moins de temps), nettoyer les pièges structurels en deuxième (navigation à facettes, paramètres d’action, identifiants de session, espaces infinis), gérer le volume d’URL en troisième (via robots.txt, sitemaps et balises canoniques). Si votre site fait moins de 100 000 pages et que votre serveur répond en moins de 500 ms, investissez votre temps dans le contenu et le netlinking plutôt que dans le budget de crawl. Si vous opérez un gros e-commerce ou un portail de contenu et que vous voyez « Détectées, actuellement non indexées » grossir dans Search Console, alors l’optimisation du budget de crawl mérite votre attention, et les correctifs de cet article vous aideront à récupérer les ressources actuellement gaspillées sur des URL sans valeur.

LaFactory conçoit et optimise des architectures de sites depuis 1996. Nos audits SEO technique incluent une analyse de logs serveur qui montre exactement où Googlebot passe son temps sur votre site et comment réorienter cette attention vers vos contenus les plus précieux. Contactez-nous pour un audit qui identifie la vraie cause de vos problèmes d’indexation.