Une hausse de 429 Too Many Requests peut signifier que le serveur est réellement saturé, qu’une clé de quota est trop large ou qu’un client légitime partage son budget avec des milliers d’autres. Ce symptôme donne le même refus à Googlebot et au scraper, tandis que CPU et base de données restent parfois sous-utilisés. À l’inverse, augmenter tous les plafonds pour restaurer le crawl peut exposer l’infrastructure à l’abus qui avait motivé la limite.
En pratique, le vrai enjeu est qu’un quota n’est pas un nombre de requêtes universel. Il protège une ressource précise, sur une fenêtre explicite, au moyen d’une clé qui représente raisonnablement le client ou le coût. Pour corriger les 429, il faut relier décision, route, algorithme et capacité, puis mesurer la récupération. Le statut renseigne le résultat ; les logs de quota expliquent pourquoi il s’est produit.
Vous allez reconstruire cette chaîne, calibrer les budgets et traiter l’urgence Googlebot sans affaiblir la défense. Notre accompagnement en SEO technique joint ces preuves aux données de crawl et aux parcours commerciaux afin que chaque changement de rate limiting possède un canari, des seuils et un repli.
Reconnaître une saturation produite par le quota
Distinguer limite atteinte et infrastructure saturée
Commencez par superposer quatre séries : nombre de requêtes, décisions 429, utilisation des ressources et latence. Si les 429 montent tandis que CPU, mémoire, pool et TTFB restent stables, le plafond ou sa clé est probablement le premier goulot. Si la capacité s’épuise avant les 429, la règle intervient trop tard ou protège la mauvaise couche. Si erreurs et latence précèdent le pic de volume, recherchez une dépendance lente plutôt qu’un client excessif.
Segmentez la hausse par route, méthode, hostname, identité vérifiée, clé de quota, point de présence et version de règle. Un pic global peut être constitué de milliers de réponses GET en cache sans danger, tandis qu’une seule route de recherche consomme la base. Comptez également les clients uniques et la concurrence. Dix mille requêtes séquentielles sur une heure ne créent pas la même pression que cent appels simultanés.
Exemple concret : Googlebot reçoit 18 % de 429 sur les catégories à 02 h, mais le CPU reste à 35 %. Les logs montrent une limite par adresse au CDN, partagée par plusieurs types de robots Google issus d’une plage et remise à zéro sur une fenêtre fixe. La limite produit une falaise au changement d’heure. Passer à un budget par hostname, route et identité vérifiée avec recharge progressive restaure le crawl sans augmenter le quota de l’API de recherche.
Vérifiez aussi les réponses de substitution. Un WAF peut afficher une page de challenge en 200 au lieu de 429, masquant le taux réel. Une API peut envelopper « rate_limit_exceeded » dans un JSON 200. Le diagnostic inspecte statut au bord, statut origine et contenu final. La métrique de décision interne doit correspondre à ce que reçoit le client.
Employer 429 et Retry-After avec leur vraie sémantique
Décrire un excès de requêtes, pas une ressource absente
Le RFC 6585 définit 429 Too Many Requests comme le cas où un client a envoyé trop de requêtes pendant une période. La réponse devrait expliquer la condition et peut inclure Retry-After. Le RFC ne prescrit ni la manière d’identifier le client, ni le compteur : par ressource, serveur, cluster, authentification ou cookie. Cette liberté impose de documenter votre propre contrat.
Utilisez Retry-After lorsque le délai avant une nouvelle tentative est estimable. Une valeur en secondes convient à un seau dont on connaît la recharge ; une date convient à une suspension bornée. Ne promettez pas dix secondes si une file manuelle décide du déblocage. Un client bien élevé peut respecter le délai, mais d’autres l’ignorent. La protection doit donc rester sûre même sans coopération.
Ne remplacez pas 429 par 403 ou 404 pour ralentir : ces codes n’expriment pas une surcharge et Google précise que les 4xx autres que 429 n’ont pas le même effet sur la cadence. Ne retournez pas non plus 503 pour un quota individuel sain ; 503 décrit l’indisponibilité temporaire du service. Une saturation générale peut justifier 503, tandis qu’une clé dépassant son budget reçoit 429.
Une réponse 429 ne doit pas être mise en cache comme une représentation normale de la ressource. Le RFC indique qu’elle ne doit pas être stockée par un cache. Vérifiez le comportement CDN, notamment lorsque le cache d’erreur est configuré globalement. Un 429 lié à un client ne doit jamais être servi à tous les suivants depuis un objet partagé.
Lire les logs par clé, route et fenêtre
Journalisez un identifiant de règle, sa version, la route normalisée, la méthode, la clé pseudonymisée, le budget, le restant avant décision, la fenêtre, la concurrence, le statut et le point d’application. Ajoutez l’identité vérifiée du robot lorsqu’elle est disponible, sans faire du User-Agent une preuve. Les valeurs sensibles restent hachées avec rotation et durée de conservation limitée.
En environnement distribué, précisez si le compteur est local au POP, partagé dans une région ou global. Un client peut contourner un quota local en touchant plusieurs points ; un compteur global peut ajouter de la latence et devenir une dépendance critique. Mesurez le retard de synchronisation. Deux nœuds qui accordent chacun dix jetons peuvent en délivrer vingt avant convergence ; ce dépassement doit être accepté ou compensé dans le budget.
Reconstituez une décision exacte à partir du log. Si l’équipe ne peut pas expliquer pourquoi une requête sentinelle a reçu 429, le système est trop opaque pour une page stratégique. Un échantillon de réponses autorisées permet de comparer. Conservez aussi le nombre de requêtes rejetées sans réponse lorsque l’attaque rend le coût d’un 429 lui-même excessif, possibilité reconnue dans les considérations de sécurité du RFC.
Le tableau de bord affiche distributions, pas uniquement totaux : clés avec le plus de refus, routes, durée jusqu’à récupération, taux de clients touchés et pourcentage d’URL distinctes. Une seule clé abusive peut créer la majorité des 429 sans affecter le crawl. À l’inverse, une règle de hostname peut toucher des milliers de clés une seule fois chacune, signe d’un budget partagé trop large.
Relier la limite à la capacité réellement protégée
Identifiez la ressource rare : CPU, workers, connexions DB, débit tiers, bande passante, mémoire ou coût financier. Mesurez le coût d’une requête par route au p50 et au p95. Un endpoint qui consomme 200 ms de base ne peut pas partager le même budget qu’un fichier statique servi au bord. Convertissez le plafond en capacité : concurrence maximale, requêtes par seconde soutenables et marge nécessaire aux pics humains.
Conservez une réserve. Si le système tient 500 requêtes coûteuses par seconde dans un test stable, ne configurez pas mécaniquement un quota total à 500. Gardez une marge pour variance, tâches internes, cache froid et défaillance d’un nœud. Par exemple, dimensionnez les budgets réguliers à 60–70 % de la capacité mesurée et réservez le reste aux rafales et au trafic prioritaire. Les chiffres dépendent du SLO et de la tolérance au risque.
Positionner le contrôle près de la ressource rare
Appliquez le contrôle au plus près de la ressource sans perdre le contexte. Le CDN peut arrêter une rafale avant le réseau, mais ignore parfois le coût applicatif réel. L’application connaît l’utilisateur et la route, mais a déjà payé TLS, proxy et parsing. Une défense à plusieurs niveaux fonctionne mieux : plafond grossier au bord, concurrence au proxy, budget par opération dans le service. Chaque niveau retourne une raison distincte.
L’instrumentation relie les entrées, les sorties et chaque dépendance à un seuil documenté. Le monitoring suit la capacité, tandis que le runbook nomme le rollback si la nouvelle limite déplace la saturation. Ce contrat fournit une preuve d’implémentation avant d’autoriser une hausse du plafond.
Le quota ne remplace pas la correction d’une URL infinie ou d’une requête lente. Si le crawl explore des filtres sans valeur, nettoyez liens, canoniques et robots.txt. Si une route effectue une requête non indexée, optimisez-la. Rate limiting protège pendant la correction ; il ne doit pas rendre acceptable une capacité artificiellement gaspillée.
Choisir fenêtre, jetons et concurrence
Adapter l’algorithme au profil du trafic légitime
Une fenêtre fixe est simple mais crée des frontières : un client peut consommer tout le budget à la fin d’une minute puis à nouveau au début de la suivante. Une fenêtre glissante lisse mieux au prix de davantage d’état. Le seau à jetons recharge progressivement et autorise une rafale bornée ; il convient souvent au crawl, qui peut arriver par groupes. Le seau fuyant régule un débit de sortie régulier. Le choix doit correspondre à la capacité et à l’expérience attendue.
Ajoutez une limite de concurrence aux opérations longues. Un client peut rester sous dix requêtes par seconde tout en occupant cent workers si chaque requête dure vingt secondes. Inversement, cent petites réponses en cache peuvent être sûres. Combinez débit, rafale et concurrence plutôt que de chercher un nombre unique. Documentez la priorité entre budgets lorsqu’une requête consomme plusieurs niveaux.
La clé détermine l’équité. L’adresse IP est accessible mais peut représenter un NAT d’entreprise, un opérateur mobile ou une infrastructure de crawl. Le compte authentifié améliore l’attribution mais ne couvre pas les pages publiques. Une clé API sert les partenaires ; une session aide les visiteurs. Pour le crawl vérifié, combinez identité, hostname et classe de route, tout en gardant un plafond global qui protège la capacité.
Contre-intuitivement, un quota plus précis peut être plus sûr qu’un plafond global plus bas. En séparant pages publiques peu coûteuses et endpoints lourds, vous autorisez davantage de découverte tout en réduisant la charge dangereuse. La complexité supplémentaire se justifie seulement si les logs et les tests permettent encore d’expliquer chaque décision.
Segmenter pages publiques, API et actions coûteuses
Créez au minimum quatre budgets. Les documents publics et assets nécessaires au rendu reçoivent une capacité protégée et bénéficient du cache. Les API de lecture coûteuses possèdent un quota par clé et par opération. Les écritures sensibles combinent authentification, idempotence et limite stricte. Les surfaces infinies comme recherche, export et filtres ont un budget de concurrence et une pagination bornée.
Les routes prioritaires sont celles qui servent la découverte, les liens internes et la conversion. Elles ne sont pas exemptes : elles disposent d’une réserve et d’un mode dégradé. Une catégorie peut servir une version cacheable ; une recherche peut réduire le nombre de filtres ; un calculateur peut afficher une estimation différée. La réponse doit conserver le statut exact et une information utile lorsque la fonction secondaire est limitée.
Les règles par User-Agent sont faciles à contourner. Utilisez-les pour l’observabilité, pas comme seule clé de confiance. Pour les partenaires, fournissez une API et un quota contractuel plutôt que de les laisser scraper les pages. Pour les robots inconnus, appliquez la politique publique fondée sur coût et comportement. Le runbook rendu JavaScript, SSR et ISR aide à identifier les ressources dont le blocage retirerait le contenu.
Traiter Googlebot sans exemption illimitée
Vérifier l’identité puis appliquer un budget compatible avec le crawl
Vérifiez Googlebot avec la procédure officielle de plages IP ou de DNS inverse et direct ; le User-Agent seul est usurpable. Une requête confirmée évite les challenges et reçoit le budget des documents publics. Elle reste soumise à la capacité du hostname et aux limites des routes coûteuses. Si Googlebot explore un espace inefficace, corrigez les URL et le maillage plutôt que d’offrir un accès illimité à une base en saturation.
Google considère 429 comme un signal de surcharge et le traite comme une erreur serveur. La documentation sur les codes HTTP et les crawlers Google indique que 5xx et 429 font temporairement ralentir le crawl, puis que la cadence remonte progressivement avec le retour des 2xx. Un taux durable de 429 peut donc retarder découverte et rafraîchissement.
En urgence, la documentation Réduire la vitesse d’exploration de Google autorise temporairement 500, 503 ou 429 pendant quelques heures ou un à deux jours. La réduction affecte le hostname, y compris des URL saines, et une utilisation prolongée peut nuire à la présence dans Search. Cette mesure protège une infrastructure critique ; elle n’est pas un réglage quotidien.
Dès que la charge baisse, cessez l’erreur volontaire et surveillez la reprise. N’attendez pas un retour instantané au volume précédent. Vérifiez pages prioritaires, 2xx, temps de réponse et capacité pendant plusieurs jours. Si le crawl reste anormal, examinez les 429 résiduels par POP, les caches, robots.txt et les espaces d’URL, avant de modifier encore le plafond.
Tester rafales, récupération et trafic distribué
Le plan de charge reproduit trois profils : débit stable sous le budget, rafale légitime et dépassement soutenu. Pour chacun, mesurez autorisations, 429, latence, ressource protégée et délai de récupération. Vérifiez que la première requête après recharge passe au moment prévu et que Retry-After reste cohérent. Une horloge désynchronisée entre nœuds peut prolonger ou raccourcir la fenêtre.
Testez plusieurs clés : une adresse, plusieurs adresses derrière un compte, plusieurs comptes derrière un NAT et un client distribué. Un botnet peut contourner un quota par IP ; un NAT peut faire bloquer des utilisateurs innocents. Le test ne cherche pas seulement la résistance maximale, mais l’équité. Mesurez le pourcentage de clients légitimes touchés au même niveau de charge.
Provoquez une perte du stockage de compteurs ou une partition régionale. Décidez si le système s’ouvre, se ferme ou bascule vers un plafond local. Pour des pages publiques, une limite locale conservatrice peut maintenir le service ; pour une API coûteuse, une ouverture illimitée peut déclencher une cascade. Le comportement de panne est un choix d’architecture à tester, pas une propriété implicite de la bibliothèque.
Enfin, rejouez les pages sentinelles avec Googlebot vérifié, User-Agent usurpé, visiteur anonyme et partenaire authentifié. Contrôlez statut, contenu, règles et ressources de rendu. Un test qui regarde uniquement la réponse principale peut manquer un 429 sur CSS, JS ou API, suffisant pour vider la page.
Déployer un nouveau quota sans effet de bord
Comparer une décision simulée avant de refuser réellement
Activez la règle en observation : calculez ce qui aurait été refusé sans changer les réponses. Analysez un cycle complet incluant pics, robots, batchs et campagnes. Corrigez les clés partagées et routes mal classées. Le rapport contient charge évitée estimée, clients touchés, pages prioritaires et faux positifs. Un mode ombre ne protège pas la production ; fixez une durée et une décision de sortie.
Passez ensuite sur une région, un POP ou 1 à 5 % des clés avec cohérence. Les seuils de rollback comprennent taux de 429 légitime, baisse de crawl utile, hausse de latence, saturation déplacée vers une autre dépendance ou réponse incorrectement cachée. Replier la version de règle doit conserver les autres protections. Le fichier de configuration précédent et la commande sont testés avant le canari.
Augmentez par paliers et observez au moins une période couvrant la recharge maximale et les batchs connus. Ne changez pas simultanément la clé, l’algorithme et tous les budgets : si le résultat dérive, la cause restera inconnue. Les migrations nécessaires peuvent être séquencées : instrumenter la nouvelle clé, activer l’algorithme à budget équivalent, puis ajuster les plafonds.
Coordonnez avec cache et autoscaling. Un quota plus permissif peut déclencher une montée de capacité trop lente ; un quota plus strict peut empêcher l’autoscaler de voir la demande réelle. Exposez demande autorisée et demande rejetée séparément. Le dimensionnement utilise le trafic souhaité, tandis que la protection se fonde sur capacité disponible et SLO.
Mesurer protection, faux positifs et reprise du crawl
Le succès comporte quatre axes. La capacité reste sous ses seuils et le p95 respecte le SLO. Les abus consomment moins de ressources. Les clients légitimes obtiennent la réponse attendue. Les pages prioritaires continuent d’être explorées et mises à jour. Une baisse du nombre total de requêtes n’est pas suffisante : elle peut représenter la perte de clients utiles plutôt qu’une protection efficace.
Suivez 429 par route et identité, proportion de clés touchées, durée de blocage, jetons restants, concurrence, CPU, DB, cache et erreurs. Pour le crawl, mesurez Googlebot vérifié, statuts, octets, pages distinctes et groupes de templates. Comparez avant/après sur des fenêtres équivalentes. Les données Search Console confirment ensuite impressions et indexation, avec leur retard habituel.
Créez une revue hebdomadaire des principales décisions et une alerte sur changement brutal. Toute exception possède propriétaire, justification et expiration. Un partenaire dont le besoin devient stable reçoit une clé et un contrat ; un plafond augmenté sans échéance devient une capacité promise. La revue transforme le rate limiting en système piloté, non en accumulation de nombres mystérieux.
La clôture d’un incident de 429 exige une fenêtre sans faux positif critique, une capacité saine sous charge, le rollback éprouvé et un crawl qui remonte progressivement. Documentez les hypothèses réfutées et les limites restantes. Si l’amélioration provient uniquement d’un trafic saisonnier plus faible, le correctif n’est pas encore prouvé.
Pour qui arbitrer équité, complexité et coût de la protection
Une clé par IP est économique mais injuste pour les NAT et faible contre un trafic distribué. Une clé authentifiée est précise mais indisponible avant connexion. Un compteur global cohérent améliore l’équité et peut ajouter latence, coût et point de panne. Choisissez par classe de route. Les documents publics tolèrent souvent un quota local avec réserve ; les opérations facturées exigent une attribution globale plus stricte.
Une forte rafale améliore la vitesse de crawl ponctuelle et peut créer une file qui dégrade les visiteurs. Un débit parfaitement lissé protège l’origine et allonge les batchs. Le seau à jetons formalise ce compromis avec capacité de rafale et vitesse de recharge. Calibrez les deux par test, puis gardez une marge. L’objectif n’est pas de satisfaire chaque client à sa cadence idéale, mais de maintenir le service utile pour tous.
Répondre 429 consomme encore réseau et calcul ; lors d’une attaque extrême, abandonner des connexions au bord peut être nécessaire. Cette réponse plus dure doit rester ciblée et observable, car elle fournit moins d’information au client et aux équipes. La défense graduée commence par cache et quotas explicites, puis passe à des mesures de protection d’urgence lorsque le coût de répondre menace le service.
Erreurs fréquentes dans une politique de quotas
- Utiliser un plafond global sans savoir quelle ressource il protège.
- Limiter toutes les routes au même débit malgré des coûts très différents.
- Faire confiance au User-Agent pour exempter un robot de toute limite.
- Confondre 429 individuel et 503 général, ou détourner 403 et 404 pour ralentir.
- Mettre en cache une réponse 429 partagée et bloquer des clients qui n’ont rien consommé.
- Augmenter le plafond sans tester concurrence, récupération et panne du compteur.
- Valider sur le volume rejeté sans mesurer faux positifs, capacité et crawl utile.
Une erreur subtile est de conserver un Retry-After fixe sans rapport avec l’algorithme. Les clients reviennent tous au même instant et recréent une pointe. Ajoutez une recharge progressive et, côté clients que vous contrôlez, un backoff avec jitter. Le serveur doit néanmoins rester protégé si le client ne respecte rien.
Questions fréquentes sur 429 et le crawl
Un 429 est-il une erreur client ou serveur pour Google ?
Sa classe HTTP est 4xx, mais Google le traite comme un signal de surcharge et une erreur serveur pour adapter le crawl. Une occurrence ponctuelle est récupérable ; un volume durable ralentit la découverte et peut finir par affecter les URL. Utilisez-le avec la sémantique de quota réel.
Faut-il exempter complètement Googlebot ?
Non. Vérifiez son identité et évitez les challenges, puis accordez un budget adapté aux pages publiques. Conservez un plafond de capacité et des limites sur les routes coûteuses. Corrigez les espaces d’URL inefficaces plutôt que de permettre une charge infinie.
Quel algorithme convient le mieux au crawl ?
Le seau à jetons offre souvent un bon compromis : débit moyen contrôlé et rafale bornée. Mais une limite de concurrence peut être indispensable pour les réponses lentes. Le choix dépend du coût de la route, de la distribution du trafic et de la cohérence nécessaire entre nœuds.
Combien de temps peut-on utiliser 429 pour ralentir Google ?
Google réserve cette tactique d’urgence à quelques heures ou un à deux jours. Au-delà, les effets sur le crawl et la présence peuvent devenir négatifs. Dès la charge maîtrisée, rendez les 2xx corrects et surveillez la remontée progressive.
Articles complémentaires à lire ensuite
Pour supprimer les espaces d’URL qui consomment inutilement la capacité, poursuivez avec le budget de crawl et l’indexation. Pour tester les règles et leurs seuils avant production, utilisez la CI/CD et la non-régression SEO technique.
La QA doit vérifier chaque route, son HTML et son canonical après revalidation ou invalidation du cache. Pour un rendu SSR, SSG ou ISR, les ressources JavaScript restent dans le même budget protégé afin que Googlebot récupère la représentation complète.
Plan d’action rate limiting en douze étapes
- Superposer trafic, 429, latence et capacité pour distinguer quota et saturation réelle.
- Segmenter par route, méthode, clé, région, identité, règle et version.
- Nommer la ressource protégée et mesurer le coût p50/p95 de chaque classe.
- Réserver une marge de capacité aux pics, pannes et parcours prioritaires.
- Choisir clé, fenêtre, rafale, recharge et concurrence selon le trafic légitime.
- Séparer documents publics, API de lecture, écritures et opérations coûteuses.
- Configurer 429 et un Retry-After cohérent sans cache partagé.
- Vérifier Googlebot officiellement et lui éviter challenge et exemption infinie.
- Tester débit stable, rafale, trafic distribué, récupération et perte du compteur.
- Observer la nouvelle décision en ombre puis la déployer sur un canari.
- Mesurer capacité, faux positifs, abus, pages distinctes et crawl utile.
- Étendre avec rollback testé, exceptions datées et revue régulière des budgets.
- À valider : la capacité reste saine et les pages prioritaires retrouvent des 2xx stables.
- À replier : le seuil de faux positifs, de latence ou de crawl utile est dépassé.
Conclusion : limiter le coût, pas la découverte utile
Un 429 n’explique pas seul une saturation. Le diagnostic relie décision, clé, fenêtre, route et ressource protégée, puis compare le plafond à la capacité réelle. Cette lecture distingue une défense utile d’une règle trop large qui bloque Googlebot sans soulager l’infrastructure.
La politique robuste segmente les coûts, autorise une rafale bornée, limite la concurrence et emploie 429 avec un Retry-After honnête. Googlebot vérifié reçoit un budget compatible avec le crawl, jamais une exemption illimitée. Le déploiement en ombre puis en canari mesure à la fois faux positifs, charge et reprise.
Pour auditer vos quotas, protéger les routes sensibles et maintenir la découverte des pages rentables, faites appel à notre expertise en SEO technique. Nous transformons les logs de rate limiting en décisions testées, réversibles et alignées sur la capacité comme sur la croissance organique.
