429 Too Many Requests — trop de requêtes

TL;DR — Une 429 Too Many Requests signifie que votre serveur a dit à un visiteur ou à un robot : « vous demandez trop de pages trop vite — ralentissez ». C’est ce qu’on appelle la limitation de débit. Bonne nouvelle pour le SEO : 429 est l’erreur de sa famille que Google traite avec le plus de douceur. Au lieu de supprimer vos pages, Googlebot ralentit simplement l’exploration pendant un moment. Cela ne devient un problème que si votre serveur continue à envoyer des 429 pendant plusieurs jours.

Ce que dit réellement une 429

Chaque fois qu’un navigateur, un script ou un robot d’exploration de moteur de recherche demande une page à votre serveur, celui-ci répond avec un code de statut. 200 signifie « voici la page ». Une 429 signifie : « vous avez envoyé trop de requêtes dans un court intervalle, je ne réponds pas à celle-ci — revenez plus tard ».

Les serveurs utilisent 429 volontairement pour se protéger. Si un visiteur (ou un robot) martèle le site assez vite pour le ralentir pour tout le monde, renvoyer 429 revient à dire arrêtez un moment. Une réponse 429 bien conçue inclut aussi un en-tête Retry-After — une indication qui dit au client combien de secondes attendre avant de réessayer. Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

Pourquoi 429 est l’erreur « sympathique » pour le SEO

Voici le point qui surprend. 429 appartient au groupe des « erreurs client 4xx », à côté de codes comme 403 Forbidden et 404 Not Found. Ces deux codes sont une mauvaise nouvelle si Google continue à les voir : Google finit par retirer ces pages de la recherche.

429 est l’exception. Google lit une 429 comme « le serveur est occupé, ralentissez » — de la même façon qu’il lit une 503 ou une 500, qui sont des erreurs serveur. Au lieu de retirer vos pages, Googlebot explore donc votre site plus lentement pendant un moment. Google recommande effectivement 429 comme la bonne façon de ralentir un robot et déconseille explicitement d’utiliser 403 ou 404 pour cela. Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Quand 429 devient-elle un problème ?

Une 429 de temps à autre est tout à fait normale et se résorbe d’elle-même : dès que votre serveur cesse de les envoyer, Google accélère à nouveau son exploration. Vous n’avez rien à demander.

Le danger apparaît lorsque les 429 persistent. Si Googlebot rencontre une 429 sur les mêmes pages pendant plus d’un jour ou deux, Google peut commencer à retirer ces pages de son index — car, du point de vue de Google, votre site semble être en panne et indisponible depuis plusieurs jours. 429 est donc un outil à court terme, pas un réglage permanent.

Que faire ?

• Si vous ne vouliez pas envoyer de 429 (elles apparaissent par surprise dans Google Search Console ou votre outil d’exploration), quelque chose limite le débit trop agressivement — souvent un plugin de sécurité, un pare-feu (WAF) ou votre hébergement/CDN. Trouvez cette couche et desserrez la limite afin qu’elle cesse de bloquer les vrais moteurs de recherche.
• Si vous vouliez envoyer ces réponses — parce que votre serveur est fortement chargé — ce n’est pas un problème : bornez simplement la durée et ajoutez un en-tête Retry-After. Désactivez la règle dans un délai d’un ou deux jours.

Vous voulez la procédure de configuration serveur, la formulation exacte de Google et les mythes fréquents ? Passez à l’onglet Advanced.

TL;DR — 429 est le seul code 4xx que Google traite comme une erreur 5xx : lorsqu’il rencontre un nombre significatif de réponses 500/503/429, il y voit un signal de surcharge serveur et ralentit l’exploration de Googlebot à l’échelle du hostname, au lieu de supprimer le contenu. C’est le seul code que Google recommande pour ralentir un robot — jamais 403 ou 404. La documentation de Google conseille, pour les urgences, « quelques heures ou 1 à 2 jours » — ce n’est pas une fenêtre de sécurité garantie ; des 429 persistantes sur les mêmes URL risquent de finir par les faire sortir de l’index, et le ralentissement recommence à s’atténuer (pas nécessairement instantanément ni complètement) quand le volume d’erreurs diminue. La RFC 6585 indique qu’une réponse 429 SHOULD expliquer la condition et MAY inclure Retry-After — son envoi est une bonne pratique recommandée, pas une exigence de conformité. Appliquez la limite au bon trafic et vérifiez l’identité des robots avant d’écrire des exceptions.

Ce que signifie 429 au niveau du protocole

Comme le formule le MDN à partir de la spécification : “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting’.” (traduction) : « Le code de statut de réponse HTTP 429 Too Many Requests indique que le client a envoyé trop de requêtes pendant une période donnée. Ce mécanisme qui demande au client de ralentir le rythme des requêtes est généralement appelé limitation de débit. » Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

La section 4 de la RFC 6585 est plus précise que la plupart des résumés. Une représentation 429 SHOULD expliquer la condition et MAY inclure un en-tête Retry-After indiquant au client un nombre concret de secondes (la RFC 9110 autorise aussi une date HTTP) à attendre avant de réessayer — Retry-After est une bonne pratique recommandée, pas une exigence de conformité. La spécification ne définit pas non plus comment identifier un client ni comment compter les requêtes ; cela relève entièrement du système qui émet la réponse (par IP, session, clé d’API, ressource — politique d’implémentation, pas règle du protocole). Autre règle facile à manquer : la RFC 6585 indique qu’une réponse 429 ne doit pas être stockée par un cache. Si vous voyez une 429 qui semble mise en cache ou rejouée alors que l’origine est saine, c’est un intermédiaire (CDN, proxy) qui se comporte mal, et non l’origine qui décide à nouveau de limiter le client.

Je l’ai toujours formulé simplement dans mon guide Codes de statut HTTP et leur impact SEO : 429 est “a form of rate-limiting to protect the server because the client sent too many requests to the server too fast.” (traduction) : « une forme de limitation de débit destinée à protéger le serveur parce que le client lui a envoyé trop de requêtes trop rapidement. » En théorie, c’est une erreur client — le client a mal agi en demandant trop. Mais c’est précisément là que le récit SEO diverge de la spécification.

L’exception parmi les codes 4xx

Le fait le plus important de cette page est le suivant : Google ne traite pas 429 comme le reste de la famille 4xx. Gary Illyes a consacré un article du blog Google Search Central à ce sujet en février 2023, parce que suffisamment de sites et de CDN utilisaient mal les 404 pour ralentir Googlebot et que Google a dû leur dire d’arrêter.

Sa règle : “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (traduction) : « L’exception est 429, qui signifie “trop de requêtes”. Cette erreur indique clairement à tout robot correctement conçu, y compris notre cher Googlebot, qu’il doit ralentir parce qu’il surcharge le serveur. » Et, dans la référence Google des codes de statut : “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (traduction) : « N’utilisez pas les codes 401 et 403 pour limiter le rythme d’exploration. Les codes de statut 4xx, à l’exception de 429, n’ont aucun effet sur ce rythme. »

Ainsi, alors que 403 et 404 feront supprimer votre contenu de Google Search, 429 vous apporte un simple ralentissement temporaire. Google le classe littéralement avec les erreurs serveur : “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 d’exploration de Google traitent le code de statut 429 comme un signal indiquant que le serveur est surchargé, et il est considéré comme une erreur serveur. » Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

C’est ce qui fait de 429 le proche parent utile de 503 Service Unavailable (le signal traditionnel de maintenance ou d’indisponibilité temporaire) — et l’exact opposé de 403 Forbidden, qui est le mauvais outil de limitation malgré le fait que de nombreux pare-feu l’utilisent par défaut.

Effet sur l’exploration à l’échelle du hostname — avec un seuil

Deux portées différentes sont souvent confondues ici ; il faut les séparer. La manière dont vous comptez et indexez une limite de débit — par IP, session, clé d’API, ressource ou serveur — relève de votre politique ; la spécification HTTP ne la définit pas. Ce que Google fait des erreurs qu’il observe est un comportement documenté distinct, conditionné par le volume et non par une seule réponse : “Google’s crawling infrastructure reduces your site’s crawling rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.” (traduction) : « L’infrastructure d’exploration de Google réduit le rythme d’exploration de votre site lorsqu’elle rencontre un nombre significatif d’URL dont la réponse HTTP a le statut 500, 503 ou 429. » Une fois ce seuil atteint, “the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.” (traduction) : « le rythme d’exploration réduit affecte l’ensemble du hostname de votre site (par exemple, subdomain.example.com), aussi bien l’exploration des URL qui renvoient des erreurs que celle des URL qui renvoient du contenu. »

Autrement dit, si vous renvoyez des 429 pour un sous-ensemble de pages (par exemple, une route d’API lourde) avec un volume réel, Googlebot ralentit l’exploration de l’ensemble du hostname, y compris des pages qui continuent à renvoyer 200. C’est généralement l’effet recherché quand le but est de réduire la charge totale. Mais une 429 isolée sur une seule route ne suffit pas à établir cet effet à l’échelle du hostname : la formulation de Google vise un « nombre significatif » de réponses d’erreur, et non une seule réponse.

La recommandation de 1 à 2 jours — quand 429 devient risquée

429 est un signal à court terme, et Google donne pour les urgences une recommandation concrète — pas une fenêtre de sécurité garantie ni une limite brutale. Dans la documentation « réduire le rythme d’exploration » : “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (traduction) : « Si vous devez réduire d’urgence le rythme d’exploration pendant une courte période (par exemple quelques heures ou 1 à 2 jours), renvoyez alors aux requêtes d’exploration une réponse HTTP de statut 500, 503 ou 429 au lieu de 200. »

Au-delà, le risque augmente, même si Google le présente comme une possibilité et non comme une promesse : “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” (traduction) : « Nous vous déconseillons de faire cela pendant une longue période (c’est-à-dire plus de 1 à 2 jours), car cela peut nuire à l’apparence de votre site dans les produits Google… si Googlebot observe ces codes de statut sur la même URL pendant plusieurs jours, l’URL peut être retirée de l’index Google. » La référence des codes de statut dit la même chose pour les 5xx et 429 : “already indexed URLs are preserved in the index, but eventually dropped.” (traduction) : « les URL déjà indexées sont conservées dans l’index, mais finissent par en être retirées. »

Le modèle de risque, formulé honnêtement : une 429 courte reste dans la fenêtre recommandée par Google pour une urgence ; une 429 persistante sur les mêmes URL pendant plusieurs jours est le cas où le langage de Google devient « peut » et « finit par être retirée » — un risque documenté, pas un résultat garanti dans un sens ou dans l’autre. La dynamique est la même qu’avec une 503 prolongée.

