Erreur 429 (Too Many Requests)

L'erreur 429 (Too Many Requests) est un code de statut HTTP par lequel un serveur indique qu'un client a envoyé trop de requêtes dans un laps de temps donné. C'est le code de la limitation de débit, ou rate limiting, renvoyé par les serveurs, les pare-feu applicatifs et les CDN pour freiner un client trop insistant. Pour le SEO, c'est un cas à part : c'est le seul code 4xx que Google traite comme une erreur serveur, avec ralentissement de l'exploration puis retrait de l'index si la situation dure.

Définition détaillée de l'erreur 429

Le code 429 a été introduit en avril 2012 par la RFC 6585 (« Additional HTTP Status Codes »), signée par Mark Nottingham et Roy Fielding. Le texte est court : « le code 429 indique que l'utilisateur a envoyé trop de requêtes dans un laps de temps donné (limitation de débit) ». La réponse devrait expliquer la condition, et peut inclure un en-tête Retry-After indiquant combien de temps attendre avant une nouvelle requête. Une réponse 429 ne doit pas être mise en cache.

La RFC laisse volontairement ouvert ce que « l'utilisateur » veut dire et comment les requêtes sont comptées : par adresse IP, par session, par jeton d'authentification, par ressource ou pour l'ensemble du serveur. Chaque outil fait son choix, et c'est ce choix qui décide si un robot légitime se retrouve ou non pris dans le filet.

À la différence d'une 403, qui interdit, ou d'une 404, qui dit que la ressource n'existe pas, la 429 dit que la ressource existe, que le client y a droit, mais pas à ce rythme. C'est un message temporaire par nature, ce qui explique le traitement particulier que lui réservent les moteurs.

Qui renvoie des erreurs 429

La 429 est rarement produite par l'application elle-même. Elle vient le plus souvent d'une couche placée devant :

• Les pare-feu applicatifs et les CDN : Cloudflare, par exemple, propose des règles de limitation de débit dont l'action de blocage renvoie par défaut le code 429, configurable entre 400 et 499. La règle compte les requêtes par période selon des caractéristiques choisies (adresse IP, cookie, empreinte du client) et bloque pendant une durée définie une fois le seuil atteint.
• Les hébergeurs mutualisés, qui plafonnent le nombre de requêtes simultanées ou par minute d'un même client pour protéger les autres sites du serveur.
• Les extensions de sécurité des CMS, qui limitent les tentatives de connexion, les requêtes vers la recherche interne ou les appels à l'API du site.
• Les API, pour lesquelles la 429 est le mécanisme standard de quota : la plupart des API publiques renvoient ce code quand la clé a dépassé son allocation.
• Les serveurs web eux-mêmes, via des modules de limitation (par exemple limit_req sur nginx), quand l'administrateur a choisi ce code plutôt que le 503 par défaut.

Le point commun : ces couches raisonnent en volume de requêtes par client, et un robot d'exploration est, par construction, un client qui envoie beaucoup de requêtes. Une règle pensée contre le scraping ou les attaques par force brute touche aussi Googlebot si elle ne l'exclut pas.

Ce que Google fait d'une erreur 429

La documentation Google Search Central sur les codes de statut HTTP est explicite : « les robots d'exploration Google traitent le code d'état 429 comme un signal indiquant que le serveur est surchargé. Il est considéré comme une erreur du serveur. » Toutes les autres erreurs 4xx signifient pour Google que le contenu n'existe pas et conduisent à retirer l'URL de l'index ; la 429 fait exception et rejoint la famille des 5xx.

Concrètement, les erreurs 5xx et 429 incitent les robots de Google à ralentir temporairement l'exploration. Les URL déjà indexées sont conservées dans un premier temps, mais finissent par être supprimées de l'index si l'erreur persiste. Le contenu éventuellement renvoyé avec la 429 est ignoré. Quand le serveur répond de nouveau en 200, Google augmente progressivement sa vitesse d'exploration.

Google en fait d'ailleurs un outil : sa documentation sur la réduction de la vitesse d'exploration recommande, pour freiner Googlebot en urgence, de renvoyer 500, 503 ou 429 au lieu de 200 pendant quelques heures ou un à deux jours au plus. Le ralentissement s'applique au nom d'hôte entier, pas seulement aux URL en erreur, et la vitesse remonte automatiquement quand les erreurs cessent. Au-delà d'un à deux jours, Google prévient que les URL qui répondent en erreur pendant plusieurs jours peuvent être retirées de l'index. Ce levier a remplacé, depuis le 8 janvier 2024, l'ancien limiteur de vitesse d'exploration de la Search Console.

Une 429 sur le robots.txt

Le fichier robots.txt suit la même logique. Google traite toutes les erreurs 4xx sur ce fichier, sauf la 429, comme l'absence de robots.txt : le crawl se fait alors sans restriction. La 429, elle, est traitée comme une erreur serveur : Google cesse d'explorer le site pendant les douze premières heures tout en réessayant, puis utilise pendant trente jours la dernière version valide du fichier. Une règle de limitation de débit qui s'applique au robots.txt peut donc suspendre tout le crawl, alors que les pages répondent normalement.

Le cas des robots d'IA

Les robots des éditeurs de modèles de langage (GPTBot et OAI-SearchBot chez OpenAI, ClaudeBot chez Anthropic, et d'autres) sont devenus une part visible du trafic automatisé de beaucoup de sites. La limitation de débit est une réponse courante des éditeurs, à côté du blocage pur et simple, et la 429 est alors le code que ces robots reçoivent.

Deux remarques d'usage. D'abord, ces éditeurs publient le nom de leur user-agent et, pour la plupart, leurs plages d'adresses IP : quand l'objectif est d'exclure un robot, une règle dans le robots.txt ou un blocage ciblé est plus lisible qu'un seuil de requêtes, et n'expose pas au risque de toucher d'autres clients. Ensuite, une règle de débit écrite pour les robots d'IA ne doit pas s'appliquer aux robots des moteurs de recherche : Cloudflare avertit dans sa documentation que l'application de règles de limitation aux robots vérifiés « peut affecter le référencement ». La plupart des outils offrent une caractéristique « robot vérifié » ou une liste d'exclusion pour ce cas. La chaîne user-agent seule ne suffit pas à identifier Googlebot, qui se vérifie par résolution DNS inverse ou par ses plages d'adresses publiées.

Comment configurer une limitation de débit sans pénaliser le SEO

• Exclure les robots vérifiés des moteurs (Google, Bing, et les moteurs utiles au marché du site) de toute règle de seuil, ou leur accorder une limite très supérieure à celle des clients anonymes. Googlebot ajuste lui-même sa vitesse en fonction des temps de réponse et des erreurs ; le brider par une 429 n'apporte rien qu'un crawl plus lent.
• Cibler les chemins sensibles plutôt que tout le site : formulaire de connexion, recherche interne, API, panier, pages de filtres. Une navigation à facettes qui génère des milliers d'URL est un cas fréquent d'exploration excessive, mais la réponse est dans la structure des URL et le robots.txt, pas dans une 429 globale.
• Renseigner l'en-tête Retry-After avec une durée réaliste : la RFC le prévoit, et les clients bien écrits le respectent.
• Calibrer les seuils sur le trafic réel : un seuil fixé au doigt mouillé sur un hébergement mutualisé bloque des visiteurs derrière un même réseau d'entreprise ou un même opérateur mobile, dont les adresses IP sont partagées.
• Préférer la 503 avec Retry-After quand le but est de protéger le serveur pendant une surcharge générale : le message est plus juste (« je ne peux pas répondre maintenant ») que « vous demandez trop ».
• Vérifier le robots.txt, le sitemap et les ressources (CSS, JavaScript, images) : une règle de débit qui les couvre empêche Google de rendre les pages, même si le HTML passe.

Diagnostiquer et corriger une erreur 429

Le premier réflexe est de regarder d'où vient la réponse. Un en-tête Server ou cf-ray, une page d'erreur au format du CDN ou de l'hébergeur disent si la 429 est produite par le site ou par une couche intermédiaire. Reproduire avec curl -I depuis une autre adresse IP confirme si le blocage est lié au client ou général.

Côté robots, l'analyse de logs est le seul moyen de savoir quelles requêtes de Googlebot ont reçu une 429, sur quelles URL et à quelle fréquence. La Search Console signale les erreurs serveur rencontrées par Googlebot, avec un délai de quelques jours, et une baisse brutale du nombre de requêtes d'exploration dans les statistiques d'exploration est souvent le premier symptôme visible.

La correction est presque toujours une affaire de configuration : relever ou supprimer la règle en cause, exclure les robots vérifiés, restreindre la règle aux chemins qui la justifient. Après correction, la vitesse d'exploration remonte progressivement ; il n'y a rien à demander à Google, sinon une réexploration des pages importantes via l'inspection d'URL si elles ont disparu de l'index.

Les erreurs fréquentes

• Croire que la 429 est une 4xx comme les autres. Pour Google, c'est une erreur serveur : elle ralentit le crawl de tout l'hôte et peut faire sortir des pages de l'index si elle dure.
• Bloquer Googlebot sur la base du volume. Un robot de moteur envoie beaucoup de requêtes, c'est son rôle. Le seuil doit distinguer le robot vérifié du client anonyme.
• Laisser une règle d'urgence en place. Renvoyer 429 pour calmer un pic est prévu par Google, mais pas plus d'un à deux jours.
• Oublier les robots des autres moteurs : Bingbot et les robots des moteurs importants pour l'audience du site ont besoin de la même exemption.
• Servir une page « trop de requêtes » en code 200, ce qui la fait indexer à la place du contenu, ou en 403, que Google interprète comme un contenu inexistant.

FAQ

Google traite-t-il l'erreur 429 comme une erreur 404 ?

Non. Toutes les erreurs 4xx sauf la 429 signifient pour Google que le contenu n'existe pas, et l'URL est retirée de l'index. La 429 est traitée comme une erreur serveur, au même titre que les 5xx : Google ralentit l'exploration, conserve les pages indexées dans un premier temps, puis les retire si l'erreur persiste plusieurs jours.

Peut-on utiliser la 429 pour ralentir Googlebot ?

Oui, c'est l'un des trois codes (avec 500 et 503) que Google recommande pour réduire sa vitesse d'exploration en urgence. Le ralentissement est quasi immédiat et s'applique à tout le nom d'hôte. La limite : pas plus d'un à deux jours, sinon les URL en erreur risquent d'être retirées de l'index.

Une erreur 429 est-elle toujours causée par le site ?

Rarement par l'application elle-même. Elle vient le plus souvent d'une couche intermédiaire : règle de limitation de débit d'un CDN ou d'un pare-feu applicatif, plafond de l'hébergeur mutualisé, extension de sécurité du CMS. Les en-têtes de la réponse et le format de la page d'erreur permettent d'identifier cette couche.

Comment savoir si Googlebot reçoit des 429 ?

Par les journaux d'accès du serveur ou du CDN, filtrés sur le user-agent Googlebot et le code 429. La Search Console signale les erreurs serveur rencontrées par Googlebot avec quelques jours de délai, et une chute soudaine des requêtes d'exploration dans les statistiques d'exploration est un signe d'alerte.

Faut-il limiter le débit des robots d'IA avec des 429 ?

C'est une pratique courante, mais si l'objectif est d'exclure un robot identifié, une règle dans le robots.txt ou un blocage ciblé sur son user-agent et ses adresses IP publiées est plus simple et plus prévisible. L'essentiel est que la règle n'atteigne pas les robots vérifiés des moteurs de recherche, faute de quoi le référencement en pâtit.

En résumé

• Erreur 429 : code HTTP défini par la RFC 6585 (avril 2012) qui signifie « trop de requêtes dans un laps de temps donné » ; réponse non cachable, avec un en-tête Retry-After optionnel.
• Origine : règles de limitation de débit d'un CDN ou d'un pare-feu applicatif (429 par défaut chez Cloudflare), plafonds d'hébergeur, extensions de sécurité, quotas d'API.
• Pour Google : la seule erreur 4xx traitée comme une erreur serveur ; ralentissement du crawl de tout l'hôte, pages conservées puis retirées de l'index si l'erreur persiste, remontée progressive au retour en 200.
• Levier d'urgence : renvoyer 429, 500 ou 503 fait baisser la vitesse de Googlebot presque immédiatement, pour un à deux jours au plus.
• Robots.txt : une 429 sur ce fichier suspend le crawl pendant douze heures, puis Google utilise la version en cache pendant trente jours.
• Bonne pratique : exclure les robots vérifiés des moteurs de toute règle de seuil, cibler les chemins sensibles, renseigner Retry-After, ne pas confondre robots d'IA et robots de moteurs.

Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !