Réponse courte
Le code HTTP 429 signale qu’un client a dépassé le nombre de requêtes autorisées sur une période donnée. C’est le seul code de la série qu’on écrit soi-même : une règle de limitation de débit, pas une panne. Le corriger n’est donc jamais une question de capacité, c’est un arbitrage de réglage.
La règle est rarement là où on la cherche : l’application, le serveur web, le pare-feu applicatif et le CDN peuvent chacun l’émettre, et c’est en général le dernier de la chaîne qui répond en premier.
Volontaire
contrairement au 500 et au 503, ce code n’est pas subi : quelqu’un l’a configuré, souvent sans le savoir.
4xx
classé erreur client, alors que le client en cause est souvent Googlebot et la faute chez l’hébergeur.
Retry-After
l’en-tête qui transforme un refus sec en restriction lisible, et qui évite au robot de revenir trop tôt.
Comment diagnostiquer un code 429 ?
Cinq étapes, du plus structurant au plus décisif. La question n’est jamais « comment supprimer le 429 » mais « qui le reçoit, et l’avait-on prévu ».
- 01Identifier qui reçoit le refus. Un visiteur, un script interne, un outil d’audit, un robot tiers ou Googlebot ? Les journaux serveur le disent : adresse, agent déclaré, fréquence, URL visée. Aucune autre source ne le sait.
- 02Qualifier la zone touchée. Des pages indexables, des ressources de mise en forme, un point d’entrée d’API, une recherche interne ? Un 429 sur un fichier de style ou de script casse le rendu et produit un dégât indirect, plus difficile à relier à sa cause.
- 03Mesurer la sévérité pour le référencement. Googlebot est-il concerné, et sur quelles pages ? Croisez le rapport d’exploration de la Search Console avec les journaux : le rapport donne l’ampleur, les journaux donnent la cause.
- 04Localiser la règle dans la chaîne. Application, serveur web, pare-feu applicatif, CDN : les quatre savent émettre un 429, et le réglage n’est pas au même endroit selon le cas. Le plus en amont répond en premier, donc l’application peut n’y être pour rien.
- 05Vérifier le signal de reprise. Sans en-tête
Retry-After, un client qui a été refusé n’a aucune idée du moment où réessayer. Il revient au hasard, souvent trop tôt, et alimente lui-même le bruit qu’on cherchait à réduire.
Le raccourci à éviter. Poser une limite globale, identique pour tout le monde. Un seuil calibré sur un visiteur humain est très vite atteint par un robot d’exploration légitime, qui demande des dizaines de pages par minute sans rien avoir d’abusif. La limitation doit distinguer les agents avant de compter les requêtes.
À quoi ressemble une réponse 429 correcte ?
Le code seul ne suffit pas : ce sont les en-têtes qui rendent la restriction exploitable.
HTTP/1.1 429 Too Many Requests
Content-Type: text/html; charset=UTF-8
Retry-After: 120
Cache-Control: no-storeRetry-After annonce le délai avant de réessayer, en secondes ou sous forme de date. Cache-Control: no-store empêche qu’un intermédiaire conserve le refus et continue de le servir après la levée de la restriction.
Ne pas confondre 429, 503 et 403
Les trois refusent de servir la page, et c’est tout ce qu’ils ont en commun. Les distinguer change entièrement le diagnostic.
| Code | Ce qu’il dit vraiment | Ce qu’il faut regarder |
|---|---|---|
| 429 | Vous avez dépassé un seuil que j’ai fixé | La règle de limitation, pas la capacité |
| 503 | Je suis temporairement incapable de répondre | La charge réelle du serveur |
| 403 | Je refuse, et ce n’est pas une question de rythme | Les droits et les règles de sécurité |
La confusion la plus coûteuse est entre 429 et 503 : on ajoute de la capacité pour résoudre un problème de configuration, ce qui ne change rien et coûte cher.
D’où vient le 429, et comment le corriger
Pour chaque origine, le signe qui la trahit et la correction associée.
| Origine | Ce qui la trahit | Correction |
|---|---|---|
| Extension de sécurité | 429 servis depuis l’application, souvent après une mise à jour | Exclure les robots légitimes de la règle |
| Pare-feu applicatif | Refus avant même que l’application soit sollicitée | Segmenter les seuils par type d’agent |
| CDN ou proxy inverse | Le serveur d’origine ne voit passer aucune requête | Relever le seuil appliqué aux robots d’indexation |
| Quota d’API | 429 limités aux points d’entrée programmatiques | Étaler les appels, respecter Retry-After côté client |
| Robot tiers agressif | Un agent inconnu monopolise le quota partagé | Cibler cet agent, sans durcir la règle générale |
| Seuil hérité jamais relu | Une limite fixée il y a des années, pour un autre trafic | Recalibrer sur le volume réel d’aujourd’hui |
Quel est l’impact SEO d’un code 429 ?
Le 429 appartient à la famille des erreurs client, mais quand le client est un robot d’indexation, son effet ressemble à celui d’une erreur serveur : la cadence d’exploration baisse, et pas seulement sur les URL refusées.
Exploration
Googlebot réduit son rythme dès qu’il rencontre des refus répétés. Il le fait pour ménager votre serveur, ce qui est exactement l’inverse du but recherché si la limite était mal calibrée.
Budget de crawl
Chaque requête refusée est un passage consommé sans rien rapporter. Sur un site à forte volumétrie, ce gaspillage retarde la découverte des pages qui comptent.
Rendu
Un 429 servi sur un fichier de style ou de script empêche la page d’être vue telle que vos visiteurs la voient. Le dégât est invisible dans un rapport d’erreurs classé par URL de page.
Indexation
Les nouvelles pages sont découvertes plus tard, et les URL refusées de façon prolongée finissent par sortir de l’index, comme sous un 5xx persistant.
Quand un 429 devient un vrai risque
Un 429 bien ciblé protège l’infrastructure et ne coûte rien en référencement. Trois situations le font basculer.
À retenir
- 01Il touche Googlebot sur des pages indexables, et non des agents abusifs.
- 02Il est servi sans
Retry-After, donc sans indication de reprise. - 03Il dure, parce que personne ne surveille les codes de réponse servis aux robots.
Sur votre site
Vos règles de sécurité bloquent-elles Googlebot sans que vous le sachiez ?
Je relève les codes de réponse réellement servis aux robots d’indexation sur trente jours et je vous dis lesquels traiter en premier. Réponse sous 24 heures ouvrées.
Les bonnes pratiques à retenir
Six habitudes qui séparent une protection utile d’un frein à l’indexation.
- Segmenter les seuils par type d’agent avant de les durcir pour tout le monde.
- Exclure les robots d’indexation légitimes des règles de limitation générales.
- Accompagner tout 429 d’un en-tête
Retry-Afterréaliste. - Interdire la mise en cache des réponses 429, pour que la levée soit immédiate.
- Vérifier le code servi aux robots après chaque mise à jour d’extension de sécurité.
- Relire les seuils une fois par an : ils sont presque toujours calibrés sur un trafic périmé.
Les codes à ne pas confondre avec un 429
503Service Unavailable
Indisponibilité subie, liée à la capacité. Le 429 est une restriction choisie : ajouter des serveurs ne le fera pas disparaître.
Lire la fiche →
403Forbidden
Refus d’accès sans notion de rythme. Là où le 429 dit « pas si vite », le 403 dit « pas du tout ».
Lire la fiche →
500Internal Server Error
Erreur interne non maîtrisée. Le 429 est au contraire un refus délibéré, émis par une infrastructure qui fonctionne.
Lire la fiche →
4xxErreurs client
La famille à laquelle le 429 appartient, et dont il est le membre le plus trompeur : le client désigné est souvent un robot légitime.
Lire la fiche →
Questions fréquentes sur le code 429
Un 429 est-il pénalisant pour le référencement ?
Pas en soi. Servi à un robot abusif, c’est une protection saine. Servi à Googlebot sur des pages indexables, il fait baisser la cadence d’exploration et retarde la découverte des contenus. Toute la différence tient au ciblage de la règle.
Pourquoi mon site renvoie-t-il des 429 alors que je n’ai rien configuré ?
Parce que la règle vient rarement de vous. Une extension de sécurité, un pare-feu applicatif ou un CDN appliquent des limites par défaut, et le plus en amont dans la chaîne répond en premier. C’est pourquoi le diagnostic commence par localiser l’émetteur.
Quelle est la différence entre un 429 et un 503 ?
Le 503 dit que le serveur ne peut pas répondre, le 429 qu’il ne veut pas répondre si vite. Le premier se corrige en capacité ou en performance, le second en réglage. Les confondre conduit à payer des serveurs pour un problème de configuration.
Faut-il vraiment ajouter un en-tête Retry-After ?
Oui, et c’est peu coûteux. Sans lui, le client refusé revient au hasard, souvent trop tôt, et amplifie la charge que la limitation devait justement contenir. Avec lui, la restriction devient lisible et le trafic se réétale de lui-même.
Comment savoir si Googlebot est réellement touché ?
En croisant deux sources. Le rapport d’exploration de la Search Console montre l’évolution des réponses reçues, les journaux serveur montrent quelles URL ont été refusées et à quel agent. Le rapport donne l’ampleur, les journaux donnent la cause.
Sources
- 1RFC 6585 : définition du code 429. Contrairement aux autres codes de la série, il ne figure pas dans la RFC 9110 mais dans ce complément.
- 2MDN : le statut 429 Too Many Requests
- 3MDN : l’en-tête Retry-After
- 4Google Search Central : réduire la fréquence d’exploration de Googlebot
- 5Google Search Central : gérer le budget d’exploration d’un grand site
- 6Constats issus d’audits de logs, méthode décrite dans la fiche Analyse de logs
Articles similaires
Powered by : Damien Hernandez
