Kod 429 Too Many Requests to odpowiedź HTTP, w której serwer informuje, że klient wysłał w danym czasie zbyt wiele żądań, i tymczasowo odmawia obsłużenia kolejnych (RFC 6585). Pojawia się przy limitach zewnętrznych API, regułach zapory hostingu lub CDN, agresywnych botach, a także przy własnych hurtowych pomiarach strony. Formalnie to kod klasy 4xx, ale Google traktuje go jak błąd serwera i po takiej odpowiedzi zwalnia crawlowanie witryny.
Co oznacza kod 429 i skąd wzięła się nazwa Too Many Requests?
Kod 429 mówi tyle: zasób istnieje i serwer działa, ale ten konkretny klient wysyła za dużo żądań w danym czasie, więc musi odczekać. Standard RFC 6585 (sekcja 4) definiuje go jako odpowiedź na przekroczenie limitu, a sam mechanizm nazywa rate limiting, po polsku limitowaniem żądań.
Limit liczy się zwykle na adres IP, sesję, klucz API albo konto, na przykład 100 zapytań na minutę z jednego IP. Po przekroczeniu progu serwer nie przetwarza żądania, tylko odsyła kod 429, a po upływie okna limitu znów odpowiada normalnie. Według RFC 6585 odpowiedź powinna wyjaśniać, jaki warunek został naruszony, i może zawierać nagłówek Retry-After z czasem oczekiwania; w przykładzie ze standardu jest to Retry-After: 3600, czyli godzina.
To jedyny kod z klasy 4xx, który zależy od tempa, a nie od samego żądania, dlatego ten sam adres pobrany minutę później odpowiada już kodem 200. O zwróceniu kodu 429 decyduje serwer, aplikacja albo pośrednik przed nimi, przez co właściciele stron często biorą go za błąd serwera, choć formalnie jest to błąd klienta.
Czym różni się kod 429 od błędu 404 i od błędów 5xx?
Błąd 404 oznacza, że zasobu nie ma pod podanym adresem. Błędy serwera 5xx mówią, że serwer nie obsłużył żądania z własnej winy, a kod 429 – że zasób jest na miejscu i serwer działa, tylko klient przekroczył limit tempa. Różnice zestawia tabela.
| Błąd 404 | Kod 429 | Błąd 503 | |
|---|---|---|---|
| Klasa kodu | 4xx (błąd żądania) | 4xx (błąd żądania) | 5xx (błąd serwera) |
| Co mówi serwer | Zasobu nie ma pod tym adresem | Zasób jest, ale klient wysłał za dużo żądań w danym czasie | Serwer chwilowo nie może obsłużyć żądania (przeciążenie lub konserwacja) |
| Czy mija samo | Nie, do naprawy linku lub przekierowania | Tak, po odczekaniu okna limitu (Retry-After) | Tak, gdy serwer odzyska zasoby |
| Kogo dotyczy | Jednego adresu, każdego odwiedzającego | Jednego klienta (IP, sesja, klucz), reszta odwiedzających widzi stronę | Zwykle wszystkich odwiedzających |
| Jak reaguje Google | Jak na każdy inny błąd 4xx: adres uznaje za nieistniejący | Jak na błąd serwera: tymczasowo zwalnia crawlowanie | Jak na błąd serwera: tymczasowo zwalnia crawlowanie |
W praktyce różnica sprowadza się do tego, co jest nie tak. Przy błędzie 404 problem tkwi w konkretnym adresie i naprawia się go przekierowaniem albo poprawą linku. Przy kodzie 429 adres jest w porządku, a zawodzi tempo żądań jednego klienta, więc pomaga zmiana limitu albo zachowania tego, kto go przekracza. Z kodem 503 łączy 429 to, że oba są tymczasowe, a dzieli adresat: 503 mówi „serwer nie ma teraz zasobów dla nikogo”, a 429 – „ty wysyłasz za dużo, inni są obsługiwani”.
Skąd bierze się kod 429 na stronie?
Kod 429 zwraca zawsze jakiś limiter, a stoi on po jednej z dwóch stron: albo w zewnętrznej usłudze, do której witryna wysyła zapytania, albo we własnym serwerze lub CDN, który ogranicza ruch przychodzący. W WordPressie najczęściej spotykane źródła to:
- Zewnętrzne API: dostawca płatności, map, poczty albo kursów walut ma własny limit zapytań; gdy strona lub wtyczka wysyła ich za dużo w krótkim czasie, dostaje od niego kod 429 i funkcja przestaje działać.
- Zapora, CDN i hosting współdzielony: Cloudflare, LiteSpeed i podobni pośrednicy bronią się przed nadmiernym ruchem i botami, licząc żądania na adres IP albo sesję; zbyt niski próg trafia jednak także w zwykłych użytkowników.
- Wtyczka WordPressa: działa w obie strony. Dodatek do synchronizacji, powiadomień albo analityki sam dostaje 429 od zewnętrznego API, bo odpytuje je za często; z kolei wtyczka bezpieczeństwa albo cache nakłada własny limit i zaczyna zwracać 429 realnym użytkownikom.
- Boty i scrapery: agresywne crawlowanie przez źle napisanego bota, narzędzie konkurencji albo własny skrypt uruchamia ochronę hostingu, a ta odpowiada kodem 429 na cały ruch z danego adresu.
- Testy i monitoring: hurtowe, równoległe sprawdzanie wielu adresów naraz też przekracza limit, więc narzędzie raportuje 429, mimo że strona dla ludzi działa poprawnie.
Jak Google traktuje kod 429 przy crawlowaniu?
Google w dokumentacji Search Central pisze, że jego roboty odbierają kod 429 jako sygnał przeciążenia i klasyfikują go jako błąd serwera. Wszystkie inne błędy 4xx dokumentacja opisuje tak samo, a 429 jest od tej reguły jedynym wyjątkiem. Po odpowiedziach 5xx i 429 roboty Google tymczasowo zwalniają crawlowanie, a gdy błąd utrzymuje się dłużej, adresy mogą wypaść z indeksu.
Ta sama dokumentacja, na stronie o zmniejszaniu tempa crawlowania, dopuszcza świadome użycie kodu 429. Gdy serwer nie wytrzymuje ruchu robota, można na kilka godzin albo 1-2 dni zwracać Googlebotowi kod 500, 503 lub 429 zamiast 200. Google ostrzega jednak, żeby nie przeciągać tego ponad 1-2 dni, bo robot, który przez dłuższy czas widzi te kody pod tym samym adresem, może usunąć go z indeksu.
Skutki dłuższego blokowania wykraczają poza pojedyncze adresy. Google odkrywa mniej nowych stron, rzadziej odświeża istniejące (na przykład ceny i dostępność produktów) i wolniej usuwa z indeksu te, które już skasowano. Ile adresów robot pobiera z witryny w danym czasie i od czego to zależy, wyjaśnia wpis o tym, co to jest crawl budget.
Jak wygląda kod 429 w praktyce i dlaczego bywa niewidoczny?
Kod 429 nie zawsze kończy się stroną błędu. Gdy limiter odrzuca tylko część żądań, na przykład o pliki CSS, JavaScript i obrazy, a dokument HTML zwraca poprawnie, strona ładuje się jako goły tekst bez stylów i grafik, czyli wygląda jak zepsuta, choć serwer działa.
Przekonaliśmy się o tym na własnej skórze przy pomiarach stron naszych klientów. Skrypt sprawdzał wiele podstron naraz, przez iframe i curl, bez odstępu między żądaniami. Po chwili strony na hostingu seohost z serwerem LiteSpeed zaczęły wyglądać, jakby nie wczytał się arkusz stylów: surowy HTML, brak układu, brak obrazów. Pierwsza myśl była taka, że to błąd we wdrożeniu CSS. W rzeczywistości LiteSpeed odpowiadał kodem 429 na część żądań, akurat tych o arkusze stylów i obrazy, bo nasz własny pomiar przekroczył limit dla jednego adresu. Strona dla zwykłych odwiedzających działała cały czas.
Z tego doświadczenia wynikają dwie zasady. Po pierwsze, zanim uznasz, że zepsuł się frontend, sprawdź kolumnę Status w zakładce Network narzędzi deweloperskich albo wykonaj curl -I na konkretny plik CSS; kod 429 przy pojedynczych zasobach rozstrzyga sprawę. Po drugie, własne pomiary i testy strony rób pojedynczo, z odstępem czasu, bo w przeciwnym razie sam wywołujesz limit, który potem diagnozujesz.
Strona wygląda na zepsutą tylko czasem, a hosting mówi, że wszystko działa?
Napisz do nas, sprawdzimy, czy serwer odrzuca część żądań kodem 429, i podpowiemy, co zmienić w limitach.
Jak sprawdzić, czy strona zwraca kod 429?
Kod 429 sprawdzisz na trzy sposoby: poleceniem curl -I dla adresu lub pliku, zakładką Network w narzędziach deweloperskich Chrome oraz raportem Statystyki indeksowania w Google Search Console. Każdy z nich pokazuje inny wycinek.
Polecenie curl -I z adresem strony zwraca nagłówki odpowiedzi; pierwsza linia pokaże HTTP/2 429. Jeśli serwer wysyła nagłówek Retry-After, zobaczysz w nim liczbę sekund albo datę, po której można ponowić żądanie. Część serwerów i CDN dopisuje też własne pozycje, na przykład Cloudflare cf-ray; po nich poznasz, gdzie zapadła decyzja o odrzuceniu.
W Chrome klawisz F12 otwiera narzędzia deweloperskie, a zakładka Network (Sieć) pokazuje każde żądanie strony osobno z kodem w kolumnie Status. To jedyne miejsce, w którym widać, że kod 429 dostał konkretny plik CSS albo obraz, a nie cały dokument, czyli dokładnie przypadek z naszego przykładu.
Google Search Console pokazuje, co widzi Googlebot: w raporcie Statystyki indeksowania (Ustawienia → Statystyki indeksowania), w sekcji „Według odpowiedzi”, pojawia się wiersz z kodem 429, jeśli robot go dostawał. Narzędzia lokalne pokazują stan z tej chwili, a raport w Search Console zbiera historię żądań robota, dlatego limit, który uruchamia się tylko przy większym ruchu, zobaczysz właśnie tam. Samemu raportowi poświęciliśmy osobny wpis: Jak czytać raport Statystyki indeksowania w GSC.
Co zrobić, gdy strona zwraca kod 429?
Najpierw ustal, kto komu odmawia: czy to strona dostaje 429 od zewnętrznego API, czy własny serwer lub CDN blokuje użytkowników i roboty. Dopiero od tego zależy reakcja:
Zidentyfikuj źródło
Log błędów, kolumna Status w zakładce Network i nagłówki odpowiedzi pokazują, który zasób dostał kod 429 i kto go zwrócił.
Wtyczka dostaje 429 od zewnętrznego API
Sprawdź limity w dokumentacji dostawcy, zmniejsz częstotliwość zapytań wtyczki (dłuższy interwał synchronizacji, cache odpowiedzi), zaktualizuj ją albo wyłącz, jeśli odpytuje API bez potrzeby.
Użytkownicy lub roboty dostają 429 od własnego serwera lub CDN
Przejrzyj reguły zapory i limitera w panelu Cloudflare albo hostingu, podnieś próg dla zwykłego ruchu i wyklucz zaufane adresy, w tym własne narzędzia pomiarowe i Googlebota. Konfiguracja limitera w WordPressie krok po kroku to temat na osobną instrukcję.
Chcesz świadomie spowolnić Googlebota
W awaryjnej sytuacji kod 429 jest jedną z trzech dopuszczalnych opcji obok 500 i 503, ale maksymalnie na 1-2 dni. Po tym czasie serwer musi znów zwracać 200, bo inaczej adresy wypadają z indeksu.
Skontaktuj się z hostingiem
Gdy próg jest zaszyty w infrastrukturze (pakiet współdzielony, zapora operatora) i nie widać go w Twoich ustawieniach, tylko dostawca może go zmienić albo wyjaśnić, który ruch go uruchamia.
Kod 429 przy sprawnej stronie jest sygnałem o tempie, nie o awarii, więc wyłączanie wtyczek na oślep rzadko coś daje. Pomaga dopiero ustalenie, kto wysyła żądania i który limiter je odrzuca.
Jakie pojęcia wiążą się z kodem 429?
- Rate limiting (limit żądań): mechanizm, który liczy żądania z jednego źródła w oknie czasu i po przekroczeniu progu odpowiada kodem 429 zamiast treści.
- Retry-After: nagłówek HTTP w odpowiedzi 429 lub 503, który podaje liczbę sekund albo datę, po której można ponowić żądanie; według RFC 6585 przy kodzie 429 jest opcjonalny.
- WAF (zapora aplikacji): filtr przed serwerem, który odrzuca ruch uznany za niebezpieczny lub nadmierny; jego reguły są częstym źródłem kodu 429 dla użytkowników i robotów.
- CDN: sieć serwerów pośredniczących (na przykład Cloudflare), która serwuje stronę bliżej odwiedzającego i zwykle ma własny limiter żądań niezależny od hostingu.
- Błąd 503: tymczasowa niedostępność dla wszystkich odwiedzających z powodu przeciążenia lub konserwacji; dla Googlebota działa tak samo jak 429, ale dotyczy całego serwera, nie jednego klienta.
- Crawl budget: liczba adresów, które robot Google pobiera z witryny w danym czasie; odpowiedzi 429 obniżają ją tak samo jak błędy 5xx.
Widzisz kod 429 w Search Console albo w logach po wdrożeniu nowej wtyczki?
Napisz do nas, ustalimy, skąd bierze się limit, i zadbamy, żeby Googlebot nie zwalniał na Twojej stronie.
FAQ
Formalnie to błąd klienta, bo należy do klasy 4xx i oznacza, że klient wysłał za dużo żądań. O jego zwróceniu decyduje jednak serwer albo pośrednik, a Google traktuje go jak błąd serwera i po takiej odpowiedzi tymczasowo zwalnia crawlowanie.
Krótkotrwały kod 429 nie zmienia pozycji, bo Google zachowuje zaindeksowane adresy i tylko zwalnia crawlowanie. Ryzyko rośnie, gdy robot dostaje 429 na tych samych adresach dłużej niż 1-2 dni: wtedy może usuwać je z indeksu, a witryna traci widoczność do czasu ponownego zindeksowania.
Kod 503 pasuje, gdy serwer nie ma zasobów dla nikogo albo trwa przerwa techniczna, a 429, gdy konkretny klient przekroczył limit i reszta ruchu jest obsługiwana. Dla Googlebota oba kody działają tak samo: sygnalizują przeciążenie i są bezpieczne tylko w oknie 1-2 dni.
Retry-After to nagłówek HTTP, którym serwer podaje, po ilu sekundach albo od jakiej daty klient może ponowić żądanie; w przykładzie z RFC 6585 ma wartość 3600, czyli godzinę. Przy kodzie 429 standard opisuje go jako opcjonalny, więc jego brak nie oznacza błędu konfiguracji.
Tak, na tym właśnie polega limiter w zaporze lub CDN: kto przekroczy próg, ten dostaje 429. Przy Googlebocie dokumentacja Google dopuszcza to tylko awaryjnie, na kilka godzin albo 1-2 dni, a limity dla botów trzeba ustawić tak, żeby nie obejmowały własnych narzędzi i zwykłych użytkowników.
Źródła
- RFC 6585 „Additional HTTP Status Codes”, sekcja 4 „429 Too Many Requests”: rfc-editor.org/rfc/rfc6585
- Google Search Central, „Kody stanu HTTP oraz błędy sieci i DNS”: developers.google.com
- Google Search Central, „Reduce Googlebot crawl rate”: developers.google.com
