Cadence d’exploration

En bref — La cadence d’exploration indique à quelle vitesse un moteur de recherche récupère les pages de votre site. Google la règle automatiquement selon la santé de votre serveur : il n’existe plus de bouton pour l’augmenter ou la réduire. Si votre serveur est saturé, il faut l’accélérer ou, pendant un ou deux jours seulement, lui faire renvoyer une erreur signalant de ralentir. Une exploration plus rapide n’améliore pas votre classement.

Qu’est-ce que la cadence d’exploration ?

Lorsqu’un moteur de recherche explore votre site, il ne récupère pas toutes les pages en même temps : il régule son rythme. La cadence d’exploration correspond à ce rythme, c’est-à-dire au nombre de pages récupérées à un instant donné et au délai entre les requêtes. Googlebot explore pour Google, Bingbot pour Bing. Evidence for this claim Google defines crawl capacity using simultaneous connections and the delay between fetches, adjusted according to site responses. Scope: Google crawler capacity, not a ranking factor. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Cette régulation vise avant tout à ménager le serveur. Un robot pourrait facilement submerger une petite infrastructure en demandant des centaines de pages par seconde. Il observe donc les réponses du site et ralentit dès que le serveur montre des signes de difficulté. Des réponses rapides l’autorisent à accélérer légèrement ; des lenteurs ou des erreurs l’incitent à réduire son activité.

Le changement majeur

Pendant des années, les conseils recommandaient de réduire la cadence à l’aide d’un curseur dans Search Console. Ce curseur n’existe plus : Google l’a supprimé le 8 janvier 2024. Tout tutoriel qui conseille encore de le régler est donc obsolète. Evidence for this claim Google deprecated the Search Console crawl-rate limiter and removed it on January 8, 2024. Scope: Google Search Console's legacy crawl-rate limiter. Confidence: high · Verified: 2026-07-14 Google: Crawl rate limiter deprecation

La cadence est aujourd’hui automatique. Vous ne la réglez pas : Google interprète les réponses de votre serveur et décide.

Comment ralentir Googlebot

Si votre serveur est réellement surchargé, procédez dans cet ordre :

1. Accélérez le serveur ou augmentez ses ressources. C’est la véritable solution. Googlebot peut explorer plus sereinement un serveur rapide et sain.
2. Uniquement en cas d’urgence réelle : faites renvoyer par le serveur une erreur 500, 503 ou 429 à la place de la page normale. Google l’interprète presque immédiatement comme une demande de ralentissement. Ne maintenez toutefois ce dispositif que pendant un ou deux jours au maximum : au-delà, Google peut commencer à retirer vos pages des résultats de recherche.

À ne pas faire : ne bloquez pas Googlebot avec des erreurs 403 ou 404 — elles ne ralentissent pas l’exploration et risquent de faire disparaître des pages — et ne comptez pas sur crawl-delay dans robots.txt. Google ignore cette directive, contrairement à Bing.

Peut-on accélérer l’exploration de Google ?

Pas à la demande : il n’existe aucun bouton pour « explorer davantage » et vous ne pouvez pas solliciter une augmentation. Vous pouvez seulement l’encourager indirectement grâce à un serveur plus rapide, un sitemap propre, de bons liens internes et la suppression des URL dupliquées ou inutiles. Mais explorer davantage n’est pas un objectif en soi : cela ne vous fera pas mieux classer.

Vous cherchez le détail des codes d’état, l’historique de la suppression de l’outil et les différences avec Bing ? Passez à l’onglet Advanced.

En bref — La cadence d’exploration représente l’offre dans le budget d’exploration : la vitesse de récupération déterminée par ce que Google appelle la limite de capacité d’exploration (connexions parallèles et délai entre les requêtes). Automatique, elle réagit à la santé du serveur ; le curseur manuel de GSC a disparu le 8 janvier 2024. Pour ralentir Googlebot, utilisez aujourd’hui des signaux HTTP : 500, 503 ou 429 pendant un à deux jours au maximum, jamais 401, 403 ou 404. Google ignore crawl-delay, que Bing respecte. Vous ne pouvez pas demander une hausse : améliorez indirectement la capacité. Bing conserve une grille manuelle Crawl Control. La cadence d’exploration n’est pas un facteur de classement et la plupart des sites n’ont jamais à la régler.

Ce qu’est réellement la cadence d’exploration

La cadence d’exploration est la vitesse à laquelle un robot récupère les pages de votre serveur : nombre de requêtes simultanées et délai entre celles-ci. Google parle de limite de capacité d’exploration : “the maximum number of simultaneous parallel connections that Google can use to crawl a site, as well as the time delay between fetches.” (traduction) « le nombre maximal de connexions parallèles simultanées que Google peut utiliser pour explorer un site, ainsi que le délai entre les récupérations ». Evidence for this claim Google defines crawl capacity using simultaneous connections and the delay between fetches, adjusted according to site responses. Scope: Google crawler capacity, not a ranking factor. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Elle constitue une moitié du budget d’exploration. Comme je l’explique dans mon guide Ahrefs sur le budget d’exploration, celui-ci se décompose en “crawl demand which is how many pages a search engine wants to crawl on your site and crawl rate which is how fast they can crawl.” (traduction) « la demande d’exploration, soit le nombre de pages qu’un moteur souhaite explorer sur votre site, et la cadence d’exploration, soit la vitesse à laquelle il peut les explorer ». La cadence correspond à l’offre — ce que votre serveur peut accepter — et la demande à ce que le moteur souhaite explorer. Le budget se situe à leur rencontre ; le classement reste entièrement extérieur à cette boucle.

Dans ma présentation How Search Works, je résume la limite de cadence à ce que votre site peut supporter. Elle dépend de la stabilité et de la santé du serveur, des réponses lentes, des erreurs 5xx et des réponses 429. Google ralentit lorsque le serveur peine, car il ne veut pas provoquer sa panne. Un détail souvent oublié : tous les Googlebots partagent un même quota d’exploration. Les robots de recherche, d’images, d’annonces et les autres puisent dans la même capacité ; l’emballement d’un type de ressource réduit donc l’exploration de toutes les autres.

Ce qui détermine la cadence d’exploration

La limite de capacité est automatique et réagit en temps réel au serveur. Google explique : “If the site responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traduction) « Après une période de réponses rapides, la limite augmente et autorise davantage de connexions d’exploration. Si le site devient lent ou produit des erreurs serveur, elle diminue et Google réduit ses passages. »

Un second levier vous échappe : les propres ressources de Google. “Google has a lot of machines, but not infinite machines. We still need to make choices with the resources that we have.” (traduction) « Google dispose d’un grand nombre de machines, mais leur nombre n’est pas infini : il doit encore arbitrer l’emploi de ses ressources. » La santé du serveur fixe donc le plafond que Google est prêt à utiliser, tandis que la capacité de Google et la demande d’exploration du site déterminent la part réellement consommée.

La documentation sur les idées reçues confirme que la santé du serveur agit dans les deux sens : “A speedy site is a sign of healthy servers, so it can get more content over the same number of connections,” (traduction) « Un site rapide est le signe de serveurs sains ; il est donc possible d’obtenir davantage de contenu avec le même nombre de connexions », tandis que “a significant number of 5xx HTTP response status codes (server errors) or connection timeouts signal the opposite, and crawling slows down.” (traduction) « un nombre important de codes d’état HTTP 5xx (erreurs serveur) ou de délais de connexion dépassés indique le contraire, et l’exploration ralentit ».

La cadence d’exploration influe-t-elle sur le classement ? Non.

Écartons d’abord cette idée reçue, à l’origine de nombreux efforts inutiles. L’exploration est nécessaire pour apparaître dans les résultats, mais ce n’est pas un signal de classement. Google l’affirme : “Improving your crawl rate won’t necessarily lead to better positions in Google Search results.” (traduction) « Améliorer votre cadence d’exploration n’entraîne pas nécessairement de meilleures positions dans les résultats de recherche Google. » Une exploration plus rapide ou plus abondante accélère la découverte et l’indexation des nouveautés, pas leur classement. La cadence relève uniquement de l’efficacité et de la santé du serveur.

Comment réduire la cadence d’exploration de Googlebot

Voici les mesures à prendre, de la solution durable au levier d’urgence :

1. Corriger le serveur — la vraie solution. Accélérez-le ou ajoutez des ressources. Puisque la limite de capacité suit le temps de réponse et les erreurs, un serveur plus sain maintient durablement l’exploration à un niveau confortable, sans risquer l’indexation.

2. Le levier d’urgence — 500, 503 ou 429. Google recommande de “return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (traduction) « renvoyer aux requêtes d’exploration un code d’état HTTP 500, 503 ou 429 à la place de 200 ». Ses robots “treat the 429 status code as a signal that the server is overloaded,” (traduction) « considèrent le code d’état 429 comme un signal de surcharge du serveur », et “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling.” (traduction) « les erreurs serveur 5xx et 429 incitent temporairement les robots de Google à ralentir l’exploration ». Gary Illyes a précisé la rapidité de réaction : “if the server persistently returns HTTP 500 status codes for a range of URLs, Googlebot will automatically, and almost immediately slow down crawling.” (traduction) « si le serveur renvoie continuellement des codes HTTP 500 pour un ensemble d’URL, Googlebot ralentira automatiquement et presque immédiatement son exploration ». Préférez 429 lorsque c’est possible : il signifie explicitement « trop de requêtes » et peut inclure un en-tête Retry-After.

Mais ce dispositif doit rester strictement temporaire. Google avertit : “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days).” (traduction) « Nous déconseillons de le faire pendant une longue période, c’est-à-dire plus d’un à deux jours. » Le maintenir entraîne un coût réel : si ces codes persistent plusieurs jours pour la même URL, “the URL may be dropped from Google’s index” (traduction) « l’URL peut être retirée de l’index de Google » et, pour Google Ads, “your campaigns may be cancelled or paused, and your ads may not serve.” (traduction) « vos campagnes peuvent être annulées ou suspendues, et vos annonces peuvent ne plus être diffusées ».

3. Ce qu’il ne faut PAS faire. N’utilisez pas les codes 4xx pour limiter la cadence. “The 4xx status codes, except 429, have no effect on crawl rate,” (traduction) « Les codes d’état 4xx, à l’exception de 429, n’ont aucun effet sur la cadence d’exploration », et Google précise : “Don’t use 401 and 403 status codes for limiting the crawl rate.” (traduction) « N’utilisez pas les codes 401 et 403 pour limiter la cadence d’exploration. » Dans un billet de 2023 consacré à cette pratique, Google écrivait : “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate. The short version of this blog post is: please don’t do that…” (traduction) « Ces derniers mois, nous avons constaté que davantage de propriétaires de sites et certains réseaux de diffusion de contenu tentaient d’utiliser des erreurs client 404 et d’autres erreurs 4xx, sauf 429, pour réduire la cadence de Googlebot. En bref : ne faites pas cela… » N’utilisez pas non plus crawl-delay dans robots.txt : “The non-standard ‘crawl-delay’ robots.txt rule is not processed by Google’s crawlers.” (traduction) « La règle non standard crawl-delay de robots.txt n’est pas traitée par les robots de Google. »

4. La demande hors urgence. Si le problème persiste sans constituer une crise, vous pouvez “file a special request to report a problem with unusually high crawl rate, mentioning the optimal rate for your site.” (traduction) « envoyer une demande spéciale pour signaler une cadence d’exploration anormalement élevée, en indiquant la cadence optimale pour votre site ». Cette procédure est lente et ne fonctionne que dans un sens.

Peut-on augmenter la cadence ? Non, pas directement.

Aucune augmentation manuelle n’est possible. Google indique : “You cannot request an increase in crawl rate, and it may take several days for the request to be evaluated and fulfilled.” (traduction) « Vous ne pouvez pas demander une augmentation de la cadence d’exploration, et l’évaluation puis l’exécution de la demande peuvent prendre plusieurs jours. » Vous pouvez en revanche agir indirectement. Mon guide sur le budget d’exploration décrit les leviers utiles : accélérer le serveur ou ajouter des ressources, conserver les pages importantes dans des sitemaps propres, supprimer le contenu dupliqué, obtenir davantage de liens externes et internes, corriger les liens redirigés, préférer GET à POST lorsque c’est possible et utiliser l’API d’indexation si votre contenu y est admissible. Le principe “a speedy site… can get more content over the same number of connections” (traduction) « un site rapide peut fournir davantage de contenu avec le même nombre de connexions » montre que la santé du serveur intervient aussi bien dans la réduction que dans l’augmentation indirecte.

Comment contrôler la cadence de Bingbot

La différence entre les moteurs est nette. Google a supprimé le contrôle manuel, mais Bing l’a conservé. Dans Bing Webmaster Tools, Crawl Control propose, sous Configuration, une grille heure par heure dont les briques représentent la vitesse : plus elles sont nombreuses, plus Bingbot explore rapidement. Vous pouvez choisir un profil adapté aux heures de pointe ou dessiner un rythme personnalisé. Bing respecte également crawl-delay dans robots.txt, précisément la directive ignorée par Google. En pratique, vous communiquez avec Google par les réponses du serveur ; pour Bing, vous disposez d’un véritable réglage.

Qu’est devenu l’outil de cadence de Search Console ?

Voici la chronologie, car de nombreux conseils renvoient encore à un outil disparu :

• Décembre 2008 — Google introduit le réglage de cadence par l’utilisateur dans Webmaster Tools.
• Février 2023 — Google publie une mise en garde contre les codes 403 et 404 pour limiter la cadence.
• 24 novembre 2023 — Google annonce la suppression prochaine de l’outil Crawl Rate Limiter. Gary Illyes justifie la décision ainsi : “with the improvements we’ve made to our crawling logic and other tools available to publishers, its usefulness has dissipated.” (traduction) « Avec les améliorations apportées à notre logique d’exploration et aux autres outils proposés aux éditeurs, son utilité s’est dissipée. » L’ancien outil était lent et très peu utilisé : il produisait “a much slower effect” (traduction) « un effet beaucoup plus lent », “would have taken over a day for the new limits to be applied on crawling,” (traduction) « aurait nécessité plus d’une journée pour appliquer les nouvelles limites à l’exploration », et servait “rarely,” (traduction) « rarement » ; ceux qui l’utilisaient réglaient “in many cases set the crawling speed to the bare minimum.” (traduction) « dans de nombreux cas la vitesse d’exploration au strict minimum ».
• 8 janvier 2024 — l’outil est supprimé. Evidence for this claim Google deprecated the Search Console crawl-rate limiter and removed it on January 8, 2024. Scope: Google Search Console's legacy crawl-rate limiter. Confidence: high · Verified: 2026-07-14 Google: Crawl rate limiter deprecation Google abaisse également le plancher : “With the deprecation of the crawl limiter tool, we’re also setting the minimum crawling speed to a lower rate, comparable to the old crawl rate limits.” (traduction) « Avec l’abandon de l’outil de limitation, nous fixons aussi la vitesse minimale d’exploration à un niveau inférieur, comparable aux anciennes limites. »

En pratique, l’ancien curseur manuel accusait déjà plus de 24 heures de retard. Les signaux serveur actuels (5xx et 429) ralentissent Googlebot presque immédiatement, ce qui convient bien mieux à une urgence réelle.

Comment surveiller la cadence d’exploration

Le rapport Statistiques sur l’exploration de GSC montre l’activité réelle de Google : nombre total de requêtes dans le temps, volume total téléchargé, temps de réponse moyen et état de l’hôte sur environ 90 jours, avec des ventilations par code de réponse, type de fichier, objectif d’exploration et type de Googlebot. Surveillez le temps de réponse et l’état de l’hôte : leur dégradation ou une série de 5xx conduit précisément Googlebot à ralentir. Ce rapport révèle donc une limitation provoquée par votre infrastructure avant que vous n’en cherchiez une autre cause. Pour Bing, Crawl Control et les informations d’exploration de Bing Webmaster Tools remplissent un rôle équivalent.

Cadence, budget et fréquence d’exploration

Ne confondez pas ces notions :

• Cadence d’exploration : la vitesse — offre et capacité.
• Demande d’exploration : la quantité que le moteur souhaite explorer, selon la popularité et l’ancienneté du contenu.
• Budget d’exploration : l’interaction entre les deux, soit “the amount of time and resources a search engine allows for crawling a website.” (traduction) « le temps et les ressources qu’un moteur de recherche accorde à l’exploration d’un site ».
• Fréquence d’exploration : la régularité avec laquelle une page donnée est réexplorée, principalement liée à la demande — popularité et fraîcheur du contenu.

Bonne nouvelle : selon mon avis constant, la plupart des sites n’ont pas à s’en préoccuper. “Most sites don’t need to worry about crawl budget, but there are few cases where you may want to take a look” (traduction) « La plupart des sites n’ont pas à se soucier du budget d’exploration, mais quelques cas méritent un examen » : les sites récents comportant beaucoup de pages, les sites très vastes ou évoluant rapidement, et ceux dont GSC signale de nombreuses URL « Détectée, actuellement non indexée ». Si vous n’entrez pas dans ces catégories, laissez l’automatisation de Google gérer la cadence.

Résumé par l’IA

Version condensée de l’onglet Advanced :

• Cadence d’exploration = vitesse de récupération des pages par un robot : la « limite de capacité d’exploration », composée des connexions parallèles et du délai entre les requêtes. C’est l’offre dans le budget ; la demande d’exploration en est la demande.
• Elle est automatique et réagit à la santé du serveur : serveur rapide et sain, limite plus élevée ; lenteurs ou erreurs 5xx et 429, Google explore moins. Les ressources propres de Google forment un second plafond. Tous les Googlebots partagent un même quota.
• Le curseur manuel de GSC a disparu le 8 janvier 2024. Tout conseil invitant à le régler est obsolète.
• Pour ralentir Googlebot aujourd’hui : corrigez d’abord le serveur ou renvoyez 500, 503 ou 429 pendant un à deux jours au maximum. Au-delà, l’indexation et les annonces risquent d’être suspendues. Préférez 429, qui peut inclure Retry-After. N’utilisez jamais 401, 403 ou 404 ; Google ignore crawl-delay.
• Vous ne pouvez pas demander d’augmentation. Agissez indirectement : serveur rapide, sitemaps propres, moins d’URL dupliquées ou inutiles, davantage de liens et API d’indexation lorsque le contenu y est admissible.
• Bing conserve un contrôle manuel : grille horaire Crawl Control et prise en charge de crawl-delay.
• La cadence n’est pas un facteur de classement. “improving your crawl rate won’t necessarily lead to better positions.” (traduction) « Améliorer votre cadence d’exploration n’entraîne pas nécessairement de meilleures positions. » La plupart des sites n’ont pas besoin de la gérer.

Documentation officielle

Documentation de première main publiée par les moteurs de recherche.

Google

• Réduire la cadence d’exploration de Googlebot — procédure essentielle : 500, 503 ou 429, limite d’un à deux jours et formulaire permettant de réduire, mais pas d’augmenter, la cadence.
• Gestion du budget d’exploration — définition de la limite de capacité et de sa réaction à la santé du serveur.
• Effet des codes d’état HTTP sur les robots de Google — codes qui ralentissent l’exploration (5xx, 429) et ceux qui ne le font pas (4xx, sauf 429).
• Idées reçues et faits sur l’exploration — crawl-delay ignoré, absence d’effet sur le classement et influence de la santé du serveur.
• Suppression prochaine de l’outil Crawl Rate Limiter (novembre 2023) — annonce de la suppression.
• N’utilisez pas les codes d’accès interdit ou 404 pour limiter la cadence (février 2023) — pourquoi les 4xx constituent un mauvais levier.
• Nouvelles statistiques d’exploration améliorées (novembre 2020) — lecture du rapport Statistiques sur l’exploration.
• Optimiser le budget d’exploration — capacité, demande et sites réellement concernés.

Bing / Microsoft

• Bing Webmaster Tools — Crawl Control — grille horaire manuelle abandonnée par Google.
• Conseils relatifs à Bingbot — documentation actuelle de Bing sur les valeurs de crawl-delay comprises entre 1 et 20 secondes.
• Série Bingbot : optimiser la fréquence d’exploration (octobre 2018) — position de Bing sur le moment opportun pour récupérer à nouveau une page.

Citations des sources

Déclarations publiques de Google. Chaque lien profond mène directement au passage cité sur la page source.

Google — définition et déterminants de la cadence

• “If the site responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traduction) « Si le site répond rapidement pendant un certain temps, la limite augmente et davantage de connexions peuvent servir à l’exploration. Si le site ralentit ou renvoie des erreurs serveur, la limite baisse et Google explore moins. » — Gestion du budget d’exploration. Accéder à la citation
• “Google has a lot of machines, but not infinite machines. We still need to make choices with the resources that we have.” (traduction) « Google possède beaucoup de machines, mais pas une infinité. Nous devons malgré tout faire des choix avec les ressources dont nous disposons. » Accéder à la citation

Google — comment réduire la cadence

• “return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (traduction) « renvoyer aux requêtes d’exploration un code d’état HTTP 500, 503 ou 429 à la place de 200 ». — Réduire la cadence d’exploration de Googlebot. Accéder à la citation
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days).” (traduction) « Nous déconseillons de le faire pendant une longue période, c’est-à-dire plus d’un à deux jours. » Accéder à la citation
• “You cannot request an increase in crawl rate, and it may take several days for the request to be evaluated and fulfilled.” (traduction) « Vous ne pouvez pas demander une augmentation de la cadence d’exploration, et l’évaluation puis l’exécution de la demande peuvent prendre plusieurs jours. » Accéder à la citation

Google — codes d’état qui ralentissent l’exploration

• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (traduction) « Les robots de Google interprètent le code d’état 429 comme un signal de surcharge du serveur et le considèrent comme une erreur serveur. » — Effet des codes d’état HTTP sur les robots de Google. Accéder à la citation
• “The 4xx status codes, except 429, have no effect on crawl rate.” (traduction) « Les codes d’état 4xx, à l’exception de 429, n’ont aucun effet sur la cadence d’exploration. » / “Don’t use 401 and 403 status codes for limiting the crawl rate.” (traduction) « N’utilisez pas les codes 401 et 403 pour limiter la cadence d’exploration. » Accéder à la citation

Google — délai d’exploration et classement

• “The non-standard ‘crawl-delay’ robots.txt rule is not processed by Google’s crawlers.” (traduction) « La règle non standard crawl-delay de robots.txt n’est pas traitée par les robots de Google. » — Idées reçues et faits sur l’exploration. Accéder à la citation
• “Improving your crawl rate won’t necessarily lead to better positions in Google Search results.” (traduction) « Améliorer votre cadence d’exploration n’entraîne pas nécessairement de meilleures positions dans les résultats de recherche Google. » Accéder à la citation

Gary Illyes, Google (à propos de la suppression de l’outil)

• “if the server persistently returns HTTP 500 status codes for a range of URLs, Googlebot will automatically, and almost immediately slow down crawling.” (traduction) « Si le serveur renvoie continuellement des codes HTTP 500 pour un ensemble d’URL, Googlebot ralentira automatiquement et presque immédiatement son exploration. » Lire l’article
• “with the improvements we’ve made to our crawling logic and other tools available to publishers, its usefulness has dissipated.” (traduction) « Avec les améliorations apportées à notre logique d’exploration et aux autres outils proposés aux éditeurs, son utilité s’est dissipée. » Lire l’article

Listes de contrôle de la cadence d’exploration

Réduire en toute sécurité la cadence de Googlebot, dans l’ordre

• Confirmez d’abord que le robot est bien la cause : consultez les statistiques d’exploration de GSC — temps de réponse moyen et état de l’hôte — ainsi que les journaux du serveur.
• Corrigez la cause : accélérez le serveur ou augmentez ses ressources. C’est la solution durable et la seule qui ne menace pas l’indexation.
• En cas d’urgence réelle, renvoyez 500, 503 ou 429 aux requêtes d’exploration, de préférence 429 avec Retry-After. Googlebot ralentit presque immédiatement.
• Maintenez cette réponse d’urgence pendant un à deux jours au maximum. Au-delà, des pages risquent de quitter l’index et des annonces peuvent être suspendues.
• Pour un problème durable mais non critique, utilisez la demande spéciale de Google en indiquant la cadence optimale pour votre site.
• Pour Bing, réglez la vitesse dans Crawl Control et, si nécessaire, ajoutez crawl-delay à robots.txt.

À ne PAS faire

• N’utilisez pas 401, 403 ou 404 pour ralentir : ces codes n’agissent pas sur la cadence et peuvent faire disparaître des pages.
• Ne comptez pas sur crawl-delay dans robots.txt pour Google : il l’ignore, contrairement à Bing.
• Ne cherchez pas l’ancien curseur de GSC : il a été supprimé le 8 janvier 2024.

Pour obtenir davantage d’exploration — sans pouvoir la forcer — améliorez-la indirectement

• Accélérez le serveur ou ajoutez des ressources.
• Placez les URL canoniques et indexables dans des sitemaps propres, avec un lastmod exact.
• Supprimez les URL dupliquées ou de faible valeur qui gaspillent l’exploration.
• Renforcez les liens internes et obtenez davantage de liens externes.
• Préférez GET à POST lorsque c’est possible et utilisez l’API d’indexation si votre contenu y est admissible.

Cadence d’exploration — aide-mémoire

Codes d’état et effet sur la cadence de Google

À retenir

• Cadence = vitesse et offre ; demande = quantité souhaitée ; budget = interaction des deux.
• Terme de Google : limite de capacité d’exploration, soit connexions parallèles et délai entre les requêtes. Elle est automatique et suit la santé du serveur.
• Fenêtre d’urgence pour 5xx et 429 : un à deux jours au maximum, au risque de désindexer des pages et de suspendre des annonces.
• Aucune augmentation manuelle : vous pouvez demander à Google de réduire la cadence, jamais de l’accroître.
• Ancien curseur de GSC : supprimé le 8 janvier 2024, après l’annonce du 24 novembre 2023.
• Tous les Googlebots partagent un même quota d’exploration.
• La cadence n’est pas un facteur de classement.
• Équivalent chez Bing : grille Crawl Control et prise en charge de crawl-delay.

Demander temporairement à Googlebot de ralentir

Il s’agit uniquement d’un levier d’urgence : renvoyez au robot une réponse 503 ou 429 accompagnée d’un en-tête Retry-After, à la place d’un 200. Ce signal conduit Google à réduire très rapidement ses requêtes. Ne maintenez ce dispositif que pendant un ou deux jours au maximum : sinon, les URL concernées peuvent être retirées de l’index et les annonces Google Ads qui y renvoient peuvent être suspendues. La solution durable consiste à rendre le serveur plus rapide et plus sain, pas à maintenir une erreur.

Apache (.htaccess) — renvoyer 503 avec Retry-After

# Emergency only — remove within 1–2 days.
# Sends Googlebot a "slow down / try later" signal.
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Googlebot|bingbot) [NC]
RewriteRule ^ - [R=503,L]
Header always set Retry-After "3600"
ErrorDocument 503 "Server temporarily overloaded — please retry later."

Nginx — renvoyer 503 avec Retry-After aux robots