Le rythme d’exploration revient automatiquement

Le revers rassurant : aucun indicateur de pénalité ne suit votre site. Une fois les erreurs résorbées, Google indique que “the crawl rate will automatically start increasing again.” (traduction) : « le rythme d’exploration recommencera automatiquement à augmenter. » Vous n’avez aucun formulaire à envoyer et aucune nouvelle demande à effectuer. Notez toutefois la formulation exacte : Google dit “starts increasing” (traduction) : « commence à augmenter », et non “instantly returns to your prior rate.” (traduction) : « revient instantanément à votre rythme précédent ». Considérez le rétablissement comme une direction documentée, sans calendrier fixe ni point d’arrivée garanti, et non comme un SLA.

(À l’inverse, si vous voulez que Google explore durablement moins votre site, Google indique de “file a special request to report a problem with unusually high crawl rate” (traduction) : « déposer une demande spéciale pour signaler un problème de rythme d’exploration inhabituellement élevé ». C’est une procédure manuelle qui peut prendre plusieurs jours et n’est pas garantie. Le rétablissement ne présente pas cette friction.)

Comment Bing traite 429

Il est largement rapporté que Bingbot se comporte de façon similaire — les 429/500/503 signalent une surcharge et Bingbot ralentit — mais je n’ai pas pu confirmer indépendamment une formulation actuelle en ce sens dans les pages d’aide de Bing lors de cette recherche (ce sont des SPA rendues en JavaScript qui n’ont pas fourni de texte statique récupérable). Considérez donc la parité comme un constat rapporté par le secteur, et non comme un fait vérifié dans la documentation actuelle de Bing. Ce que Bing confirme, dans ses anciennes recommandations, ce sont deux contrôles proactifs que Google ne propose pas sous la même forme :

• Crawl Control dans Bing Webmaster Tools, une grille de requêtes par seconde qui permet de régler la vitesse de Bingbot selon l’heure de la journée.
• La directive crawl-delay de robots.txt. La recommandation actuelle de Bing Webmaster documente des valeurs de 1 à 20 secondes. Elle est propre à Bing et ne ralentit pas Googlebot.

Sur Bing, vous pouvez donc limiter préventivement avec crawl-delay ou Crawl Control plutôt que réagir avec des codes de statut. (Google a retiré son propre curseur manuel de rythme d’exploration en 2024 et s’appuie désormais entièrement sur les réponses de votre serveur.)

Quand envoyer volontairement une 429

Voici des raisons légitimes de renvoyer délibérément une 429 :

• Surcharge serveur urgente — pic de trafic, migration mal préparée ou panne nécessitant de ralentir Googlebot immédiatement pendant quelques heures.
• Protection des API et des points de terminaison non HTML contre l’abus de robots — les robots des moteurs, les robots SEO tiers (Ahrefs, Screaming Frog) et les scrapers atteignent tous des limites destinées à empêcher l’abus.

Ce que 429 ne doit pas faire : bloquer définitivement les robots dont vous ne voulez pas. Si vous ne voulez jamais qu’un élément soit exploré, utilisez une interdiction dans robots.txt, pas une 429. Si vous voulez conserver une page tout en la retirant de l’index, utilisez noindex. 429 signifie seulement « plus tard », pas « jamais ».

429 involontaires — les coupables habituels

Lorsque des 429 apparaissent dans le rapport d’indexation des pages ou de statistiques d’exploration de GSC alors que vous ne les avez pas configurées, la source est généralement l’une des suivantes — je ne connais pas de preuve solide permettant de classer universellement la plus fréquente ; voyez donc cette liste comme des hypothèses à confirmer ou écarter, pas comme un diagnostic :

• Règles de WAF ou de pare-feu qui se déclenchent à tort sur des plages IP de robots légitimes.
• Limites par défaut de l’hébergement mutualisé ou du CDN trop strictes pour une exploration réelle.
• Outils de gestion des robots qui classent Googlebot ou Bingbot comme trafic abusif.
• Middleware de limitation agressive prévu pour l’abus d’API mais qui intercepte vos propres robots.

Avant de modifier un seuil ou d’écrire une règle qui exempte de vrais robots de recherche, établissez d’abord la provenance — ne devinez pas quelle couche possède la réponse. Récupérez les en-têtes bruts de la réponse, les lignes exactes du journal de requêtes (pas un résumé de tableau de bord), l’identifiant de la règle ou de la zone de limitation qui s’est déclenchée, la clé client comptée (IP, session, clé d’API), la route, le point de présence CDN ou l’emplacement edge, ainsi que la fenêtre temporelle. Cette combinaison indique quelle couche a réellement émis la 429 et ce qu’elle comptait ; ce n’est qu’alors qu’il est logique d’assouplir une limite ou d’ajouter une exception. Vérifiez l’identité du robot par DNS inverse puis direct (méthode officielle de Google), et non avec le seul user-agent — les user-agents « Googlebot » usurpés sont fréquents. L’onglet Scripts contient les commandes exactes.

La version courte du mode opératoire

1. Utilisez 429 ou 503 avec Retry-After pour ralentir un robot — jamais 403 ou 404.
2. Limitez la durée à quelques heures ou 1 à 2 jours — au-delà, des URL peuvent être retirées.
3. Souvenez-vous que le ralentissement est à l’échelle du hostname et qu’il se rétablit automatiquement lorsque les erreurs cessent.
4. Appliquez la limite au bon trafic et vérifiez l’identité du robot avant d’exempter des robots.

