Le vieux limiteur de crawl Search Console a disparu. Voici ce qu’il faut faire aujourd’hui pour ralentir Googlebot proprement quand la charge serveur l’exige.
Sommaire
Ce qui a changé depuis la Search Console d’avant
Beaucoup de professionnels ont gardé en tête l’ancien outil de limitation du crawl dans Search Console. Google a pourtant annoncé sa dépréciation fin novembre 2023, avant la suppression effective du vieux Crawl Rate Limiter le 8 janvier 2024.
En 2026, si vous voulez ralentir Googlebot, vous ne passez plus par un petit réglage manuel dans l’interface. Il faut agir via le comportement du serveur, la qualité des réponses HTTP et l’architecture du site.
Quand ralentir Googlebot a du sens
Ce n’est pas un objectif normal pour un site qui tourne bien. Réduire le crawl devient pertinent si :
- le serveur montre des signes de saturation
- un site en migration ou en maintenance renvoie des erreurs
- un grand catalogue multiplie les URL parasites
- des filtres ou facettes font exploser les explorations inutiles
Dans beaucoup de cas, le vrai sujet n’est pas “réduire Google”, mais nettoyer le site.
Ce qui remplace l’ancien limiteur
Aujourd’hui, Google recommande surtout une approche technique :
- renvoyer un 429 si la charge devient anormale
- utiliser un 503 temporaire pendant une maintenance réelle
- surveiller les logs
- réduire les URL inutiles
- clarifier les gabarits, les facettes et la navigation
Ce point rejoint directement notre article sur Googlebot et la limite des 2 Mo pour Google Search, car un site lourd et un site mal structuré finissent souvent par créer le même type de tension côté crawl.
La documentation Google sur la réduction du crawl précise d’ailleurs que les signaux 500, 503 ou 429 jouent sur tout le hostname, et que cette logique doit rester courte. De son côté, le guide sur le crawl budget insiste surtout sur l’inventaire d’URL, les duplications, les soft 404 et les longues chaînes de redirection.
Les erreurs classiques à éviter
La première erreur est de vouloir ralentir Google sans diagnostiquer la cause. Si le problème vient d’une architecture gonflée, d’un front JavaScript fragile ou de milliers d’URL sans valeur, le simple ralentissement ne règle rien.
La deuxième erreur est d’envoyer de mauvais signaux HTTP. Un code 200 sur une page en erreur, une maintenance bricolée ou un front qui casse le rendu JS créent plus de confusion qu’ils n’aident. C’est justement pour cela que notre point sur JavaScript et les pages non-200 mérite d’être lu en complément.
À l’inverse, Google a aussi rappelé dans son billet Don’t use 403s or 404s for rate limiting qu’il ne faut pas bricoler cette logique avec des 403 ou 404 pour ralentir Googlebot.
Ce qu’un site doit vérifier avant d’agir
- l’état réel du serveur
- la volumétrie des URL explorées
- les réponses HTTP
- les modèles de pages qui génèrent du bruit
- la présence ou non de paramètres, facettes et duplications
Si vous travaillez avec un stack large mêlant SEO, e-commerce et veille concurrentielle, un environnement rationalisé peut aussi simplifier les arbitrages. Notre article sur quel outil mutualisé choisir pour l’e-commerce et les ads parle justement de ce type de compromis côté budget et workflow.
Sources officielles utiles : annonce sur la fin du Crawl Rate Limiter, documentation Google pour réduire le crawl, guide crawl budget.
FAQ
Peut-on encore réduire le crawl depuis Search Console ?
Non, l’ancien outil de limitation a été retiré. Il faut désormais passer par une gestion technique plus propre du site et du serveur.
Quand utiliser un code 429 ?
Quand la charge du serveur devient vraiment trop forte et qu’il faut indiquer à Google de ralentir.
Le 503 doit-il être permanent ?
Non. Il sert à un état temporaire, par exemple une maintenance réelle.
Le vrai problème est-il souvent le crawl lui-même ?
Pas toujours. Très souvent, le problème vient surtout d’une architecture d’URL trop bruyante ou d’un site mal nettoyé.
