Book now

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

par Francis Rozange | Mar 27, 2026 | SEO

Technical SEO

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

Le budget de crawl est l’un de ces concepts SEO qui génère énormément de discussions, la plupart inutiles pour la majorité des sites. John Mueller de Google a été direct sur ce point : « À mon avis, le budget de crawl est surestimé. La plupart des sites n’ont jamais besoin de s’en préoccuper. » Gary Illyes, qui a écrit l’article original de blog de Google sur le budget de crawl en 2017, a confirmé en 2025 que le seuil d’un million de pages à partir duquel le budget de crawl commence à compter n’a pas changé. Si ton site compte moins de 100 000 pages, Mueller a affirmé que c’est « généralement pas assez pour affecter le budget de crawl ». Mais pour les grandes boutiques e-commerce, les sites avec navigation à facettes , les portails avec des URL paramétriques, ou les sites ayant un historique de migrations, le budget de crawl peut être le goulot d’étranglement invisible qui explique pourquoi tes pages n’apparaissent pas dans Google malgré un bon contenu. Cet article explique ce que le budget de crawl est réellement selon l’équipe de Google, quand il compte vraiment, et comment arrêter de le gaspiller. faceted navigation, portals with parametric URLs, or sites with a history of migrations, crawl budget can be the invisible bottleneck that explains why your pages are not appearing in Google despite having good content. This article explains what crawl budget actually is according to Google’s own team, when it genuinely matters, and how to stop wasting it.

Ce que le budget de crawl est réellement (selon Google)

Le concept de budget de crawl n’a pas été créé à l’intérieur de Google. Il a été inventé par la communauté SEO, et Google a finalement adopté une définition pour correspondre à la conversation externe. Gary Illyes a expliqué sur le podcast Search Off the Record : « Pendant longtemps, nous disions que nous n’avions pas le concept de budget de crawl. Et c’était vrai. Nous n’avions pas quelque chose qui pouvait signifier budget de crawl en soi. Et puis, parce que les gens en parlaient, nous avons essayé de venir avec quelque chose. » La définition sur laquelle Google s’est arrêté est « le nombre d’URL que Googlebot peut et est disposé à explorer pour un site donné ». Cela dépend de deux facteurs qui fonctionnent ensemble : la limite de taux de crawl et la demande de crawl. La limite de taux de crawl est le nombre maximal de connexions simultanées que Googlebot établira avec ton serveur sans causer de problèmes. Si ton serveur répond rapidement, Googlebot peut explorer plus de pages dans la même fenêtre de temps. Si ton serveur est lent ou retourne des erreurs, Googlebot réduit son taux de crawl pour éviter de surcharger le serveur. La demande de crawl est le degré auquel Google veut explorer ton site en fonction de facteurs comme la popularité et la fraîcheur de ton contenu, la fréquence à laquelle les pages changent, et l’importance perçue de tes URL. Un site d’actualités qui publie des dizaines d’articles quotidiennement aura une demande de crawl beaucoup plus élevée qu’un site brochure d’entreprise qui change une fois par trimestre.

Quand le budget de crawl compte réellement

Les seuils confirmés par Google

Selon la documentation officielle de Google, le budget de crawl est principalement pertinent dans deux scénarios : les sites avec plus d’un million de pages uniques mises à jour hebdomadairement ou plus fréquemment, et les sites avec plus de 10 000 pages qui changent quotidiennement. Gary Illyes a confirmé en 2025 que le seuil d’un million de pages n’a pas changé depuis 2020. Mueller a séparément confirmé que 100 000 URL est « généralement pas assez pour affecter le budget de crawl ». Pour 99 pour cent des sites d’entreprise, les problèmes qui ressemblent à des problèmes de budget de crawl sont en réalité des problèmes de qualité de contenu, des problèmes de liens internes , ou des problèmes de vitesse du serveur. Si ton site a 5 000 pages et que certains contenus ne sont pas indexés, ne regarde pas le budget de crawl en premier. Vérifie si ce contenu a une valeur utilisateur véritable, s’il est correctement lié à partir de pages autoritaires, et s’il a des problèmes techniques comme des balises noindex, des balises canoniques pointant ailleurs, ou des réponses de serveur lentes. internal linking problems, or server speed problems. If your site has 5,000 pages and some content is not being indexed, do not look at crawl budget first. Check whether that content has genuine user value, whether it is properly linked from authoritative pages, and whether it has technical issues like noindex tags, canonical tags pointing elsewhere, or slow server responses.

Signes que tu as réellement un problème de budget de crawl

L’indicateur le plus fiable d’un véritable problème de budget de crawl est un nombre croissant de pages dans le rapport Couverture de Google Search Console sous « Découverts, pas encore indexés ». Ce statut signifie que Google a trouvé l’URL (via ton sitemap ou tes liens internes) mais a décidé de ne pas l’explorer pour le moment. Si ce nombre est important et croissant, tu pourrais avoir un problème de crawl qui vaut la peine d’être investigué. Les autres signes incluent les nouvelles pages prenant des semaines ou des mois pour apparaître dans l’index de Google malgré d’être dans ton sitemap et correctement liées, les pages importantes montrant des versions en cache périmées dans le cache de Google (indiquant un recrawl peu fréquent), et les journaux du serveur montrant Googlebot passant la plupart de son temps sur les URL de faible valeur plutôt que sur ton contenu important. Vérifie tes statistiques de crawl dans Google Search Console sous Paramètres, puis Statistiques de crawl. Cela te montre combien de pages Google explore par jour, ton temps de réponse moyen, et la distribution de l’activité de crawl sur ton site. Si ton temps de réponse serveur moyen est supérieur à 500 ms, corriger la vitesse du serveur devrait être ta première priorité parce que cela augmente directement le nombre de pages que Googlebot peut explorer dans son budget de temps. Google Search Console Crawl Stats‘s Coverage report under “Discovered, currently not indexed.” This status means Google has found the URL (through your sitemap or internal links) but has decided not to crawl it yet. If that number is large and growing, you may have a crawling problem worth investigating. Other signs include new pages taking weeks or months to appear in Google’s index despite being in your sitemap and properly linked, important pages showing stale cached versions in Google’s cache (indicating infrequent recrawling), and server logs showing Googlebot spending most of its time on low-value URLs rather than your important content. Check your crawl stats in Google Search Console under Settings, then Crawl stats. This shows you how many pages Google is crawling per day, your average response time, and the distribution of crawl activity across your site. If your average server response time is above 500ms, fixing server speed should be your first priority because it directly increases the number of pages Googlebot can crawl within its time budget.

Les quatre principaux destructeurs de budget de crawl (selon Google)

Dans l’épisode « 2025 Wrapped » du podcast Search Off the Record, Gary Illyes et Martin Splitt ont examiné les données internes de Google sur les problèmes de crawl les plus courants. Près de 85 pour cent des problèmes de crawl majeurs proviennent de pièges structurels qui gaspillent les ressources de Googlebot sur des URL inutiles.

Navigation à facettes (50 % de tous les problèmes de crawl)

La navigation à facettes, les options de filtrage et de tri sur les pages de catégories e-commerce, est responsable de la moitié du gaspillage du budget de crawl signalé à l’équipe de Google. Quand une page de catégorie permet aux utilisateurs de filtrer par couleur, taille, prix, marque, matériau, et de trier par popularité, prix, ou évaluation, 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, chacune affichant essentiellement les mêmes produits dans un arrangement légèrement différent. Googlebot tente d’explorer chacune de ces URL, brûlant le budget de crawl sur des pages quasi-dupliquées qui n’ajoutent aucune valeur unique. La correction consiste à bloquer les URL à facettes de l’exploration en utilisant des règles robots.txt pour les modèles de paramètres (comme Disallow: /*?color= ou Disallow: /*?sort=), et à utiliser des balises canoniques pointant toutes les variantes à facettes vers l’URL de catégorie propre. Pour les sites WooCommerce, cela nécessite une configuration prudente parce que WooCommerce génère des URL filtrables par défaut sans contrôles de crawl appropriés.

Paramètres d’action (25 % de tous les problèmes de crawl)

Les paramètres d’action sont des paramètres d’URL générés par les actions des utilisateurs que Googlebot ne devrait jamais explorer : les URL d’ajout au panier, les URL de liste de souhaits, les URL de comparaison, et d’autres paramètres transactionnels. Illyes a plaisanté en disant que « ce que Googlebot tend à ne pas faire est faire du shopping sur Internet. Il n’achètera pas ton sweat à capuche bizarre. » Pourtant, chaque milliseconde que Googlebot passe à explorer une URL d’ajout au panier est un budget gaspillé qui aurait pu être dépensé pour indexer une page de produit ou un article de blog. Bloque ces URL dans robots.txt avec des règles comme Disallow: /*?add-to-cart= et Disallow: /*?wishlist=. La plupart des plates-formes 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 du site.

ID de session (10 % de tous les problèmes de crawl)

Malgré le fait d’être une pratique dépassée, les ID de session ajoutés aux URL représentent toujours 10 pour cent des problèmes de crawl. Quand ton site ajouté un identifiant de session unique à chaque URL (comme ?sid=12345), Googlebot traite chaque session comme une page unique. Cela crée une énorme quantité de contenu quasi-dupliqué qui dilue la valeur de la page principale et gaspille le budget de crawl sur des URL temporaires et inutiles. La gestion de session moderne devrait utiliser des cookies, pas des paramètres d’URL. Si ton site utilise toujours des ID de session basés sur les URL, c’est une dette technique qui a besoin d’être réparée indépendamment du budget de crawl parce que cela crée aussi des problèmes de contenu dupliqué qui affectent directement tes classements.Contenu dupliqué that dilutes the value of the main page and wastes crawl budget on temporary, useless URLs. Modern session management should use cookies, not URL parameters. If your site still uses URL-based session IDs, this is a technical debt that needs fixing regardless of crawl budget because it also creates duplicate content problems that affect your rankings directly.

Espaces infinis (widgets de calendrier, plugins d’événements)

Les espaces infinis sont des URL générées par les widgets de calendrier, les sélecteurs de date, ou la pagination qui permettent à Googlebot de cliquer sur « suivant » indéfiniment. Si un widget de calendrier génère une URL valide pour chaque mois jusqu’à l’année 3000, Googlebot peut essayer d’explorer chacune. Illyes a noté des instances où les plugins ont généré ces pièges infinis sur chaque chemin unique d’un site web, piégeant l’explorateur dans une boucle de contenu vide qui épuise le budget de crawl avant qu’il n’atteigne les pages de valeur. Audite ton site pour toute fonctionnalité qui génère une série infinie d’URL et bloqué ces modèles dans robots.txt.

La révélation 2025 de Gary Illyes : la vitesse compte plus que la taille

Peut-être l’aperçu le plus important de l’apparition du podcast 2025 d’Illyes est que la vitesse du serveur compte plus que le nombre de pages pour le budget de crawl. « Si tu fais des appels de base de données coûteux, cela va coûter beaucoup au serveur », a noté Illyes. Un site web avec quelques centaines de milliers de pages mais affligé de requêtes de base de données lentes, de problèmes de rendu dynamique, ou de configurations de serveur médiocres peut souffrir plus en crawlabilité qu’un site statique avec plus d’un million de pages. L’amélioration du temps de réponse du serveur peut multiplier ton taux de crawl quotidien jusqu’à quatre fois parce que Googlebot peut demander plus de pages par minute quand chaque réponse revient plus rapidement. Cela s’aligne avec la hiérarchie des priorités que nous avons discutée dans notre article d’ optimisation de vitesse de site : répare TTFB en premier, parce que les réponses de serveur rapides bénéficient à tes utilisateurs et à Googlebot. Illyes a aussi clarifié que le crawling n’est pas le principal goulot d’étranglement des ressources de Google. « Ce n’est pas le crawling qui consomme les ressources. C’est l’indexation et potentiellement la distribution, ou ce que tu fais avec les données quand tu traites ces données. » Cela signifie que même si Googlebot explore ta page, si le contenu est de faible qualité, lent à rendre, ou dupliquatif, Google peut choisir de ne pas l’indexer, rendant le crawl une perte des deux côtés. Vitesse du site optimization article: fix TTFB first, because fast server responses benefit both your users and Googlebot. Illyes also clarified that crawling is not the main bottleneck for Google’s resources. “It’s not crawling that is eating up the resources. It’s indexing and potentially serving, or what you are doing with the data when you are processing that data.” This means that even if Googlebot crawls your page, if the content is low quality, slow to render, or duplicative, Google may choose not to index it, making the crawl a waste from both sides.

Comment optimiser ton budget de crawl

Répare la vitesse du serveur en premier

En fonction de l’aperçu 2025 d’Illyes, la priorité correcte pour l’optimisation du budget de crawl est la vitesse du serveur en premier, la qualité du contenu en deuxième, et le volume d’URL en troisième. Réduis ton temps de réponse serveur (TTFB) à moins de 200 ms pour les pages en cache et moins de 600 ms pour les pages dynamiques. Cela seul peut augmenter considérablement le nombre de pages que Googlebot explore par jour. Utilise LiteSpeed ou Nginx au lieu d’Apache, active la mise en cache côté serveur, optimisé les requêtes de base de données, et déploie un CDN. Notre article d’ optimisation de vitesse de site couvre les détails techniques de chacune de ces améliorations. Vitesse du site optimization article covers the technical détails of each of these improvements.

Nettoie ton robots.txt

Ton fichier robots.txt est ton outil principal pour dire à Googlebot ce qu’il ne faut pas explorer. Utilise des règles d’interdiction pour bloquer les modèles d’URL qui gaspillent le budget de crawl : paramètres de navigation à facettes, paramètres d’action (ajouter au panier, liste de souhaits, comparaison), résultats de recherche interne, répertoires d’administration et d’évaluation, espaces basés sur le calendrier et la date infinis, et versions imprimables ou PDF de pages. Sois précis avec tes règles d’interdiction. Une règle comme Disallow: /*?* bloqué toutes les URL paramétrées, ce qui peut inclure des pages légitimes. À la place, cible des paramètres spécifiques : Disallow: /*?color=, Disallow: /*?sort=, Disallow: /*?sid=. Souviens-toi que robots.txt bloqué le crawl mais pas l’indexation. Si une URL bloquée a des liens externes pointant vers elle, Google peut toujours indexer l’URL (l’affichant dans les résultats sans description) même s’il ne peut pas explorer le contenu. Pour les pages qui ne devraient pas du tout apparaître dans la recherche, utilise une balise meta noindex à la place de ou en plus de robots.txt.

Optimise ton sitemap XML

Ton sitemap XML devrait être une liste soignée de tes pages importantes, pas une liste exhaustive de chaque URL sur ton site. Inclus seulement les pages que tu veux que Google indexe : tes pages de contenu principal, pages de produits, pages de catégories, et articles de blog. Exclus les pages qui ne devraient pas apparaître dans les résultats de recherche : pages d’administration, pages d’archives minces, résultats paginés, vues filtrées, et toute page avec une balise noindex. Garde ton sitemap frais. Si tu ajoutes ou mets à jour du contenu, ton sitemap devrait refléter ces changements. La plupart des plugins SEO WordPress (Yoast, Rank Math, AIOSEO) génèrent des sitemaps automatiquement et les mettent à jour quand le contenu change. Soumets ton sitemap à Google Search Console et vérifie le rapport sitemap régulièrement pour vérifier que Google peut y accéder et que le nombre d’URL soumises correspond à peu près au nombre d’URL indexées.

Répare les chaînes de redirection

Une chaîne de redirection se produit quand l’URL A redirige vers l’URL B, qui redirige vers l’URL C, qui atteint finalement la page de destination. Chaque saut dans la chaîne consomme une demande de crawl sans livrer de contenu indexable. Bien que Google ait affirmé qu’il suit jusqu’à 10 redirections dans une chaîne, chacune gaspille le budget de crawl et ajouté de la latence. Explore ton site avec Screaming Frog et cherche les chaînes de redirection plus longues qu’un saut. Répare-les en mettant à jour la redirection d’origine pour pointer directement vers la destination finale. Identifie aussi et répare tous les liens internes qui pointent vers les URL redirigées plutôt que vers la destination finale directement.

Gère le contenu dupliqué

Le contenu dupliqué gaspille le budget de crawl parce que Googlebot explore plusieurs URL qui servent tous le même contenu. Les sources courantes de duplication incluent les versions HTTP et HTTPS de la même page, les versions www et non-www, les versions avec barre oblique finale et sans barre oblique finale, les variations de paramètres d’URL, et les pages d’archives paginées. Utilise les redirections 301 pour résoudre les variations de protocole et www (chaque site devrait se résoudre en une version canonique). Utilise les balises canoniques pour le contenu qui existe légitimement à plusieurs URL (comme les produits dans plusieurs catégories). Utilise meta noindex pour le contenu qui devrait exister pour les utilisateurs mais pas pour les moteurs de recherche (comme les archives de tags ou les archives de dates dans WordPress).

Gère les explorateurs IA

Une préoccupation croissante pour le budget de crawl en 2025 et 2026 est les explorateurs IA. Les bots comme GPTBot (OpenAI), ClaudeBot (Anthropic), et divers autres explorateurs de formation IA et de récupération consomment maintenant des ressources de serveur importantes. Certains rapports indiquent que les explorateurs IA peuvent consommer jusqu’à 40 pour cent de la bande passante d’un site, réduisant les ressources disponibles pour Googlebot. Si tes journaux de serveur montrent un trafic lourd d’explorateurs IA, envisage de bloquer les explorateurs de formation (comme GPTBot) tout en permettant aux explorateurs de récupération qui pourraient citer ton contenu dans les résultats de recherche IA. La distinction compte : bloquer tous les explorateurs IA protège ta bande passante mais peut réduire ta visibilité dans la recherche alimentée par l’IA. Une approche sélective bloqué les bots de formation tout en permettant aux bots de récupération qui génèrent du trafic.

Comment surveiller le budget de crawl

Statistiques de crawl de Google Search Console

Google Search Console fournit des statistiques de crawl sous Paramètres, puis Statistiques de crawl. Ce rapport montre le nombre total de demandes de crawl par jour, le temps de réponse moyen, et le pourcentage de demandes de crawl qui ont retourné des codes de statut HTTP spécifiques. Un rapport de statistiques de crawl sain montre une activité de crawl quotidienne cohérente (pas de fluctuations sauvages), des temps de réponse moyens sous 500 ms, un pourcentage élevé de réponses 200 (OK), et des réponses minimales 404, 500, ou de redirection. Si ton taux de crawl décline au fil du temps sans que tu fasses des changements, cela peut indiquer que Google réduit sa demande de crawl pour ton site à cause de signaux de qualité ou de problèmes de performance du serveur.

Analyse des journaux du serveur

Pour la vue la plus détaillée de la manière dont Googlebot interagit avec ton site, analysé tes journaux d’accès au serveur. Les journaux du serveur affichent chaque demande que Googlebot fait, y compris les URL exactes explorées, les codes de réponse retournés, l’heure de chaque demande, et la fréquence des visites à des sections spécifiques de ton site. Les outils comme Screaming Frog Log Analyzer, Oncrawl, ou même des scripts personnalisés peuvent analyser tes journaux et révéler si Googlebot passe son temps sur ton contenu important ou se fait piéger dans des modèles d’URL de faible valeur. Si tes journaux montrent Googlebot explorant des milliers d’URL de navigation à facettes tout en touchant à peine ton nouveau contenu de blog, tu as un problème de distribution de budget de crawl clair que ton robots.txt doit aborder.

Surveillance du budget de crawl : outils et techniques

Statistiques de crawl de Google Search Console

Google Search Console fournit des statistiques de crawl sous Paramètres, puis Statistiques de crawl. Ce rapport montre le nombre total de demandes de crawl par jour, le temps de réponse moyen, et le pourcentage de demandes de crawl qui ont retourné des codes de statut HTTP spécifiques. Un rapport de statistiques de crawl sain montre une activité de crawl quotidienne cohérente sans fluctuations sauvages, des temps de réponse moyens sous 500 ms, un pourcentage élevé de réponses 200 (OK), et des réponses minimales 404, 500, ou de redirection. Si ton taux de crawl décline au fil du temps sans que tu fasses des changements, cela peut indiquer que Google réduit sa demande de crawl à cause de signaux de qualité ou de problèmes de performance du serveur. Vérifie aussi le rapport Couverture régulièrement, particulièrement les catégories « Découverts, pas encore indexés » et « Explorés, pas encore indexés ». La première indique les pages que Google a trouvées mais a choisi de ne pas explorer (un problème potentiel de budget de crawl), tandis que la dernière indique les pages que Google a explorées mais a choisi de ne pas indexer (un problème de qualité de contenu, pas un problème de budget de crawl).

Analyse des journaux du serveur

Pour la vue la plus détaillée de la manière dont Googlebot interagit avec ton site, analysé tes journaux d’accès au serveur. Les journaux du serveur affichent chaque demande que Googlebot fait, y compris les URL exactes explorées, les codes de réponse retournés, l’heure de chaque demande, et la fréquence des visites à des sections spécifiques de ton site. Les outils comme Screaming Frog Log Analyzer, Oncrawl, ou même des scripts personnalisés peuvent analyser tes journaux et révéler si Googlebot passe son temps sur ton contenu important ou se fait piéger dans des modèles d’URL de faible valeur. Si tes journaux montrent Googlebot explorant des milliers d’URL de navigation à facettes tout en touchant à peine ton nouveau contenu de blog, tu as un problème de distribution de budget de crawl clair que ton robots.txt doit aborder. internal linking improvements. Log analysis also reveals AI crawler activity: look for user agents like GPTBot, ClaudeBot, CCBot, and other AI crawlers to understand how much of your server resources they are consuming and whether blocking some of them would free up capacity for Googlebot.

Quand NE PAS s’inquiéter du budget de crawl

Si ton site a moins de 10 000 pages, le budget de crawl n’est presque certainement pas ton problème. Même jusqu’à 100 000 pages, Mueller a confirmé que Google gère ce volume sans contraintes de budget de crawl. Si tes nouvelles pages sont indexées dans un ou deux jours après la publication, ton budget de crawl va bien. Si tu ne vois pas « Découverts, pas encore indexés » augmenter dans Search Console, ton budget de crawl va bien. Concentre ton énergie sur la qualité du contenu, la vitesse du site, les liens internes, et les autres fondamentaux qui ont un impact beaucoup plus important sur le fait que tes pages se classent bien. L’erreur la plus courante en SEO est d’attribuer les problèmes d’indexation au budget de crawl quand le véritable problème est que le contenu est mince, dupliquatif, ou non lié à partir de nulle part important sur le site. Google ne refuse pas d’explorer les pages à cause de limites de budget sur les petits sites. Il refuse d’indexer les pages parce qu’elles ne répondent pas au seuil de qualité pour l’inclusion dans son index.

Conclusion

Le budget de crawl est un véritable concept technique qui compte pour les sites web grands et complexes. Mais pour la grande majorité des sites sur le web, c’est, comme le dit Mueller, surestimé. L’ordre de priorité correct pour l’optimisation du budget de crawl est : répare la vitesse du serveur en premier (parce que les réponses rapides laissent Googlebot explorer plus en moins de temps), nettoie les pièges de crawl structurels en deuxième (navigation à facettes, paramètres d’action, ID de session, espaces infinis), et gère le volume d’URL en troisième (via robots.txt, sitemaps, et balises canoniques). Si ton site a moins de 100 000 pages et que ton serveur répond en moins de 500 ms, dépense ton temps sur le contenu et la création de liens au lieu du budget de crawl. Si tu exploites une grande boutique e-commerce ou un portail de contenu et que tu vois « Découverts, pas encore indexés » augmenter dans Search Console, alors l’optimisation du budget de crawl vaut ta attention, et les corrections dans cet article t’aideront à récupérer les ressources de crawl qui sont actuellement gaspillées sur des URL qui n’ajoutent aucune valeur.

LaFactory has been building and optimizing website architectures since 1996. Our SEO Technique audits include server log analysis that shows exactly where Googlebot spends its time on your site and how to redirect that attention to your most valuable content. Contactez-nous for an audit that identifies the real cause of your indexing problems.

Sources