Błąd 429 (Too Many Requests)

Jak wygląda

Odpowiedź serwera albo warstwy pośredniej z limitem:

HTTP/1.1 429 Too Many Requests

Retry-After: 120

Wiele usług dodaje własne nagłówki z informacją o limicie, na przykład:

X-RateLimit-Limit: 100

X-RateLimit-Remaining: 0

W nginx limit żądań ustawia się modułem limit_req, a kod odpowiedzi po przekroczeniu limitu wskazuje dyrektywa:

limit_req_status 429;

Dla robotów wyszukiwarek zwykle robi się wyjątek, bo celem limitu jest ochrona przed nadużyciami, a nie blokowanie indeksowania.

Jak traktuje to Google

Według dokumentacji o kodach stanu (jak kody HTTP wpływają na roboty Google) roboty Google traktują 429 jako sygnał, że serwer jest przeciążony, i uznają go za błąd serwera. To jedyny kod 4xx z takim wyjątkiem: pozostałe błędy 4xx oznaczają, że treści nie ma, i nie wpływają na szybkość skanowania. Dla 5xx i 429 obowiązuje inna zasada: roboty mają na jakiś czas zwolnić, zindeksowane adresy zostają w indeksie, ale po jakimś czasie są usuwane, a treść odpowiedzi jest ignorowana.

Dokument o hamowaniu robota (zmniejszanie szybkości indeksowania) opisuje mechanizm dokładniej. Gdy infrastruktura Google napotka znaczną liczbę adresów z kodami 500, 503 lub 429, zmniejsza szybkość skanowania całej nazwy hosta, łącznie z adresami, które odpowiadają poprawnie. Gdy liczba błędów spadnie, tempo samo rośnie. Przy 429 można dołączyć nagłówek Retry-After z liczbą sekund albo datą UTC. Google dopuszcza tę metodę jako awaryjne hamowanie na kilka godzin lub 1-2 dni i ostrzega, że po kilku dniach takich odpowiedzi pod tymi samymi adresami może usunąć je z indeksu.

Ten sam dokument zabrania używać kodów 401 i 403 do ograniczania szybkości skanowania. Przewodnik o budżecie (optymalizacja budżetu indeksowania) wymienia sygnały ograniczania szybkości, w tym HTTP 429, obok błędów 5xx jako powód obniżenia limitu wydajności skanowania. Więcej o tym limicie w haśle o crawl budget.

Kiedy ma znaczenie

• CDN albo WAF z ochroną przed botami, która liczy żądania Googlebota jak każdego innego klienta,
• limit żądań na adres IP, gdy Google skanuje z wielu adresów naraz, ale z jednego zakresu,
• sklep z nawigacją fasetową, gdzie robot generuje tysiące żądań o filtry i trafia w limit,
• API albo wyszukiwarka wewnętrzna z własnym limitem, do której prowadzą linki z szablonu,
• hosting współdzielony z limitem połączeń na konto.

Dokument o zmniejszaniu szybkości skanowania wskazuje, że nagły wzrost ruchu robota często wynika z nieefektywnej struktury adresów: nawigacji fasetowej, sortowania i filtrowania albo kalendarza z osobnymi adresami dla każdej daty (zmniejszanie szybkości indeksowania). Zanim podniesiesz limit, sprawdź, czy robot nie krąży po adresach, które powinny być zablokowane w pliku robots.txt.

Najczęstsze błędy

Jak sprawdzić

W logach serwera i CDN odfiltruj odpowiedzi z kodem 429 i sprawdź, czy wśród klientów jest Googlebot. Adres IP zweryfikuj zgodnie z dokumentacją (weryfikacja żądań Googlebota), bo sama nazwa klienta użytkownika niczego nie dowodzi.

Z linii poleceń odtwórz serię żądań i obejrzyj nagłówki pierwszej odpowiedzi z 429:

for i in $(seq 1 50); do curl -s -o /dev/null -w "%{http_code}\n" https://example.com/kategoria/; done

curl -I https://example.com/kategoria/

W nagłówkach szukaj Retry-After, nagłówków z limitem oraz nazwy warstwy, która odpowiedziała. Odpowiedź od CDN albo zapory wygląda inaczej niż odpowiedź z aplikacji.

W Search Console raport Statystyki indeksowania (raport Statystyki indeksowania) pokazuje odpowiedzi na żądania robota według kodu i stan hosta, więc widać, czy 429 trafia w Googlebota i od kiedy. Adresy z tym kodem w raporcie Indeksowanie stron lądują jako URL jest zablokowany z powodu innego błędu 4xx. Jeśli 429 pojawia się w środku łańcucha przekierowań, sprawdzarka przekierowań wypisze kod każdego kroku. Opis wszystkich kodów i ich wpływu na indeksowanie znajdziesz w haśle o kodach odpowiedzi HTTP.

Monitorowanie

IndexRise co noc pobiera monitorowane adresy i zapisuje kod odpowiedzi. 429 traktujemy jako odmowę sprawdzenia, a nie błąd strony: adres zachowuje ostatni znany stan i jest oznaczony jako „nie udało się sprawdzić”, a projekt pokazuje, że zabezpieczenie serwisu nie wpuszcza monitoringu. Zamiast ponawiać mocniej, zwalniamy. Jeśli 429 powtarza się noc po nocy, limit trafia też w Googlebota i trzeba go poprawić, zanim raport Statystyki indeksowania pokaże spadek.