HTTP 429 : trop de requêtes (Too Many Requests)

L'équipe Citead, mis à jour le

En bref. HTTP 429 signale une limitation du débit, peut inclure Retry-After et entraîne un ralentissement temporaire des robots d’exploration de Google.

Définition : HTTP 429 Too Many Requests est le code de statut de réponse défini par la RFC 6585 lorsqu’un utilisateur envoie trop de requêtes sur une période donnée. Un serveur peut inclure Retry-After pour indiquer un délai d’attente avant une nouvelle requête.

Points clés

  • La RFC 6585 indique que la réponse devrait expliquer la situation et ne doit pas être stockée dans un cache.
  • La RFC 9110 définit Retry-After comme une date HTTP ou un délai en secondes.
  • Au 17 octobre 2026, la documentation de Google sur ses robots d’exploration traite le code 429 comme un signal de surcharge du serveur qui ralentit temporairement l’exploration.

Comment la limite de débit est-elle déterminée ?

La limitation du débit des requêtes (rate limiting) contrôle leur fréquence dans le temps. La RFC 6585, section 4, autorise un comptage par ressource, à l’échelle d’un serveur ou de plusieurs serveurs. Des identifiants d’authentification ou un cookie conservant un état peuvent identifier l’utilisateur dont les requêtes sont comptabilisées dans la limite.

La RFC donne comme exemple une règle de 50 requêtes par heure et par utilisateur connecté. Ce quota appartient à cet exemple ; la spécification laisse à l’exploitant du serveur le choix des règles d’identification et de comptage. Le corps de la réponse devrait expliquer la situation pour que le destinataire comprenne la restriction applicable.

Comment Retry-After indique-t-il quand réessayer ?

Les en-têtes de réponse suivants reproduisent l’exemple de la RFC 6585 :

HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600

La RFC 9110, section 10.2.3, précise qu’une valeur numérique exprime un nombre de secondes à compter de la réception de la réponse. Ici, le délai indiqué est de 3600 secondes. Une date HTTP désigne quant à elle un instant précis. Les délais numériques utilisent des nombres entiers décimaux positifs ou nuls.

Le choix du moment où réessayer exige aussi de tenir compte de l’opération répétée. La même RFC définit une méthode idempotente comme une méthode pour laquelle plusieurs requêtes identiques ont le même effet attendu sur le serveur qu’une seule requête. Elle conseille aux clients de répéter automatiquement les requêtes non idempotentes uniquement lorsqu’ils savent que l’opération est effectivement idempotente ou peuvent détecter que la requête initiale n’a jamais été appliquée.

Qu’est-ce que cela change pour l’exploration ?

La documentation de Google sur les codes de statut HTTP regroupe le code 429 avec les erreurs serveur pour le traitement par ses robots d’exploration. Pour Google Search, les URL déjà indexées restent d’abord dans l’index, puis finissent par en être retirées si ces erreurs persistent. Lorsque le serveur recommence à renvoyer des réponses indiquant un succès, Google augmente progressivement la fréquence d’exploration du site.

Une limitation persistante du débit influe donc sur la disponibilité d’un site pour les robots d’exploration de Google. Le signal de rétablissement documenté est le retour à des réponses HTTP indiquant un succès. Ces règles de traitement concernent spécifiquement l’infrastructure de Google.

Termes associés

Questions fréquentes

Toutes les réponses 429 doivent-elles inclure Retry-After ?

La RFC 6585 rend cet en-tête facultatif. Elle recommande par ailleurs d’expliquer la limitation du débit dans le corps de la réponse.

Comment interpréter une valeur numérique de Retry-After ?

Selon la RFC 9110, vous comptez les secondes indiquées à partir de la réception de la réponse. Son exemple Retry-After: 120 correspond à un délai de deux minutes.

Devez-vous utiliser le code 403 pour ralentir les robots d’exploration de Google ?

La documentation de Google déconseille explicitement d’utiliser les codes 401 ou 403 pour limiter la fréquence d’exploration. Elle identifie le code 429 comme l’exception parmi les réponses d’erreur client qui influe sur cette fréquence.

Sources

  1. IETF, « RFC 6585: Additional HTTP Status Codes », avril 2012
  2. IETF, « RFC 9110: HTTP Semantics », juin 2022
  3. 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