En bref. Retry-After transmet un délai d’attente suggéré dans un en-tête de réponse HTTP, tandis que le traitement par les robots dépend du comportement documenté de chaque implémentation.
Définition : Retry-After est un en-tête de réponse HTTP qui indique au client combien de temps il devrait attendre avant d’envoyer une nouvelle requête. La RFC 9110 définit sa valeur comme une date HTTP ou un délai en secondes à compter de la réception de la réponse.
Points clés
- La RFC 9110, HTTP Semantics définit la valeur en secondes comme un entier décimal positif ou nul.
- La RFC 6585, Additional HTTP Status Codes autorise Retry-After dans une réponse 429 Too Many Requests, qui signale une limitation du débit (rate limiting).
- Au 17 octobre 2026, les consignes de Google sur la fréquence d’exploration décrivent l’emploi de Retry-After avec les réponses 503 ou 429 pour indiquer quand ses robots peuvent renouveler leur requête.
- La documentation de Google sur les codes d’état HTTP indique que ses robots ralentissent temporairement l’exploration en cas d’erreurs serveur ou de réponses 429 ; le contenu reçu avec une réponse 5xx est ignoré.
Comment le délai d’attente est-il exprimé ?
La section 10.2.3 de la RFC 9110 définit deux possibilités. Une valeur numérique exprime un nombre de secondes à compter de la réception de la réponse. L’exemple ci-dessous, tiré de la RFC, demande une attente de deux minutes :
Retry-After: 120
Une date HTTP indique un instant précis. Les consignes de Google sur la fréquence d’exploration donnent cet autre exemple :
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT
Le format numérique exige un nombre entier de secondes : une valeur fractionnaire ne respecte donc pas la grammaire de la RFC.
Quelles réponses utilisent Retry-After ?
La section 15.6.4 de la RFC 9110 définit le code 503 Service Unavailable pour une surcharge temporaire ou une maintenance planifiée. Un serveur peut inclure Retry-After pour suggérer au client un délai d’attente. Avec ce code d’état, l’en-tête exprime la durée prévue d’indisponibilité du service.
La limitation du débit consiste à restreindre le nombre de requêtes sur une période donnée. La section 4 de la RFC 6585 définit le code 429 Too Many Requests pour cette situation et rend Retry-After facultatif. La spécification laisse au serveur le choix de la méthode d’identification des utilisateurs et de comptage des requêtes.
La RFC 9110 définit également Retry-After pour les réponses de redirection de la classe 3xx. Dans ce contexte, l’en-tête exprime le délai minimal demandé avant de suivre la redirection. Son interprétation exige donc de lire sa valeur conjointement avec le code d’état de la réponse.
Quelles sont les limites pour les robots d’exploration ?
Les consignes de Google pour réduire la fréquence d’exploration en urgence montrent l’en-tête dans cette réponse :
HTTP/1.1 503 Service Unavailable
Retry-After: 120
Les mêmes consignes indiquent qu’un nombre important de réponses 500, 503 ou 429 réduit l’exploration sur l’ensemble du nom d’hôte, y compris pour les URL qui renvoient toujours du contenu. La fréquence d’exploration augmente de nouveau automatiquement à mesure que ces erreurs diminuent.
Google déconseille de renvoyer ces erreurs pendant plus d’un ou deux jours. Si Googlebot les observe sur la même URL pendant plusieurs jours, cette URL peut sortir de l’index de recherche de Google. Retry-After s’inscrit dans la gestion des surcharges temporaires ; des réponses d’erreur persistantes ont leurs propres conséquences sur l’indexation. La documentation citée n’établit pas de calendrier commun de nouvelles tentatives pour les robots des moteurs de réponse.
Termes associés
Questions fréquentes
Retry-After contient-il des secondes ou des millisecondes ?
La RFC 9110 spécifie des secondes pour la forme numérique. Vous pouvez également fournir une date HTTP.
Retry-After est-il obligatoire avec une réponse de limitation du débit ?
La RFC 6585 rend l’en-tête facultatif avec 429 Too Many Requests. Le code d’état signale la limitation du débit même lorsque le serveur omet l’en-tête.
Sources
- IETF, "RFC 9110: HTTP Semantics", juin 2022
- IETF, "RFC 6585: Additional HTTP Status Codes", avril 2012
- Google, "Reduce the Google crawl rate", mis à jour le 6 octobre 2026
- Google, "How HTTP status codes affect Google's crawlers", mis à jour le 4 février 2026
Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO