En bref. Utilisez HTTP 429 en cas de requêtes trop nombreuses et ajoutez Retry-After si nécessaire, en gardant temporaires les réponses signalant une surcharge à Google.
Définition : HTTP 429 Too Many Requests est le code d’état de réponse destiné à un client qui dépasse une limite de fréquence des requêtes. Un serveur peut inclure un en-tête Retry-After pour indiquer combien de temps le client doit attendre avant d’envoyer une nouvelle requête.
Points clés
- La RFC 6585, section 4 définit le code 429 et recommande que la réponse explique le dépassement de la limite de fréquence.
- La RFC 9110, section 10.2.3 définit Retry-After comme une date et une heure ou un délai en secondes.
- En octobre 2026, les consignes de Google sur la fréquence d’exploration décrivent un ralentissement des robots d’exploration (crawlers) sur l’ensemble du nom d’hôte lorsqu’un nombre important d’URL renvoient 500, 503 ou 429.
- La documentation de Google sur les codes d’état HTTP traite le code 429 comme un signal de surcharge du serveur et déconseille d’utiliser 401 ou 403 pour limiter l’exploration.
Quel code d’état le serveur doit-il utiliser ?
La RFC 6585 attribue le code 429 aux requêtes trop nombreuses sur une période donnée. Le serveur choisit comment compter les requêtes et identifier le client. La spécification autorise un décompte par ressource, à l’échelle d’un serveur ou de plusieurs serveurs. Les réponses portant ce code d’état ne doivent pas être stockées dans un cache.
HTTP 503 Service Unavailable décrit une surcharge temporaire ou une maintenance planifiée selon la RFC 9110, section 15.6.4. Un serveur peut donc utiliser 429 lorsqu’un client dépasse le nombre de requêtes qui lui est accordé, ou 503 lorsque la situation correspond à une indisponibilité temporaire du service. Les deux codes permettent d’envoyer un en-tête Retry-After.
Quelles informations sur la nouvelle tentative inclure dans la réponse ?
La partie de l’exemple de la RFC 6585 qui contient les en-têtes est la suivante :
HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
Ici, le délai d’attente est de 3600 secondes. Il s’agit de la valeur donnée en exemple dans la RFC ; le corps de la réponse devrait expliquer les circonstances réelles du dépassement de la limite de fréquence.
La RFC 9110 précise que le délai est un entier décimal positif ou nul, mesuré à partir de la réception de la réponse. L’autre forme possible est une date HTTP. Les consignes de Google sur la fréquence d’exploration autorisent explicitement les deux formes avec 503 ou 429 pour indiquer quand ses robots peuvent renouveler leur requête.
Quelles conséquences pour l’exploration et l’indexation de Google ?
Les consignes de Google pour réduire la fréquence d’exploration en urgence présentent les réponses d’erreur temporaires comme une mesure à court terme. Lorsqu’un nombre suffisant d’URL renvoient ces erreurs, l’exploration ralentit sur l’ensemble du nom d’hôte, y compris pour les URL qui renvoient toujours du contenu. La fréquence augmente à nouveau automatiquement lorsque les erreurs diminuent.
Les mêmes consignes déconseillent de prolonger cette mesure au-delà d’un ou deux jours : des erreurs répétées sur une URL pendant plusieurs jours peuvent entraîner son retrait de l’index de Google. Une exploration plus lente retarde aussi l’actualisation des pages existantes, notamment la prise en compte des changements de prix et de disponibilité.
Pour établir le diagnostic, Google recommande d’examiner les journaux d’accès récents du serveur avec l’hébergeur. Parmi les causes de forte hausse énumérées figurent la navigation à facettes, qui crée des URL pour les filtres et le tri, ainsi que les calendriers comportant de nombreuses URL associées à des dates précises. Le traitement de cette cause doit accompagner la modification temporaire des réponses.
Termes associés
- HTTP 429 : trop de requêtes (Too Many Requests)
- Codes d’état HTTP
- Googlebot
- Analyse des journaux serveur
Questions fréquentes
Puis-je utiliser 403 pour ralentir Googlebot ?
La documentation de Google sur les codes d’état déconseille 401 et 403 pour limiter la fréquence d’exploration. Elle présente 429 comme l’exception parmi les codes d’erreur client qui signale une surcharge.
Retry-After est-il obligatoire avec 429 ?
La RFC 6585 rend cet en-tête facultatif. Elle recommande d’inclure dans le corps de la réponse des détails expliquant la situation.
Un serveur doit-il répondre à chaque requête excédentaire par 429 ?
La RFC 6585, section 7.2, reconnaît que produire des réponses d’erreur consomme des ressources. En cas d’attaque ou de volume de requêtes très élevé, un serveur peut couper les connexions ou prendre d’autres mesures pour limiter l’utilisation des ressources.
Sources
- IETF, « Additional HTTP Status Codes », avril 2012
- IETF, « HTTP Semantics », juin 2022
- Google, « Reduce the Google crawl rate », 6 octobre 2026
- Google, « How HTTP status codes affect Google's crawlers », 4 février 2026
Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO