Retry-After

L'équipe Citead, mis à jour le

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

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

  1. IETF, "RFC 9110: HTTP Semantics", juin 2022
  2. IETF, "RFC 6585: Additional HTTP Status Codes", avril 2012
  3. Google, "Reduce the Google crawl rate", mis à jour le 6 octobre 2026
  4. 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

Testez une page et voyez quoi corriger en premier

L'analyse prend en général moins de 10 secondes et ne demande pas de compte.

400 000+ pages notées dans le benchmark public