Résumé par IA

Une synthèse de la version Advanced :

• 429 Too Many Requests = le serveur indique à un client (navigateur, script ou robot) qu’il a envoyé trop de requêtes trop rapidement — c’est la « limitation de débit ». En théorie, il s’agit d’une erreur 4xx côté client.
• Au niveau du protocole : la RFC 6585 indique qu’une réponse 429 SHOULD expliquer la condition et MAY inclure Retry-After — c’est recommandé, pas obligatoire. Elle NE DOIT PAS non plus être stockée par un cache ; une 429 mise en cache ou rejouée signale un problème d’intermédiaire, pas de l’origine. La manière de compter ou d’indexer la limite (IP, session, clé d’API, ressource) relève de votre politique ; la spécification ne la définit pas.
• L’unique exception 4xx : Google traite 429 comme une erreur serveur 5xx, et non comme 403/404. Il y voit “server overloaded, slow down” (traduction) : « serveur surchargé, ralentissez » et réduit le rythme d’exploration au lieu de supprimer le contenu.
• Google recommande 429 (ainsi que 500/503) pour ralentir les robots — jamais 403 ou 404. Gary Illyes a publié un article en 2023 pour demander explicitement aux sites et aux CDN de cesser d’utiliser les 404 pour ralentir Googlebot.
• Le ralentissement est à l’échelle du hostname, au-delà d’un seuil — la formulation de Google le conditionne à la rencontre d’un « nombre significatif » de réponses 500/503/429, et non à une seule 429. Au-delà du seuil, les pages qui continuent à servir 200 sont elles aussi moins explorées.
• La recommandation de 1 à 2 jours n’est pas une limite brutale : la documentation Google conseille, pour une urgence, « quelques heures ou 1 à 2 jours ». Des 429 persistantes sur les mêmes URL pendant plusieurs jours peuvent finir par faire sortir ces URL de l’index — « peut » et « finit par », pas une garantie — comme avec une 503 prolongée.
• Le rétablissement est progressif, pas instantané : cessez d’envoyer des 429 et Google dit que le rythme d’exploration « recommence à augmenter » — aucune nouvelle demande ni pénalité persistante, mais aucune promesse non plus d’un rétablissement immédiat ou complet selon un calendrier fixe.
• Nouvelles tentatives côté client : respectez un Retry-After valide lorsqu’il est présent ; en son absence, la RFC ne prescrit aucune formule — utilisez un backoff borné avec jitter, plafonnez les tentatives et vérifiez l’idempotence avant de répéter une requête non idempotente.
• Appliquez la limite au bon trafic et vérifiez l’identité des robots (DNS inverse puis direct) avant de les exempter.
• Bing est réputé ralentir de façon similaire face aux 429, même si cette parité n’a pas été confirmée indépendamment dans la documentation actuelle de Bing lors de cette passe ; ses recommandations historiques confirment crawl-delay et la grille Crawl Control comme solutions préventives.
• 429 ≠ blocage : cela signifie « plus tard », pas « jamais ». Utilisez robots.txt pour empêcher l’exploration et noindex pour retirer une page de l’index.

Documentation officielle

Documentation issue des sources primaires des moteurs de recherche et de la spécification HTTP.

Google

• N’utilisez pas les 403 ou 404 pour limiter le débit — article de Gary Illyes de février 2023 ; formulation de référence qui établit que 429 est l’exception et que 403/404 sont les mauvais outils.
• Réduire le rythme d’exploration de Google — recommandations « renvoyer 500, 503 ou 429 », fenêtre de 1 à 2 jours, ralentissement à l’échelle du hostname et rétablissement automatique.
• Codes de statut HTTP, erreurs réseau et erreurs DNS — traitement de chaque code par Google ; 429 est regroupé avec les erreurs serveur (également disponible à l’ancien chemin search/docs/crawling-indexing/http-network-errors).
• Réduire le rythme d’exploration de Google — demande spéciale — procédure manuelle pour « signaler un problème de rythme d’exploration inhabituellement élevé » lorsque renvoyer des erreurs n’est pas possible.

Bing / Microsoft

• Crawl Control — planificateur de requêtes par seconde de Bingbot dans Bing Webmaster Tools.
• Recommandations pour Bingbot — recommandations actuelles de Bing Webmaster pour crawl-delay (1 à 20 secondes).

Spécification HTTP

• MDN — 429 Too Many Requests — définition du protocole, Retry-After et principes de limitation de débit.

Citations de la source

Déclarations attribuées de Google, de Bing et de la spécification HTTP. Chaque lien est un lien profond qui mène directement au passage cité sur la page source.

Google — Gary Illyes, « N’utilisez pas les 403 ou 404 pour limiter le débit » (février 2023)

• “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.” (traduction) : « Au cours des derniers mois, nous avons constaté une hausse du nombre de propriétaires de sites et de certains réseaux de diffusion de contenu (CDN) qui tentent d’utiliser 404 et d’autres erreurs client 4xx (mais pas 429) pour réduire le rythme d’exploration de Googlebot. » Aller à la citation
• “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (traduction) : « Pour un robot qui se comporte correctement, ce code est un signal clair — y compris pour notre cher Googlebot — qu’il doit ralentir parce qu’il surcharge le serveur. » Aller à la citation
• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (traduction) : « Les statuts HTTP 4xx, sauf 429, provoquent tous le retrait du contenu de Google Search. » Aller à la citation
• “Use Search Console to temporarily reduce crawl rate. Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (traduction) : « Utilisez Search Console pour réduire temporairement le rythme d’exploration. Renvoyez un code de statut HTTP 500, 503 ou 429 à Googlebot lorsqu’il explore trop rapidement. » Aller à la citation

Google — Réduire le rythme d’exploration / référence des codes de statut

• “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (traduction) : « Si vous devez réduire d’urgence le rythme d’exploration pendant une courte période (par exemple quelques heures ou 1 à 2 jours), renvoyez aux requêtes d’exploration une réponse HTTP de statut 500, 503 ou 429 au lieu de 200. » Aller à la citation
• “The reduced crawl rate affects the whole hostname of your site… Once the number of these errors is reduced, the crawl rate will automatically start increasing again.” (traduction) : « Le rythme d’exploration réduit affecte l’ensemble du hostname de votre site… Une fois le nombre de ces erreurs réduit, le rythme d’exploration recommencera automatiquement à augmenter. » Aller à la citation
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days)… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” (traduction) : « Nous vous déconseillons de faire cela pendant une longue période (c’est-à-dire plus de 1 à 2 jours)… si Googlebot observe ces codes de statut sur la même URL pendant plusieurs jours, l’URL peut être retirée de l’index Google. » Aller à la citation
• “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 d’exploration de Google traitent le code de statut 429 comme un signal indiquant que le serveur est surchargé, et il est considéré comme une erreur serveur. » Aller à la citation
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (traduction) : « Ne servez pas des statuts 401 ou 403 pour limiter l’exploration : les autres codes 4xx, sauf 429, ne changent pas son rythme. » Aller à la citation

MDN — la définition du protocole

• “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting’.” (traduction) : « En clair, le client a envoyé trop de requêtes pendant une période donnée ; cette invitation à ralentir est couramment appelée limitation de débit. » Aller à la citation

Bing — recommandations actuelles de Webmaster

• Recommandations pour Bingbot documente des valeurs de crawl-delay comprises entre 1 et 20 secondes. Considérez cette indication comme propre à Bing et non comme une méthode générique de limitation des robots.

Confirmation sectorielle de la déclaration de Google

• L’article d’Illyes de février 2023 a été repris presque mot pour mot par Search Engine Land, Search Engine Roundtable et Search Engine Journal — les trois présentent 429 comme « l’unique exception ». (traduction de la formulation citée) Il s’agit de comptes rendus de presse spécialisée du même article Google ; la source primaire est l’article de blog d’Illyes cité plus haut.

Envoyer une 429 correcte — avec Retry-After

L’élément le plus important d’une 429 bien conçue est l’en-tête Retry-After. Il indique à tout client conforme — y compris Googlebot — combien de temps attendre. Il accepte soit un nombre de secondes, soit une date HTTP :

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: text/html

<html><body>Too many requests. Please retry later.</body></html>

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 01 Jul 2026 12:00:00 GMT

Omettre Retry-After ne rend pas la réponse non conforme, mais l’inclure est une bonne pratique et fournit aux robots un signal concret de ralentissement.

nginx — limiter le débit en renvoyant 429

Par défaut, limit_req de nginx renvoie 503. Pour obtenir une sémantique adaptée aux robots, remplacez-la par 429 et ajoutez un en-tête Retry-After. Cet exemple autorise 10 requêtes par seconde et par IP, avec un petit burst :

# In the http {} block: define a shared memory zone keyed by client IP
limit_req_zone $binary_remote_addr zone=crawl_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=crawl_limit burst=20 nodelay;

        # Return 429 (not the default 503) when the limit is exceeded
        limit_req_status 429;
    }

    # Attach a Retry-After header to 429 responses
    error_page 429 = @too_many;
    location @too_many {
        add_header Retry-After 3600 always;
        return 429;
    }
}

Apache — limiter avec mod_ratelimit / mod_evasive

Le module Apache mod_ratelimit du cœur limite la bande passante, et non le nombre de requêtes ; pour limiter le rythme des requêtes, on utilise généralement mod_evasive (ou un WAF). Pour obtenir une réponse 429 avec Retry-After, définissez-la explicitement :

# Send a 429 with Retry-After for a chosen condition (e.g. a rate-limit env var)
<If "%{ENV:RATE_LIMITED} == '1'">
    Header always set Retry-After "3600"
    Redirect 429 /
</If>

# mod_evasive: throttle abusive request bursts (returns 429 in recent versions;
# older builds default to 403 — override where possible)
<IfModule mod_evasive20.c>
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSBlockingPeriod   60
</IfModule>

Notez la réserve : les anciennes versions de mod_evasive utilisent par défaut 403 pour le blocage — exactement le code que Google déconseille pour limiter le débit. Confirmez que votre version renvoie 429 (ou placez devant elle un CDN/WAF qui le fait).

Cloudflare / CDN — limiter le débit à 429

À la couche CDN, configurez l’action de la règle de limitation pour qu’elle renvoie 429 (de nombreuses configurations utilisent par défaut 403 ou un challenge). Dans les règles Rate Limiting de Cloudflare, le statut de réponse lorsque la limite est dépassée est configurable — choisissez 429 et, lorsque c’est pris en charge, ajoutez Retry-After. Même principe avec Fastly, Akamai ou une passerelle d’API : l’action déclenchée au dépassement doit être 429 Too Many Requests, et non 403 Forbidden.

Côté client : réessayer après une 429 sans formule imposée

Si vous écrivez le client, la RFC donne une seule règle ferme et aucune formule de repli : respectez un Retry-After valide lorsqu’il est présent. Lorsqu’il est absent, la RFC 6585 ne prescrit ni intervalle de nouvelle tentative, ni formule de backoff, ni distribution de jitter, ni nombre de tentatives, ni condition de « réussite » — ce sont vos choix de politique, pas une exigence de la spécification. Ne présentez pas une formule particulière (y compris celle qui suit) comme une loi HTTP ; c’est une valeur par défaut raisonnable et bornée, pas l’unique solution correcte.

on 429 response:
    if Retry-After header present and valid:
        wait = parse(Retry-After)          # seconds or HTTP-date
    else:
        wait = min(cap, base * 2^attempt) + random_jitter(0, jitter_window)

    if attempt >= max_attempts or wait > cap:
        stop and surface the failure        # don't retry forever
    if request is not idempotent (e.g. a POST that isn't safe to repeat):
        confirm idempotency (idempotency key, or a safe no-op check) before retrying
    sleep(wait)
    attempt += 1
    retry request

Quels que soient les nombres choisis, trois éléments comptent : plafonner le délai total et le nombre de tentatives (ne pas réessayer indéfiniment), ajouter du jitter (pour éviter qu’une flotte de clients ne réessaie en même temps et ne déclenche à nouveau la limite) et vérifier l’idempotence avant de répéter une opération qui n’est pas sûre (un POST non idempotent a besoin d’une clé de dédoublonnage, pas d’une nouvelle tentative aveugle).

Vérifier qu’un robot est bien Googlebot avant de l’exempter

Si vous écrivez des exceptions de limitation pour les moteurs de recherche, confirmez l’identité avec une vérification DNS inverse puis directe — les user-agents « Googlebot » usurpés sont fréquents et la chaîne UA seule ne prouve rien.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Si la recherche inverse ne se termine pas par un domaine Google, ou si la recherche directe ne correspond pas à l’IP d’origine, ce n’est pas Googlebot. Vous pouvez aussi comparer avec les plages IP publiées par Google (googlebot.json).

Mythes courants sur 429 et le SEO

Mythe : « Toute 429 nuira à mon SEO ou entraînera une désindexation. » Non. Google a conçu 429 comme un signal de limitation attendu et sans danger en soi. Les 429 courtes ou intermittentes sont normales et se corrigent d’elles-mêmes. Le risque de désindexation n’apparaît que lorsque des 429 persistent sur les mêmes URL pendant plusieurs jours — la recommandation de Google de 1 à 2 jours marque la limite.

Mythe : « 429 et 503 sont pratiquement interchangeables pour le SEO. » Pour ralentir l’exploration, Google les traite de façon comparable. Mais leur sens diffère : 503 Service Unavailable est le signal traditionnel « indisponible temporairement / maintenance », tandis que 429 indique spécifiquement une surcharge de rythme ou de volume. Utiliser le code qui correspond à la réalité est important pour vos propres outils de supervision et pour tout service en aval qui lit les codes de statut — même si Googlebot ralentit dans les deux cas.

Mythe : « On peut utiliser 403 ou 404 pour ralentir Googlebot comme 429. » L’article d’Illyes de février 2023 réfute directement cette idée — le phénomène était assez courant pour que Google publie un article dédié demandant d’arrêter. 403/404 n’ont aucun effet sur le rythme d’exploration et retirent activement le contenu de l’index. 429 est le seul code 4xx qui provoque ce ralentissement.

Mythe : « Limiter les robots de recherche entraîne une réduction permanente du budget d’exploration. » La réduction est temporaire et se résorbe automatiquement lorsque le volume d’erreurs diminue. Il n’y a pas de marque persistante sur votre site après l’arrêt des erreurs — la documentation Google dit que le rythme d’exploration “will automatically start increasing again.” (traduction) : « recommencera automatiquement à augmenter ».

Mythe : « Si Googlebot reçoit une 429, il abandonne définitivement cette URL. » Google réessaie plus tard. Le problème concerne les 429 persistantes pendant plusieurs jours pour chaque URL — pas une limitation ponctuelle ou occasionnelle, que Googlebot respecte simplement avant de revenir.

Questions fréquentes

Une erreur 429 nuit-elle à mon SEO ? Pas en elle-même. Les 429 courtes ou intermittentes ralentissent temporairement Googlebot et se résorbent d’elles-mêmes. Le risque apparaît seulement lorsque les mêmes URL renvoient 429 pendant plusieurs jours.

Combien de temps puis-je renvoyer 429 avant que Google ne désindexe mes pages ? La documentation Google conseille « quelques heures ou 1 à 2 jours » — “a couple of hours, or 1–2 days.” (traduction) : « quelques heures ou 1 à 2 jours ». Au-delà, “the URL may be dropped from Google’s index.” (traduction) : « l’URL peut être retirée de l’index Google ». Considérez 1 à 2 jours comme une limite supérieure, pas comme une durée cible.

Quelle est la différence entre 429 et 503 pour le SEO ? Google ralentit l’exploration de façon similaire dans les deux cas. Mais 503 signifie « indisponible temporairement / maintenance », tandis que 429 signifie spécifiquement « vous envoyez trop de requêtes ». Utilisez le code qui correspond au sens réel afin que vos outils de supervision le lisent correctement.

Dois-je bloquer Googlebot avec une 429 si je veux qu’il explore durablement moins ? Non — 429 est un signal à court terme, pas un réglage permanent. Pour une réduction durable, Google indique de déposer une demande spéciale concernant un rythme d’exploration élevé. Pour empêcher complètement les robots d’explorer une zone, utilisez robots.txt ; pour retirer une page de l’index, utilisez noindex.

Bingbot respecte-t-il 429 comme Googlebot ? Bingbot ralentit également face aux signaux de surcharge comme 429/500/503. Bing propose en outre des contrôles préventifs que Google n’offre pas : la directive crawl-delay dans robots.txt et la grille de requêtes par seconde de Crawl Control dans Bing Webmaster Tools.

Qu’est-ce que l’en-tête Retry-After et est-il nécessaire ? Retry-After indique au client combien de temps attendre avant de réessayer (un nombre de secondes ou une date HTTP). Il n’est pas strictement obligatoire, mais constitue une bonne pratique et donne aux robots un signal concret de ralentissement.

Google reprendra-t-il une exploration normale après l’arrêt des 429 ? Oui, automatiquement. Une fois le volume d’erreurs réduit, “the crawl rate will automatically start increasing again.” (traduction) : « le rythme d’exploration recommencera automatiquement à augmenter ». Aucune nouvelle demande n’est nécessaire et il n’y a pas de pénalité durable.

Un WAF ou un CDN peut-il envoyer accidentellement une 429 à Googlebot ? Très souvent. Des règles de pare-feu agressives, les limites par défaut d’un CDN ou d’un hébergeur et les outils de gestion des robots peuvent classer Googlebot ou Bingbot comme trafic abusif. Vérifiez l’identité du robot (DNS inverse puis direct) avant d’écrire une exception et assouplissez les limites qui interceptent de vrais moteurs de recherche.

429 est-elle une erreur client ou une erreur serveur ? Techniquement, c’est une erreur 4xx client dans la spécification HTTP. Mais Google la traite comme une erreur serveur pour l’exploration — c’est le seul code 4xx regroupé avec les 5xx.

Que doit faire mon client s’il reçoit une 429 sans en-tête Retry-After ? Il n’existe pas de formule imposée par HTTP — la spécification laisse ce choix à la politique du client. Une valeur par défaut raisonnable et bornée : backoff exponentiel avec jitter, plafond ferme du délai total et du nombre de tentatives pour ne pas réessayer indéfiniment, et vérification de l’idempotence avant de répéter une requête qui n’est pas sûre à envoyer deux fois. Consultez l’onglet Scripts pour un pseudocode détaillé.

Que faire face à une 429 ?

Problèmes courants liés à 429

Googlebot reçoit une 429, mais pas les visiteurs ordinaires

Symptôme : les rapports de robots indiquent 429 tandis que les contrôles dans un navigateur renvoient 200. Cause probable : gestion des robots, règle fondée sur le user-agent ou limitation par IP. Correctif : corrélez les événements du WAF avec des IP de robots vérifiées, puis resserrez ou corrigez la règle responsable ; n’autorisez pas un simple user-agent.

Le rythme d’exploration de tout le hostname diminue

Symptôme : l’exploration ralentit au-delà des URL qui ont renvoyé 429. Cause probable : Google applique le signal de surcharge à l’échelle du hostname. Correctif : arrêtez les 429 involontaires, rétablissez des réponses positives stables et laissez le rythme d’exploration se rétablir automatiquement.

Les réponses 429 continuent après l’incident

Symptôme : le serveur est sain, mais les URL renvoient encore 429. Cause probable : cache CDN, règle edge ou état du limiteur ayant survécu à l’événement. Correctif : désactivez ou faites expirer la règle temporaire, purgez une réponse mise en cache à tort et vérifiez plusieurs routes et régions représentatives.

Retry-After est absent ou inutilisable

Symptôme : les clients savent qu’ils ont été limités, mais pas quand réessayer. Cause probable : la réponse vient d’une règle de sécurité générique. Correctif : demandez à la couche émettrice d’envoyer un délai ou une date HTTP valide et testez l’en-tête brut.

Prompt : auditer une règle de limitation

Review this 429 rate-limit configuration for search-crawler safety. Identify its key,
scope, threshold source, Retry-After behavior, hostname-wide SEO impact, and any
user-agent-only exceptions. Separate deliberate short-term overload protection from
permanent crawl control. Return a minimal safe revision, test matrix, monitoring
signals, and rollback conditions. Do not invent provider syntax.

[PASTE CONFIGURATION AND SANITIZED SAMPLE LOGS]

Prompt : diagnostiquer des 429 inexpliquées

Use these headers, access-log rows, WAF events, and timestamps to determine which
layer generated the 429 and which traffic dimension triggered it. Give competing
hypotheses ranked by evidence, the next exact check for each, and a fix that does not
trust claimed crawler user agents. Do not infer missing logs.

[PASTE EVIDENCE]

Outils pour enquêter sur les 429

• Bulk HTTP Status Code Checker : testez un ensemble d’URL représentatif et exportez les routes qui renvoient actuellement 429.
• HTTP Header Checker : inspectez Retry-After, les empreintes CDN et les sauts de redirection de la réponse limitée.
• Googlebot Verifier : validez les éléments IP avant de créer une exception pour un robot.
• Log File Analyzer : segmentez le gaspillage lié aux codes de statut par robot et par section, tout en gardant les journaux importés dans le navigateur.
• Statistiques d’exploration de Search Console : comparez le moment des 429 avec l’évolution des requêtes d’exploration et du comportement de réponse de l’hôte.

Valider une configuration 429

Test du contrat de réponse

Test à exécuter : déclenchez la limite de manière sûre dans un environnement contrôlé et inspectez la réponse brute. Résultat attendu : 429 avec un Retry-After valide, sans redirection accidentelle ni statut de succès. Interprétation d’un échec : la mauvaise couche ou le mauvais modèle d’erreur possède la réponse. Fenêtre de supervision : immédiate. Déclencheur de retour arrière : des requêtes normales sont limitées ou le test déstabilise le service.

Test de portée

Test à exécuter : faites passer un client volontairement limité, des utilisateurs normaux et un robot vérifié sur plusieurs classes d’URL représentatives. Résultat attendu : seul le trafic défini dépasse la limite. Interprétation d’un échec : la clé de limitation ou la portée de la règle est trop large. Fenêtre de supervision : pendant le test contrôlé et la propagation sur les points de présence. Déclencheur de retour arrière : des routes, utilisateurs ou hôtes sans rapport reçoivent 429.

Test de rétablissement

Test à exécuter : arrêtez le déclencheur, attendez l’intervalle Retry-After configuré, puis répétez les requêtes. Résultat attendu : des réponses normales et stables reprennent sans contournement manuel par URL. Interprétation d’un échec : des 429 mises en cache ou un état du limiteur persistent. Fenêtre de supervision : l’intervalle configuré augmenté du délai de propagation du déploiement. Déclencheur de retour arrière : le hostname reste limité après la disparition de la charge sous-jacente.

Test de stockage en cache

Test à exécuter : placez un cache ou un CDN devant la route limitée, déclenchez une 429, puis demandez à nouveau la même URL une fois la condition d’origine résolue. Résultat attendu : la seconde requête est évaluée à nouveau — aucune 429 mise en cache ou rejouée ne vient du point de présence. Interprétation d’un échec : un intermédiaire stocke une réponse que la RFC 6585 indique comme ne devant pas être mise en cache ; vérifiez les en-têtes de contrôle du cache et la configuration de la règle edge, pas l’origine. Fenêtre de supervision : immédiate, sur un ensemble représentatif de nœuds ou POP edge. Déclencheur de retour arrière : une 429 en cache est servie après le rétablissement de l’origine.

Test de politique de nouvelle tentative client

Test à exécuter : faites passer un client par une 429 avec, puis sans, un en-tête Retry-After valide. Résultat attendu : avec l’en-tête, le client attend l’intervalle indiqué ; sans lui, le client applique un backoff borné avec jitter, respecte un nombre maximal de tentatives et vérifie l’idempotence avant de répéter une requête non idempotente. Interprétation d’un échec : un client qui réessaie immédiatement, sans limite ou qui répète aveuglément une requête non idempotente a une politique de nouvelle tentative défectueuse, et non un problème de conformité HTTP. Fenêtre de supervision : pendant toute la séquence bornée de tentatives. Déclencheur de retour arrière : le client redéclenche la même limite par des tentatives immédiates ou illimitées.

Ressources utiles

Mes articles connexes

• Codes de statut HTTP et leur impact SEO — mon guide complet de l’impact de chaque code de statut sur le SEO, y compris la place de 429.
• Le guide du débutant en SEO technique — la place des contrôles d’exploration et des codes de statut dans une vue d’ensemble.
• L’histoire du blocage de deux pages très bien classées avec robots.txt — mon expérience de première main sur ce qui se passe réellement lorsque l’on coupe l’accès aux robots.

Mes conférences

• Comment fonctionne la recherche (SlideShare) — mon parcours de l’exploration, du rendu, de l’indexation et du classement, y compris la manière dont les serveurs indiquent aux robots de ralentir. (Mon avertissement habituel s’applique : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) : « Voici ma compréhension des systèmes… elle ne sera pas complète ni exacte à 100 %. »)

