429 Too Many Requests
Cunoscut și ca: HTTP 429, eroare 429, cod de stare 429, prea multe cereri, 429 error, HTTP 429 Too Many Requests
Ce înseamnă 429 Too Many Requests?
Pe scurt
429 Too Many Requests este un cod de stare HTTP care arată că un client a trimis prea multe cereri într-un anumit interval. Acest mecanism este numit limitarea ratei cererilor. Răspunsul poate include antetul Retry-After, care indică perioada de așteptare înaintea unei noi încercări.
Ce indică răspunsul 429
Codul HTTP 429 Too Many Requests semnalează că un client a trimis prea multe cereri într-un anumit interval. Mecanismul este numit „rate limiting”. Serverul îi cere astfel clientului să reducă frecvența solicitărilor.
Conform RFC 6585, reprezentarea răspunsului ar trebui să explice motivul restricției. Serverul poate trimite și antetul Retry-After pentru a preciza cât trebuie să aștepte clientul înainte de a face o nouă cerere.
Un răspuns 429 nu trebuie stocat de un cache.
Cum poate fi aplicată limitarea
Standardul nu impune o singură metodă pentru identificarea utilizatorului sau numărarea cererilor. Limita poate fi stabilită pentru o anumită resursă, pentru întregul server sau pentru un grup de servere.
Identificarea poate folosi acreditările de autentificare sau un cookie cu stare. MDN menționează și aplicarea restricțiilor pe baza IP-ului clientului, a utilizatorului ori a aplicației autorizate. Implementarea exactă depinde de configurația serverului.
Diferența față de o indisponibilitate generală
429 descrie explicit o frecvență prea mare a cererilor venite de la client. Nu definește o eroare permanentă a resursei. Dacă răspunsul include Retry-After, clientul poate folosi informația pentru a stabili când să încerce din nou.
Codul face parte din clasa răspunsurilor HTTP de eroare asociate clientului. Apariția sa poate fi provocată și de un client configurat greșit, care trimite repetat aceeași solicitare într-o buclă.
De ce contează în SEO?
În SEO, răspunsurile 429 sunt relevante atunci când roboții sau instrumentele de audit trimit cereri mai repede decât permite serverul. Resursele afectate nu pot fi preluate prin cererea care primește acest răspuns.
Situația trebuie evaluată din jurnalele serverului și din configurația de rate limiting. Un răspuns 429 izolat nu demonstrează singur o problemă SEO generală. Răspunsurile repetate arată că anumite cereri sunt limitate. Serverul ar trebui să explice restricția și poate transmite Retry-After, astfel încât clientul să știe cât să aștepte înaintea unei noi încercări.
Pentru orice sistem automatizat care încearcă să preia conținut prin HTTP, principiul tehnic este similar: dacă o cerere primește 429, resursa nu este furnizată prin acea cerere. Efectul concret asupra descoperirii, preluării sau utilizării ulterioare a conținutului nu poate fi dedus doar din codul de stare.
În GEO și optimizarea pentru LLM, termeni folosiți în industrie, obiectivul practic este menținerea unui acces HTTP stabil, fără eliminarea necontrolată a protecțiilor. Regulile trebuie analizate separat pentru fiecare tip de client și resursă.
Exemplu
Un magazin online din România are un endpoint pentru rapoarte. O integrare configurată greșit îl solicită repetat într-o buclă. Serverul activează limitarea și răspunde astfel:
HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
<html lang="ro">
<head><title>Prea multe cereri</title></head>
<body>
<p>Ai trimis prea multe cereri. Încearcă din nou mai târziu.</p>
</body>
</html>
Antetul Retry-After îi comunică aplicației cât trebuie să aștepte înaintea unei noi încercări. Aplicația ar trebui să oprească bucla și să țină cont de perioada indicată.
Cum verifici?
- Solicită URL-ul cu
curl -I https://exemplu.ro/resursași verifică statusul HTTP. - Dacă primești 429, caută antetul Retry-After și mesajul care explică restricția.
- Verifică jurnalele serverului pentru clientul, resursa și succesiunea de cereri asociate răspunsurilor 429.
- Analizează configurația de rate limiting pentru a vedea dacă regula se aplică unei resurse, întregului server sau unui grup de servere.
- Dacă răspunsul conține Retry-After, repetă testul după perioada indicată, fără a genera o buclă de cereri.
- Într-un audit tehnic, urmărește răspunsurile 429 observate în timpul accesării site-ului.
Ce trebuie să faci?
- Include în răspuns o explicație clară a restricției.
- Trimite Retry-After atunci când serverul poate comunica perioada de așteptare.
- Configurează clientul să reducă frecvența cererilor și să țină cont de Retry-After.
- Oprește buclele sau integrările care repetă necontrolat aceeași solicitare.
- Verifică dacă limitarea este aplicată la nivelul potrivit: resursă, server sau grup de servere.
- Nu permite stocarea răspunsurilor 429 de către cache.
Greșeli frecvente
- Interpretarea codului 429 ca dovadă a unei indisponibilități permanente a resursei.
- Retrimiterea imediată și repetată a cererii fără a ține cont de antetul Retry-After.
- Aplicarea unei limite fără un mesaj care să explice motivul restricției.
- Presupunerea că standardul impune o anumită metodă de identificare a clientului.
- Stocarea răspunsului 429 într-un cache.
Perspectiva SEO 365
Verificăm mai întâi jurnalele serverului și regulile de rate limiting. Nu eliminăm automat protecția, ci analizăm configurarea acesteia astfel încât clienții legitimi să poată accesa resursele fără a genera cereri necontrolate. Evităm tratarea exclusivă a simptomului și verificăm buclele sau integrările care produc traficul repetitiv.