# Emergency only — remove within 1–2 days.
if ($http_user_agent ~* (Googlebot|bingbot)) {
    return 503;
}
# Send a Retry-After hint with the 503 response.
add_header Retry-After 3600 always;

Express / Node.js — 429 Trop de requêtes avec Retry-After

// Emergency only — remove within 1–2 days.
// 429 explicitly means "too many requests" and carries a Retry-After.
app.use((req, res, next) => {
  const ua = req.get("user-agent") || "";
  if (/Googlebot|bingbot/i.test(ua)) {
    res.set("Retry-After", "3600"); // seconds
    return res.status(429).send("Too many requests — please retry later.");
  }
  next();
});

Rappel : cette mesure ne fait que ralentir temporairement l’exploration. Elle ne permet ni de suspendre ni de bloquer l’indexation, et ne remplace pas la correction de la capacité du serveur.

Outils pour observer et contrôler la cadence

• Google Search Console — rapport Statistiques sur l’exploration : vision de Google sur le nombre total de requêtes, le volume téléchargé, le temps de réponse moyen, l’état de l’hôte sur environ 90 jours et les ventilations par code, type de fichier, objectif et type de Googlebot. C’est ici que vous constaterez un ralentissement.
• Bing Webmaster Tools — Crawl Control : grille manuelle heure par heure, prédéfinie ou personnalisée, qui règle la vitesse de Bingbot selon l’heure. Google a supprimé son propre levier manuel.
• crawl-delay dans robots.txt : respecté par Bing et certains autres moteurs, ignoré par Google. Utile pour Bing, sans effet sur Google.
• Analyse des journaux serveur : source de vérité sur la vitesse réelle des robots et les codes qu’ils reçoivent.
• Audits et robots d’exploration : Ahrefs Site Audit et Screaming Frog SEO Spider aident à repérer les URL dupliquées, paramétrées ou piégées qui gaspillent la capacité.

Que faire face à la cadence d’exploration ?

Procédure d’incident : les robots surchargent le serveur d’origine

1. Vérifier le robot. Confirmez que l’adresse IP source appartient bien au robot déclaré. Sinon, bloquez ou limitez l’usurpateur avec vos contrôles de sécurité habituels.
2. Mesurer l’impact. Corrélez les requêtes du robot avec la latence, la saturation, les délais dépassés et les réponses 5xx. En l’absence de corrélation, cherchez la véritable source de charge.
3. Protéger la disponibilité. Délestez uniquement le trafic nécessaire. Pour une urgence temporaire liée à Googlebot, utilisez 429 ou 503, jamais 403 ou 404.
4. Repérer les motifs les plus coûteux. Regroupez les requêtes par répertoire, paramètres, code de réponse et octets. Si un espace d’URL incontrôlé domine, corrigez les liens ou les règles qui le génèrent.
5. Corriger la cause. Augmentez la capacité, mettez en cache les réponses appropriées, supprimez les pièges ou employez les contrôles officiellement pris en charge par le robot.
6. Rétablir puis vérifier. Retirez la limitation temporaire et confirmez le retour de la latence utilisateur et du taux d’erreurs du robot au niveau de référence du site.

Erreurs liées à la cadence d’exploration

• Utiliser crawl-delay pour Googlebot. Google l’ignore. En cas d’urgence seulement, renvoyez temporairement 429 ou 503 et corrigez la charge sous-jacente.
• Renvoyer 403 ou 404 pour ralentir Googlebot. Ces codes signalent un refus d’accès ou une absence, pas une surcharge temporaire. Employez le bon signal.
• Tenter d’imposer une augmentation permanente. Le curseur de Search Console a disparu et davantage d’exploration n’améliore pas le classement. Renforcez la santé du serveur et les signaux de demande.
• Faire confiance à la chaîne user-agent. Un imposteur peut se déclarer Googlebot. Vérifiez l’adresse IP avant de modifier le comportement du site.
• Maintenir la limitation d’urgence. Des erreurs prolongées nuisent à l’exploration et à l’indexation. Désignez un responsable et une condition de retrait avant le déploiement.

Le cadre vérifier → protéger → corriger

• Vérifier : prouver que le trafic provient d’un vrai robot et qu’il coïncide avec une dégradation du serveur.
• Protéger : appliquer le contrôle temporaire le plus étroit qui préserve la disponibilité pour les utilisateurs et exprime le bon sens HTTP.
• Corriger : supprimer le goulet d’étranglement ou l’espace d’URL incontrôlé, puis retirer le contrôle temporaire.

Séparez la cadence de la demande : un serveur sain peut relever le plafond de capacité, mais ne peut pas obliger un moteur à vouloir explorer davantage d’URL.

Prouver l’efficacité d’une intervention

Réponse de limitation temporaire

Test : interrogez une URL de test limitée avec curl -I. Résultat attendu : le 429 ou 503 prévu apparaît uniquement pendant l’incident, tandis que les URL normales restent disponibles. Interprétation d’un échec : la règle vise un périmètre incorrect ou renvoie le mauvais code. Fenêtre de surveillance : immédiate. Déclencheur de retour arrière : des utilisateurs ou des robots sans rapport reçoivent la limitation.

Rétablissement après le retrait de la limitation

Test : répétez les contrôles d’en-têtes et surveillez les journaux du serveur et d’accès. Résultat attendu : les réponses 200 normales reviennent, les erreurs des robots diminuent et la latence utilisateur reste au niveau de référence. Interprétation d’un échec : la règle temporaire demeure active ou le problème de capacité persiste. Fenêtre de surveillance : immédiate pour HTTP, puis pendant le prochain cycle normal d’exploration. Déclencheur de retour arrière : une nouvelle saturation ou des erreurs 5xx imposent de reprendre la procédure d’incident.

Correction de l’espace d’URL

Test : explorez et contrôlez dans les journaux le motif de paramètres ou de chemins à l’origine des requêtes excessives. Résultat attendu : les nouvelles URL pièges ne sont plus générées ni liées, tandis que les URL utiles restent accessibles. Interprétation d’un échec : une autre voie de découverte expose encore le motif. Fenêtre de surveillance : comparez des périodes de journaux équivalentes. Déclencheur de retour arrière : des pages utiles ou des ressources nécessaires deviennent inaccessibles.

Indicateurs de santé de la cadence

Cadence des requêtes de robots vérifiés

Indicateur : requêtes par unité de temps provenant d’adresses IP de robots vérifiées. Ce qu’il révèle : le rythme réel du robot. Collecte : journaux d’accès après vérification du robot. Repère réaliste : établissez une référence par robot et période de trafic ; aucune cadence universelle n’est sûre. Fréquence : quotidienne pendant un incident, mensuelle sinon.

Taux d’erreurs et latence corrélés aux robots

Indicateur : erreurs 5xx, délais dépassés et latence du serveur d’origine pendant l’activité des robots. Ce qu’il révèle : un éventuel dépassement de capacité. Collecte : alignez la télémétrie serveur sur les horodatages des journaux du robot. Repère réaliste : utilisez le niveau normal hors incident et les objectifs de capacité du site. Fréquence : alertes continues pour les sites critiques.

Part de requêtes utiles

Indicateur : requêtes vérifiées vers des pages utiles en 200, comparées aux redirections, erreurs et URL pièges connues. Ce qu’il révèle : la part de capacité dépensée utilement. Collecte : classez les URL et les codes des journaux. Repère réaliste : suivez la tendance par rapport à l’inventaire du site, sans cible universelle. Fréquence : mensuelle.

Testez vos connaissances : cadence d’exploration

Ressources utiles

Mes articles connexes

• Quand faut-il s’inquiéter du budget d’exploration ? — la cadence comme moitié du budget, et les leviers de réduction ou d’augmentation indirecte.
• Qu’est-ce que Googlebot et comment fonctionne-t-il ? — comment Googlebot détermine sa vitesse et les éléments à explorer, ainsi que l’obsolescence du réglage manuel.
• Guide du débutant sur le SEO technique — place de l’exploration et de sa cadence dans l’ensemble du SEO technique.

Mes conférences

• How Search Works (SlideShare) — j’y présente la limite de cadence comme “what your site can support” (traduction) « ce que votre site peut supporter » et précise que tous les Googlebots partagent un même quota. Réserve permanente : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) « C’est ma compréhension de ces systèmes… elle ne sera pas complète ni exacte à 100 %. »

Autres sources

• Search Engine Land — suppression prochaine de l’outil de cadence de Googlebot et suppression effective — historique et explications de Gary Illyes.
• Série Google Crawling December — ensemble particulièrement dense d’explications officielles sur l’exploration.
• Search Engine Journal — suppression de l’outil Crawl Rate Limiter dans Search Console — reprise par Roger Montti de l’annonce de novembre 2023 et du nouveau plancher automatique.
• Search Engine Journal — ne pas utiliser les erreurs 403 ou 400 pour limiter Googlebot — mise en garde du billet de Google de février 2023 contre les erreurs de la famille 4xx.
• Bing Webmaster Blog — série Bingbot : optimiser la fréquence d’exploration — explication de Bing sur le moment et la manière de récupérer à nouveau une page.
• Bing Webmaster Blog — tirer le meilleur parti de Bingbot avec Bing Webmaster Tools — utilisation de Crawl Control et des autres paramètres BWT pour gérer la cadence de Bingbot.

Journal des modifications