Dans le secteur

• N’utilisez pas les 403 ou 404 pour limiter le débit (Google Search Central, Gary Illyes) — la formulation de référence qui établit que 429 est l’exception.
• Réduire le rythme d’exploration de Google (Google) — la fenêtre de 1 à 2 jours, le ralentissement à l’échelle du hostname et le rétablissement automatique.
• Google déconseille d’utiliser les codes de statut 403 ou 404 pour limiter le rythme d’exploration de Googlebot (Search Engine Land) — compte rendu de presse spécialisée de l’article d’Illyes.
• Google demande d’arrêter d’utiliser les 403 ou 404 pour réduire le rythme d’exploration de Googlebot (Search Engine Roundtable) — résumé de Barry Schwartz présentant 429 comme « l’unique exception ».
• Google : n’utilisez pas les réponses d’erreur 403/404 pour limiter Googlebot (Search Engine Journal) — troisième article indépendant sur ces mêmes recommandations.
• MDN — 429 Too Many Requests — définition HTTP et référence de Retry-After.
• Recommandations pour Bingbot — recommandations actuelles de Bing pour la directive crawl-delay.

Testez-vous : 429 Too Many Requests

Cinq questions rapides sur le fonctionnement de 429 et la manière dont Google le traite. Choisissez une réponse pour chaque question, puis vérifiez.

Journal des modifications