Réduire le crawl Google en 2026 : ce qui a remplacé le Crawl Rate Limiter

Réduire le crawl Google, ce n’est pas “mettre Googlebot au ralenti” dès qu’un serveur chauffe un peu. C’est une mesure à manier proprement, parce qu’elle peut ralentir la découverte de nouvelles pages, retarder la mise à jour des contenus existants et laisser plus longtemps en index des URL supprimées.

Depuis la disparition de l’ancien Crawl Rate Limiter dans Search Console, beaucoup de réflexes sont devenus périmés. En 2026, la bonne question n’est plus “où est le bouton pour limiter Googlebot ?”. La vraie question est plus utile : est-ce que le problème vient d’une surcharge serveur temporaire, d’une architecture d’URL trop bruyante, de facettes e-commerce mal cadrées ou d’un site qui répond mal aux crawlers ?

Ce qui a changé depuis l’ancien limiteur Search Console

Google a annoncé fin novembre 2023 la disparition de l’ancien outil de limitation du crawl dans Search Console, avec une suppression effective le 8 janvier 2024. L’argument était assez clair : Googlebot réagit déjà automatiquement aux signaux du serveur, notamment aux erreurs serveur persistantes et aux temps de réponse qui s’allongent.

Autrement dit, la logique moderne est moins “je choisis un curseur dans Search Console” et plus “je sers un site sain, avec des statuts cohérents, et je laisse Google ajuster son passage”. Ce n’est pas plus confortable quand on veut un bouton magique, mais c’est plus proche du fonctionnement réel du web.

La documentation officielle sur la réduction du crawl Google précise aussi que les hausses soudaines de crawl viennent souvent de problèmes très concrets : paramètres d’URL, filtres, calendriers avec trop d’URL, facettes, ou campagnes publicitaires qui poussent Google Ads à revisiter certaines pages.

Quand ralentir Googlebot a vraiment du sens

Ralentir Googlebot a du sens dans deux cas principaux.

Le premier cas est l’urgence serveur. Le site est en panne partielle, le serveur répond lentement, la base de données souffre, un CDN ou un WAF a été mal réglé, ou un pic de crawl arrive au mauvais moment. Là, l’objectif est de protéger l’infrastructure pendant quelques heures ou un à deux jours, pas de modifier durablement la stratégie SEO.

Le second cas est le diagnostic d’un site trop bruyant. Le crawl semble excessif parce que Google découvre trop d’URL sans vraie valeur : facettes infinies, tris, calendriers, pages de recherche internes, combinaisons de filtres vides, archives inutiles, paramètres dupliqués, anciennes URL encore liées. Dans ce cas, ralentir Googlebot ne règle pas la cause. Il faut remettre de l’ordre dans ce que le site laisse explorer.

Pour un petit blog ou un site vitrine qui publie quelques pages par semaine, la réduction du crawl est rarement le bon sujet. Le guide Google sur le crawl budget explique d’ailleurs que les sites modestes n’ont généralement pas besoin d’optimisation avancée, tant que le sitemap reste à jour et que l’indexation est surveillée.

Ce qui remplace l’ancien Crawl Rate Limiter

Il n’y a pas un remplaçant unique. Il y a une combinaison de bons signaux.

• Réponses serveur cohérentes : 200 pour les pages valides, 404 ou 410 pour les pages supprimées, 503 pour une indisponibilité temporaire, 429 si le serveur indique une surcharge.
• Inventaire d’URL propre : pas de multiplication incontrôlée de paramètres, facettes, tris ou calendriers inutiles.
• Sitemap à jour : les pages importantes doivent être listées proprement, avec un lastmod fiable quand il est utile.
• Redirections sobres : éviter les chaînes longues, les anciennes URL empilées et les boucles.
• Pages efficaces : un HTML, des ressources et un rendu suffisamment rapides pour que Google puisse comprendre les pages importantes.

Ce point rejoint l’article sur Googlebot et la limite des 2 Mo pour Google Search. Ce n’est pas exactement le même problème, mais le réflexe est proche : Googlebot doit pouvoir récupérer et comprendre les ressources critiques sans se battre contre un site inutilement lourd.

Tableau : que faire selon le symptôme

Les bons signaux HTTP et les mauvais réflexes

Le point le plus sensible concerne les codes HTTP. Google indique que les statuts 5xx et 429 peuvent pousser ses crawlers à ralentir temporairement. Le 429 est traité comme un signal de surcharge serveur. Le 503 est cohérent pendant une maintenance réelle. Le 500 signale une erreur serveur.

Mais ces codes ne sont pas une stratégie long terme. Si Googlebot voit les mêmes erreurs sur les mêmes URL pendant plusieurs jours, la page peut finir par perdre sa place dans l’index. C’est une solution d’urgence, pas un outil de pilotage éditorial.

La documentation Google sur les codes HTTP et les crawlers est très utile pour clarifier ce point : les statuts 4xx, sauf 429, ne ralentissent pas le crawl. Ils indiquent plutôt que le contenu n’existe pas, qu’il est interdit ou qu’il ne doit pas être utilisé.

Ce sujet croise aussi les sites JavaScript. Une page peut sembler correcte dans Chrome tout en répondant avec un mauvais statut. Si vous avez un front moderne, une SPA ou des routes côté client, relisez le guide sur JavaScript et les pages non-200. Il aide à distinguer le rendu visible et le vrai signal reçu par Googlebot.

Le vrai chantier : l’inventaire d’URL

Quand un site demande “comment réduire le crawl Google ?”, la réponse honnête commence souvent par une autre question : combien d’URL le site laisse-t-il découvrir, et combien d’entre elles méritent vraiment d’être crawlées ?

Google parle de crawl capacity et de crawl demand. La capacité dépend de ce que le serveur peut encaisser. La demande dépend de ce que Google pense utile de revisiter, selon la taille du site, sa fraîcheur, sa qualité, sa popularité, ses changements et son inventaire d’URL connu.

La partie que vous pouvez le plus contrôler, c’est l’inventaire. Un site qui expose des milliers d’URL pauvres donne du travail inutile à Googlebot. Un e-commerce avec des filtres non cadrés peut générer des combinaisons quasiment infinies. Un blog avec des archives, tags, recherches internes et pages pagination sans logique peut diluer le crawl sur des pages secondaires.

La bonne démarche consiste à classer les URL en quatre familles :

• À garder et pousser : pages qui ont une valeur SEO, commerciale ou éditoriale claire.
• À consolider : pages proches qui devraient devenir une seule URL plus forte.
• À laisser mourir proprement : anciennes pages sans équivalent, avec 404 ou 410 assumé.
• À empêcher d’être explorées : filtres, tris ou espaces techniques sans intérêt pour Search.

Les commandes Google peuvent aider à repérer certaines bizarreries, mais elles ne suffisent pas. L’article sur les commandes Google encore utiles en 2026 explique justement pourquoi il faut les croiser avec Search Console, les logs, le sitemap et un crawl de site.

Facettes, filtres et paramètres : le cas classique

Les facettes sont un des meilleurs exemples de problème qui ressemble à un crawl excessif alors qu’il s’agit surtout d’une architecture d’URL trop ouverte. Couleur, taille, prix, marque, disponibilité, note, tri, ordre d’affichage, page, région : chaque combinaison peut créer une nouvelle URL.

Google explique dans son guide sur la navigation à facettes que ces URL peuvent consommer beaucoup de ressources et ralentir la découverte des pages utiles. Si les facettes n’ont pas vocation à apparaître dans Google, robots.txt peut être plus efficace que de compter sur des canonicals ou des liens nofollow. Si certaines facettes doivent être indexables, elles doivent suivre une logique stable : paramètres propres, ordre cohérent, combinaisons utiles, pages vides en 404.

La nuance est importante. Bloquer toutes les facettes peut priver un site de pages catégorie intéressantes. Les laisser toutes ouvertes peut créer un labyrinthe. Il faut choisir les filtres qui correspondent à une vraie demande, puis fermer le reste proprement.

Avant de chercher à ralentir Googlebot, il faut d'abord comprendre ce qu'il rencontre : les logs serveur après migration permettent de distinguer surcharge, erreurs HTTP, DNS et simples fluctuations temporaires.

Ce qu’un site doit vérifier avant d’agir

Avant de chercher à ralentir Googlebot, vérifiez d’abord ce que Google rencontre réellement. Sur un site qui vient de migrer, qui a changé d’hébergement, de CDN, de thème ou d’architecture front, la hausse de crawl peut être temporaire. Sur un gros site e-commerce, elle peut révéler un problème plus profond.

Les points à contrôler en priorité :

• Logs serveur : volume de requêtes Googlebot, statuts reçus, chemins les plus demandés, profondeur, fréquence.
• Rapport Pages Search Console : découvertes non indexées, explorées non indexées, soft 404, pages avec redirection.
• Sitemap : présence des vraies pages importantes, retrait des URL supprimées, dates de modification cohérentes.
• Robots.txt : blocage des zones inutiles, sans masquer des pages qui devraient être explorées.
• Statuts HTTP : 200, 301, 404, 410, 429, 503, et absence de maintenance en 200.
• Modèles de pages : catégories, filtres, pagination, recherche interne, tags, archives, pages vides.
• Performance serveur : temps de réponse réel, erreurs 5xx, saturation base de données, cache, CDN et WAF.

Sur les pages très lourdes, lisez aussi la question du poids des ressources dans l’article sur Googlebot et les 2 Mo. Un site peut perdre en efficacité de crawl parce qu’il multiplie les URL, mais aussi parce que ses pages importantes sont trop lentes, trop lourdes ou trop dépendantes de scripts fragiles.

Méthode de diagnostic en 30 minutes

Voici une méthode simple pour éviter de réagir trop vite.

1. Ouvrez Search Console et regardez si le problème concerne l’exploration, l’indexation ou seulement quelques URL isolées.
2. Regardez les logs récents si vous y avez accès : top URL crawlées, statuts, user agents, dates, pics et chemins récurrents.
3. Comparez sitemap et URLs demandées : si Googlebot passe surtout sur des pages absentes du sitemap, cherchez d’où elles viennent.
4. Listez les paramètres et facettes les plus fréquents : tris, filtres, pagination, recherches internes, calendriers, tags.
5. Testez les statuts HTTP sur dix URL représentatives : page valide, page supprimée, filtre vide, redirection, pagination, maintenance.
6. Décidez si c’est une urgence : si le serveur souffre vraiment, utilisez des statuts temporaires cohérents. Si le serveur tient, corrigez d’abord l’inventaire d’URL.
7. Documentez la correction : ce qui a été bloqué, redirigé, supprimé, consolidé, ajouté au sitemap ou corrigé côté modèle de page.

Le piège est de traiter tous les signaux comme une crise. Parfois, Googlebot revient plus fort après une refonte, une migration ou un gros nettoyage. C’est normal pendant un temps. Ce qui compte, c’est de savoir si ce crawl sert à redécouvrir des pages importantes ou s’il tourne dans des zones faibles.