429 Zbyt wiele żądań

TL;DR — 429 Too Many Requests oznacza, że serwer powiedział odwiedzającemu lub botowi: „wysyłasz zbyt wiele stron zbyt szybko — zwolnij”. Nazywa się to ograniczaniem szybkości (rate limiting). Dobra wiadomość dla SEO: 429 jest jedynym błędem w tej rodzinie, który Google obsługuje łagodnie. Zamiast usuwać strony, Googlebot po prostu na pewien czas zwalnia i crawluje witrynę wolniej. Problem pojawia się dopiero wtedy, gdy serwer wysyła 429 przez wiele dni z rzędu.

Co naprawdę oznacza 429

Za każdym razem, gdy przeglądarka, skrypt lub crawler wyszukiwarki prosi serwer o stronę, serwer odpowiada kodem stanu. 200 oznacza „oto strona”. 429 oznacza: „wysłano zbyt wiele żądań w krótkim czasie, więc na to żądanie nie odpowiem — wróć później”.

Serwery używają 429 celowo, aby się chronić. Jeśli jeden odwiedzający (lub bot) bombarduje witrynę tak szybko, że spowalnia ją wszystkim pozostałym, zwrócenie 429 jest komunikatem: przestań na chwilę. Dobrze zachowująca się odpowiedź 429 zawiera także nagłówek Retry-After — informację, ile sekund klient ma odczekać przed ponowną próbą. Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

Dlaczego 429 jest „przyjaznym” błędem dla SEO

To część, która zaskakuje wiele osób. 429 należy do grupy „błędów klienta 4xx”, obok kodów takich jak 403 Forbidden i 404 Not Found. Te dwa kody są złym sygnałem, jeśli Google widzi je stale — Google ostatecznie usuwa takie strony z wyników wyszukiwania.

429 jest wyjątkiem. Google odczytuje 429 jako komunikat “server overloaded, slow down” (tłumaczenie) „serwer jest zajęty, zwolnij” — tak samo jak błąd serwera 503 lub 500. Zamiast usuwać strony, Googlebot przez pewien czas crawluje witrynę wolniej. Google wręcz zaleca 429 jako właściwy sposób spowolnienia crawlera i wyraźnie ostrzega przed używaniem do tego 403 lub 404. Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Kiedy 429 staje się problemem

Pojedyncze 429 od czasu do czasu jest całkowicie normalne i samo się naprawia — gdy serwer przestanie je wysyłać, Google samoczynnie przyspieszy crawlowanie. Nie trzeba o to prosić.

Niebezpieczne jest utrzymywanie się odpowiedzi 429. Jeśli Googlebot przez więcej niż dzień lub dwa nadal otrzymuje 429 dla tych samych stron, Google może zacząć usuwać je z indeksu — z perspektywy Google wygląda to tak, jakby witryna była zepsuta i niedostępna przez wiele dni. 429 jest więc narzędziem krótkoterminowym, a nie ustawieniem stałym.

Co należy z tym zrobić

• Jeśli nie zamierzałeś wysyłać 429 (pojawiają się niespodziewanie w Google Search Console lub narzędziu do crawlowania), coś ogranicza szybkość zbyt agresywnie — często jest to wtyczka bezpieczeństwa, zapora (WAF) albo hosting/CDN. Znajdź tę warstwę i poluzuj limit, aby przestała blokować prawdziwe wyszukiwarki.
• Jeśli zamierzałeś je wysyłać — na przykład serwer jest mocno obciążony — to w porządku, ale ogranicz czas działania i dodaj nagłówek Retry-After. Wyłącz tę regułę w ciągu dnia lub dwóch.

Chcesz poznać konfigurację serwera, dokładne sformułowania Google i mity, które często są powtarzane? Przejdź do karty Advanced.

TL;DR — 429 jest jedynym kodem 4xx, który Google traktuje jak 5xx: gdy napotka znaczną liczbę odpowiedzi 500/503/429, odczytuje to jako sygnał przeciążenia serwera i ogranicza szybkość crawlowania Googlebota w obrębie całego hosta, zamiast usuwać treści. To jedyny kod, który Google aprobuje do spowalniania crawlera — nigdy 403 ani 404. Dokumentacja Google podaje wskazówkę dla sytuacji awaryjnych: “a couple of hours, or 1–2 days” (tłumaczenie) „kilka godzin lub 1–2 dni” — nie gwarantuje jednak bezpiecznego okna. Utrzymujące się 429 dla tych samych adresów URL mogą ostatecznie doprowadzić do ich usunięcia z indeksu, a ograniczenie zaczyna ponownie rosnąć (niekoniecznie natychmiast ani w pełni), gdy liczba błędów spada. RFC 6585 mówi, że 429 SHOULD wyjaśniać warunek i MAY zawierać Retry-After — jego wysłanie jest zalecaną praktyką, a nie wymogiem zgodności. Ograniczenie przypisz do właściwego ruchu i zweryfikuj tożsamość crawlera przed dodaniem wyjątków.

Czym jest 429 na poziomie protokołu

Wprost ze specyfikacji, w ujęciu MDN: “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (tłumaczenie) „Kod odpowiedzi klienta HTTP 429 Too Many Requests oznacza, że klient wysłał zbyt wiele żądań w określonym czasie. Ten mechanizm proszenia klienta o spowolnienie tempa żądań nazywa się zwykle ograniczaniem szybkości.” Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

RFC 6585 §4 jest dokładniejszy niż większość jego skrótowych opisów. Reprezentacja 429 SHOULD wyjaśniać warunek i MAY zawierać nagłówek Retry-After, podający klientowi konkretną liczbę sekund (RFC 9110 dopuszcza także datę HTTP), które należy odczekać przed ponowieniem — Retry-After jest zalecaną praktyką, a nie wymogiem zgodności. Specyfikacja nie definiuje też, jak identyfikować klienta ani jak zliczać żądania; pozostawia to wystawcy odpowiedzi (na przykład według adresu IP, sesji, klucza API lub zasobu — to polityka implementacji, nie protokołu). Jest jeszcze jedna łatwa do przeoczenia reguła: RFC 6585 mówi, że odpowiedź 429 nie może być przechowywana przez cache. Jeśli zdrowe źródło zwraca odpowiedź 429 wyglądającą na zcache’owaną lub odtworzoną, problem dotyczy pośrednika (CDN, proxy), a nie ponownego ograniczenia przez źródło.

Zawsze ujmowałem to prosto w swoim poradniku o kodach stanu HTTP i ich wpływie na SEO: 429 to “a form of rate-limiting to protect the server because the client sent too many requests to the server too fast.” (tłumaczenie) „forma ograniczania szybkości, która chroni serwer, ponieważ klient wysłał do niego zbyt wiele żądań zbyt szybko.” Formalnie jest to błąd klienta — klient zrobił coś nieprawidłowego, żądając zbyt wiele. Właśnie tutaj opowieść SEO odchodzi od ujęcia specyfikacji.

Jedyny wyjątek wśród kodów 4xx

Najważniejszy fakt na tej stronie jest taki: Google nie traktuje 429 tak jak reszty rodziny 4xx. Gary Illyes napisał o tym cały wpis na blogu Google Search Central w lutym 2023 r., ponieważ wystarczająco wiele witryn i CDN-ów niewłaściwie używało 404 do ograniczania Googlebota, więc Google musiało powiedzieć im, aby przestali.

Jego zasada brzmi: “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (tłumaczenie) „Jedynym wyjątkiem jest 429, który oznacza zbyt wiele żądań. Ten błąd wyraźnie sygnalizuje każdemu poprawnie działającemu robotowi, w tym naszemu ukochanemu Googlebotowi, że musi zwolnić, ponieważ przeciąża serwer.” Z drugiej strony, w referencji kodów stanu Google czytamy: “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (tłumaczenie) „Nie używaj kodów 401 i 403 do ograniczania szybkości crawlowania. Kody 4xx, z wyjątkiem 429, nie wpływają na szybkość crawlowania.”

W tym samym momencie, gdy 403 i 404 mogą spowodować usunięcie treści z wyszukiwarki, 429 powoduje tymczasowe spowolnienie. Google zalicza go dosłownie do błędów serwera: “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (tłumaczenie) „Crawlery Google traktują kod 429 jako sygnał przeciążenia serwera i jest on uznawany za błąd serwera.” Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

To sprawia, że 429 jest użytecznym odpowiednikiem 503 Service Unavailable (tradycyjnego sygnału konserwacji lub tymczasowej niedostępności) — i dokładnym przeciwieństwem 403 Forbidden, który jest niewłaściwym narzędziem do ograniczania szybkości, mimo że wiele zapór domyślnie go używa.

Wpływ na szybkość crawlowania obejmuje cały host — po przekroczeniu progu

Mieszają się tu dwa różne zakresy, więc warto je rozdzielić. To, jak Ty zliczasz i kluczujesz limit — według adresu IP, sesji, klucza API, zasobu czy serwera — jest Twoją polityką; specyfikacja HTTP tego nie definiuje. To, co Google robi z błędami, które obserwuje, jest odrębnym, udokumentowanym zachowaniem zależnym od wolumenu, a nie od pojedynczej odpowiedzi: “Google’s crawling infrastructure reduces your site’s crawling rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.” (tłumaczenie) „Infrastruktura crawlująca Google zmniejsza szybkość crawlowania witryny, gdy napotyka znaczną liczbę adresów URL z kodami odpowiedzi HTTP 500, 503 lub 429.” Po osiągnięciu tego progu “the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.” (tłumaczenie) „Zmniejszona szybkość crawlowania obejmuje cały host, zarówno adresy URL zwracające błędy, jak i te zwracające treść.”

Innymi słowy, jeśli przy rzeczywistym wolumenie zwrócisz 429 dla części stron (na przykład ciężkiej ścieżki API), Googlebot zwolni crawlowanie całego hosta — także stron, które nadal zwracają 200. Zwykle właśnie o to chodzi, gdy celem jest zmniejszenie całkowitego obciążenia. Jednak pojedyncza odpowiedź 429 na jednej ścieżce sama w sobie nie ustanawia efektu obejmującego cały host — własne sformułowanie Google mówi o “a significant number” (tłumaczenie) „znacznej liczbie” odpowiedzi błędów, a nie o jednej odpowiedzi. Evidence for this claim When Google encounters a significant number of 500, 503, or 429 responses, its documented crawl-rate reduction affects the whole hostname, including error URLs and URLs still returning content; one isolated 429 does not establish that site-wide effect. Scope: hostname crawl-load incidents Confidence: high · Verified: 2026-07-16 Reduce Google crawl rate

Wskazówka 1–2 dni — kiedy 429 staje się ryzykowny

429 jest sygnałem krótkoterminowym, a Google podaje dla niego konkretną wskazówkę dotyczącą sytuacji awaryjnych — nie gwarantowane bezpieczne okno ani twardą granicę. W dokumentacji „reduce crawl rate” czytamy: “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (tłumaczenie) „Jeśli pilnie potrzebujesz krótkotrwale zmniejszyć szybkość crawlowania, na przykład przez kilka godzin lub 1–2 dni, zwróć dla żądań crawlowania kod 500, 503 lub 429 zamiast 200.”

Przekroczenie tego czasu oznacza większe ryzyko, choć Google opisuje je jako możliwość, a nie obietnicę: “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” (tłumaczenie) „Nie zalecamy robić tego przez długi czas, czyli dłużej niż 1–2 dni, ponieważ może to negatywnie wpłynąć na wygląd witryny w produktach Google; jeśli Googlebot obserwuje te kody dla tego samego adresu URL przez wiele dni, adres może zostać usunięty z indeksu Google.” Referencja kodów stanu mówi to samo o 5xx i 429 razem: “already indexed URLs are preserved in the index, but eventually dropped.” (tłumaczenie) „Adresy URL już zindeksowane pozostają w indeksie, ale ostatecznie są usuwane.”

Uczciwie ujęty model ryzyka jest taki: krótkotrwały 429 mieści się w oknie zalecanym przez Google dla użycia awaryjnego; utrzymujący się 429 dla tych samych adresów URL przez wiele dni to moment, gdy własne sformułowania Google przechodzą w „może” i „ostatecznie usunięty” — udokumentowane ryzyko, a nie gwarantowany wynik w żadną stronę. To ta sama dynamika co przy przedłużającym się 503.

Szybkość crawlowania odzyskuje się automatycznie

Uspokajająca druga strona: po witrynie nie ciągnie się żadna flaga kary. Gdy liczba błędów spadnie, Google mówi, że “the crawl rate will automatically start increasing again.” (tłumaczenie) „Szybkość crawlowania automatycznie zacznie ponownie rosnąć.” Nie trzeba niczego zgłaszać ani ponownie prosić o crawlowanie. Zwróć jednak uwagę na dokładne sformułowanie — Google mówi “starts increasing,” (tłumaczenie) „zaczyna rosnąć”, a nie “instantly returns to your prior rate.” (tłumaczenie) „natychmiast wraca do poprzedniej szybkości”. Traktuj odzyskiwanie jako udokumentowany kierunek bez ustalonego harmonogramu i gwarantowanego punktu końcowego, a nie jako SLA. Evidence for this claim Google says crawl rate automatically starts increasing after the number of overload responses falls; this describes direction, not an immediate return, fixed recovery time, or guaranteed prior crawl rate. Scope: hostname crawl-load incidents Confidence: high · Verified: 2026-07-16 Reduce Google crawl rate

(Dla kontrastu istnieje problem odwrotny — chcesz, aby Google na stałe crawlowalo Cię mniej. Jeśli wysyłanie błędów nie jest możliwe, Google mówi, aby “file a special request to report a problem with unusually high crawl rate” (tłumaczenie) „złożyć specjalne zgłoszenie problemu z niezwykle wysoką szybkością crawlowania” — jest to ręczna ścieżka, która może potrwać kilka dni i nie daje gwarancji. Odzyskiwanie nie wiąże się z takim utrudnieniem.)

Jak Bing obsługuje 429

Powszechnie opisuje się, że Bingbot zachowuje się podobnie — sygnały przeciążenia 429/500/503 powodują wycofanie się Bingbota — choć w tej rundzie badań nie udało mi się niezależnie potwierdzić aktualnego brzmienia na stronach pomocy Binga (są to aplikacje SPA renderowane przez JavaScript, które nie udostępniły pobieralnego tekstu statycznego). Traktuj więc twierdzenie o zgodności jako informację branżową, a nie coś zweryfikowanego w aktualnej dokumentacji Binga. Bing potwierdza natomiast we własnych historycznych wytycznych dwa proaktywne mechanizmy, których Google nie oferuje w tej samej formie:

• Crawl Control w Bing Webmaster Tools — siatkę żądań na sekundę, w której ustawiasz szybkość Bingbota według pory dnia.
• Dyrektywę crawl-delay w robots.txt. Aktualne wytyczne Binga opisują wartości od 1 do 20 sekund. Jest to rozwiązanie właściwe dla Binga; nie ogranicza Googlebota.

W Bingu możesz więc proaktywnie ograniczać szybkość przez crawl-delay lub Crawl Control, zamiast reagować kodami stanu. (Google wycofał własny ręczny suwak szybkości crawlowania w 2024 r. i obecnie całkowicie polega na odpowiedziach serwera.)

Kiedy celowo wysłać 429

Uzasadnione powody, aby celowo zwrócić 429:

• Awaryjne obciążenie serwera — skok ruchu, nieudana migracja lub awaria, gdy trzeba natychmiast spowolnić Googlebota na kilka godzin.
• Ochrona API i punktów końcowych innych niż HTML przed nadużyciami crawlerów i botów — crawlery wyszukiwarek, zewnętrzne crawlery SEO (Ahrefs, Screaming Frog) i scrapery mogą trafić na limity mające zatrzymać nadużycia.

Do czego 429 nie służy: do trwałego blokowania botów, których w ogóle nie chcesz wpuszczać. Jeśli czegoś nigdy nie chcesz crawlowac, użyj zakazu w robots.txt, a nie 429. Jeśli chcesz zachować stronę, ale wyłączyć ją z indeksu, użyj noindex. 429 oznacza tylko „później”, a nie „nigdy”.

Niezamierzone 429 — typowi winowajcy

Gdy odpowiedzi 429 pojawiają się w raporcie indeksowania stron lub statystykach crawlowania GSC, mimo że ich nie skonfigurowałeś, źródłem jest zwykle jedna z poniższych rzeczy — nie znam dobrych dowodów na uniwersalny ranking częstości, więc potraktuj to jako listę hipotez do potwierdzenia lub odrzucenia, a nie diagnozę:

• Błędnie działające reguły WAF / zapory dotyczące prawidłowych zakresów adresów IP crawlerów.
• Zbyt ciasne domyślne limity współdzielonego hostingu lub CDN-u dla rzeczywistego crawlowania.
• Narzędzia zarządzania botami błędnie klasyfikujące Googlebota lub Bingbota jako ruch nadużywający.
• Agresywne oprogramowanie pośredniczące do ograniczania szybkości przeznaczone do ochrony API, które przechwytuje własne crawlery.

Zanim zmienisz próg lub napiszesz regułę zwalniającą prawdziwe boty wyszukiwarek, najpierw ustal pochodzenie odpowiedzi — nie zgaduj, która warstwa ją wystawiła. Pobierz surowe nagłówki odpowiedzi, dokładne wiersze logu żądania (nie podsumowanie pulpitu), identyfikator uruchomionej reguły lub strefy limitu, klucz klienta użyty do zliczania (IP, sesja, klucz API), trasę, lokalizację POP-u CDN-u lub krawędzi oraz przedział czasu. Ten zestaw pokaże, która warstwa rzeczywiście wystawiła 429 i co zliczała — dopiero wtedy ma sens poluzowanie limitu albo dodanie wyjątku. Tożsamość crawlera zweryfikuj przez odwrotne i ponowne wyszukiwanie DNS (oficjalna metoda Google), a nie tylko przez ciąg user-agenta — fałszywe user-agenty „Googlebot” są częste. Karta Scripts zawiera dokładne polecenia.

Skrócona wersja planu działania

1. Użyj 429 lub 503 z Retry-After, aby spowolnić crawlera — nigdy 403 ani 404.
2. Ogranicz to do godzin lub 1–2 dni — później adresy URL mogą zostać usunięte.
3. Pamiętaj, że ograniczenie obejmuje cały host i odzyskuje się automatycznie, gdy błędy ustaną.
4. Ogranicz regułę do właściwego ruchu i zweryfikuj tożsamość crawlera przed zwolnieniem botów z limitu.

Podsumowanie AI

Skrót wersji Advanced:

• 429 Too Many Requests oznacza, że serwer informuje klienta (przeglądarkę, skrypt lub crawler), iż wysłał zbyt wiele żądań zbyt szybko — to „rate limiting”. Formalnie jest to błąd klienta 4xx.
• Poziom protokołu: RFC 6585 mówi, że odpowiedź 429 SHOULD wyjaśniać warunek i MAY zawierać Retry-After — jest to zalecane, ale nie wymagane. Odpowiedź nie może być przechowywana przez cache; zcache’owany lub odtworzony 429 to błąd pośrednika, a nie źródła. Sposób zliczania i kluczowania limitu (IP, sesja, klucz API, zasób) jest własną polityką — specyfikacja go nie definiuje.
• Jeden wyjątek 4xx: Google traktuje 429 jak błąd serwera 5xx, a nie jak 403/404. Odczytuje go jako “server overloaded, slow down” (tłumaczenie) „serwer przeciążony, zwolnij” i ogranicza crawlowanie zamiast usuwać treści.
• Google zaleca 429 (oraz 500/503) do spowalniania crawlerów — nigdy 403 ani 404. Gary Illyes napisał wpis w 2023 r. właśnie po to, aby powiedzieć witrynom i CDN-om, by przestały używać 404 do ograniczania Googlebota.
• Ograniczenie obejmuje cały host, po przekroczeniu progu — Google warunkuje ten efekt znaczną liczbą odpowiedzi 500/503/429, a nie pojedynczym 429. Po przekroczeniu progu wolniej crawlowane są również strony nadal zwracające 200.
• Wskazówka 1–2 dni, nie twarda granica: dokumentacja Google mówi o „kilku godzinach lub 1–2 dniach”. Utrzymujące się przez wiele dni 429 dla tych samych adresów URL oznacza ryzyko ich usunięcia z indeksu — „może” i „ostatecznie”, a nie gwarancję — podobnie jak przy długim 503.
• Odzyskiwanie jest kierunkowe, nie natychmiastowe: przestań wysyłać 429, a Google mówi, że szybkość crawlowania „zaczyna ponownie rosnąć” — bez ponownego zgłoszenia i bez trwałej kary, ale też bez obietnicy natychmiastowego lub pełnego powrotu według stałego harmonogramu.
• Ponowienia po stronie klienta: honoruj prawidłowy Retry-After, gdy jest obecny; gdy go nie ma, RFC nie narzuca wzoru — użyj ograniczonego backoffu z jitterem, ogranicz liczbę prób i sprawdź idempotencję przed powtórzeniem żądania nieidempotentnego.
• Ogranicz limit do właściwego ruchu i zweryfikuj tożsamość crawlera (odwrotny i ponowny DNS), zanim zwolnisz boty z limitu.
• Bing według licznych relacji podobnie wycofuje się po 429, choć w tej rundzie nie potwierdzono tego niezależnie w aktualnej dokumentacji Binga; historyczne wytyczne Binga potwierdzają crawl-delay i siatkę Crawl Control jako proaktywne alternatywy.
• 429 ≠ blokada: oznacza „później”, a nie „nigdy”. Użyj robots.txt, aby nie wpuszczać botów, i noindex, aby usunąć stronę z indeksu.

Oficjalna dokumentacja

Dokumentacja źródłowa wyszukiwarek i specyfikacji HTTP.

Google

• Nie używaj 403 ani 404 do ograniczania szybkości — wpis Gary’ego Illyesa z lutego 2023 r.; kanoniczne stwierdzenie, że 429 jest wyjątkiem, a 403/404 są niewłaściwymi narzędziami.
• Zmniejszanie szybkości crawlowania Google — wskazówka „zwróć 500, 503 lub 429”, okno 1–2 dni, ograniczenie obejmujące cały host i automatyczne odzyskiwanie.
• Kody stanu HTTP, błędy sieci i DNS — sposób obsługi każdego kodu przez Google; 429 jest grupowany z błędami serwera (strona jest też dostępna pod starszą ścieżką search/docs/crawling-indexing/http-network-errors).
• Zmniejszanie szybkości crawlowania Google — ścieżka specjalnego zgłoszenia — ręczna ścieżka „zgłoś problem z niezwykle wysoką szybkością crawlowania”, gdy wysyłanie błędów nie jest możliwe.

Bing / Microsoft

• Crawl Control — harmonogram żądań na sekundę Bingbota w Bing Webmaster Tools.
• Wytyczne dotyczące Bingbota — aktualne wytyczne Bing Webmaster dotyczące crawl-delay (1–20 sekund).

Specyfikacja HTTP

• MDN — 429 Too Many Requests — definicja protokołu, Retry-After i podstawy ograniczania szybkości.

Cytaty ze źródeł

Wypowiedzi przedstawicieli Google i Binga oraz fragmenty specyfikacji HTTP. Każdy link prowadzi bezpośrednio do cytowanego fragmentu strony źródłowej.

Google — Gary Illyes, „Nie używaj 403 ani 404 do ograniczania szybkości” (luty 2023)

• “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate.” (tłumaczenie) „W ciągu ostatnich kilku miesięcy zauważyliśmy wzrost liczby właścicieli witryn i niektórych sieci dostarczania treści (CDN), którzy próbują używać kodu 404 i innych błędów klienta 4xx (ale nie 429) do zmniejszenia szybkości crawlowania Googlebota.” Przejdź do cytatu
• “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (tłumaczenie) „Wyjątkiem jest 429 („zbyt wiele żądań”): poprawnie działający robot, także Googlebot, odczytuje ten błąd jako polecenie zwolnienia, ponieważ obciąża serwer.” Przejdź do cytatu
• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (tłumaczenie) „Wszystkie kody statusu HTTP 4xx (ponownie z wyjątkiem 429) spowodują usunięcie Twojej treści z Google Search.” Przejdź do cytatu
• “Use Search Console to temporarily reduce crawl rate. Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (tłumaczenie) „Użyj Search Console, aby tymczasowo zmniejszyć szybkość crawlowania. Zwróć Googlebotowi kod statusu HTTP 500, 503 lub 429, gdy crawluje zbyt szybko.” Przejdź do cytatu

Google — zmniejszanie szybkości crawlowania / referencja kodów stanu

• “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (tłumaczenie) „Jeśli musisz pilnie zmniejszyć szybkość crawlowania przez krótki czas (na przykład kilka godzin lub 1–2 dni), zwróć dla żądań crawlowania kod statusu HTTP 500, 503 lub 429 zamiast 200.” Przejdź do cytatu
• “The reduced crawl rate affects the whole hostname of your site… Once the number of these errors is reduced, the crawl rate will automatically start increasing again.” (tłumaczenie) „Zmniejszona szybkość crawlowania obejmuje cały host Twojej witryny… Gdy liczba tych błędów się zmniejszy, szybkość crawlowania automatycznie zacznie ponownie rosnąć.” Przejdź do cytatu
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days)… the URL may be dropped from Google’s index.” (tłumaczenie) „Nie zalecamy robić tego przez długi czas (czyli dłużej niż 1–2 dni)… adres URL może zostać usunięty z indeksu Google.” Przejdź do cytatu
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (tłumaczenie) „Crawlery Google traktują kod statusu 429 jako sygnał przeciążenia serwera i jest on uznawany za błąd serwera.” Przejdź do cytatu
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (tłumaczenie) „Nie używaj kodów statusu 401 i 403 do ograniczania szybkości crawlowania. Kody statusu 4xx, z wyjątkiem 429, nie wpływają na szybkość crawlowania.” Przejdź do cytatu

MDN — definicja protokołu

• “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (tłumaczenie) „Odpowiedź HTTP 429 Too Many Requests informuje, że w danym przedziale klient przekroczył liczbę żądań. Polecenie ograniczenia ich częstotliwości określa się jako rate limiting.” Przejdź do cytatu

Bing — aktualne wytyczne Webmaster

• Wytyczne dotyczące Bingbota opisują wartości crawl-delay od 1 do 20 sekund. Traktuj je jako wskazówkę właściwą dla Binga, a nie ogólny mechanizm ograniczania crawlerów.

Branżowe potwierdzenie stwierdzenia Google

• Wpis Illyesa z lutego 2023 r. został dosłownie omówiony przez Search Engine Land, Search Engine Roundtable i Search Engine Journal — wszystkie trzy źródła przedstawiają 429 jako „jedyny wyjątek”. Są to branżowe omówienia tego samego wpisu Google; źródłem pierwotnym jest przytoczony wyżej wpis Illyesa.

Wyślij prawidłowy 429 — z Retry-After

Najważniejszym elementem poprawnej odpowiedzi 429 jest nagłówek Retry-After. Informuje on każdego zgodnego klienta — w tym Googlebota — jak długo czekać. Może zawierać liczbę sekund albo datę HTTP:

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

<html><body>Too many requests. Please retry later.</body></html>

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 01 Jul 2026 12:00:00 GMT

Pominięcie Retry-After nie oznacza braku zgodności, ale jego dodanie jest najlepszą praktyką i daje crawlerom konkretny sygnał wycofania.

nginx — ograniczanie szybkości zwracające 429

Domyślnie limit_req w nginx zwraca 503. Aby uzyskać semantykę przyjazną crawlerom, nadpisz ją na 429 i dodaj nagłówek Retry-After. Ten przykład pozwala na 10 żądań na sekundę z jednego adresu IP i niewielki burst:

# In the http {} block: define a shared memory zone keyed by client IP
limit_req_zone $binary_remote_addr zone=crawl_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=crawl_limit burst=20 nodelay;

        # Return 429 (not the default 503) when the limit is exceeded
        limit_req_status 429;
    }

    # Attach a Retry-After header to 429 responses
    error_page 429 = @too_many;
    location @too_many {
        add_header Retry-After 3600 always;
        return 429;
    }
}

Apache — ograniczanie szybkości przez mod_ratelimit / mod_evasive

Rdzeń Apache mod_ratelimit ogranicza przepustowość, a nie liczbę żądań, dlatego do ograniczania częstotliwości zwykle używa się mod_evasive (albo WAF-u). Aby ograniczona odpowiedź zwracała 429 z Retry-After, ustaw to jawnie:

# Send a 429 with Retry-After for a chosen condition (e.g. a rate-limit env var)
<If "%{ENV:RATE_LIMITED} == '1'">
    Header always set Retry-After "3600"
    Redirect 429 /
</If>

# mod_evasive: throttle abusive request bursts (returns 429 in recent versions;
# older builds default to 403 — override where possible)
<IfModule mod_evasive20.c>
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSBlockingPeriod   60
</IfModule>

Zwróć uwagę na zastrzeżenie: starsze wersje mod_evasive domyślnie blokują odpowiedzią 403 — dokładnie tym kodem, którego Google mówi, aby nie używać do ograniczania szybkości. Potwierdź, że Twoja wersja zwraca 429 (albo umieść przed nią CDN/WAF, który to robi).

Cloudflare / CDN — ograniczanie szybkości do 429

Na warstwie CDN ustaw odpowiedź akcji reguły ograniczania szybkości na 429 (wiele usług domyślnie wybiera 403 albo wyzwanie). W regułach Rate Limiting Cloudflare status odpowiedzi po przekroczeniu limitu można skonfigurować — wybierz 429 i, jeśli jest to obsługiwane, dołącz Retry-After. Ta sama zasada obowiązuje w Fastly, Akamai i bramie API: akcja po przekroczeniu limitu powinna zwracać 429 Too Many Requests, a nie 403 Forbidden.

Po stronie klienta: ponowienie po 429 bez jednego wzoru

Jeśli piszesz klienta, RFC daje Ci dokładnie jedną twardą regułę i nie podaje algorytmu awaryjnego: gdy obecny jest prawidłowy Retry-After, zastosuj się do niego. Gdy go nie ma, RFC 6585 nie określa odstępu między próbami, wzoru backoffu, rozkładu jitteru, liczby prób ani warunku „sukcesu” — to Twoja polityka, a nie wymóg specyfikacji. Nie przedstawiaj żadnego pojedynczego wzoru (w tym poniższego) jako prawa HTTP; jest to rozsądny ograniczony domyślny wybór, a nie jedyne poprawne rozwiązanie.

on 429 response:
    if Retry-After header present and valid:
        wait = parse(Retry-After)          # seconds or HTTP-date
    else:
        wait = min(cap, base * 2^attempt) + random_jitter(0, jitter_window)

    if attempt >= max_attempts or wait > cap:
        stop and surface the failure        # don't retry forever
    if request is not idempotent (e.g. a POST that isn't safe to repeat):
        confirm idempotency (idempotency key, or a safe no-op check) before retrying
    sleep(wait)
    attempt += 1
    retry request

Niezależnie od wybranych liczb znaczenie mają trzy elementy: ograniczenie łącznego czasu oczekiwania i liczby prób (nie ponawiaj bez końca), jitter (aby flota klientów nie ponawiała w tym samym momencie i nie wywołała limitu ponownie) oraz sprawdzenie idempotencji przed ponowieniem czegokolwiek, czego nie można bezpiecznie powtórzyć (nieidempotentny POST potrzebuje klucza deduplikacji, a nie ślepej próby).

Zanim zwolnisz bota, sprawdź, czy to naprawdę Googlebot

Jeśli piszesz wyjątki od limitu dla wyszukiwarek, potwierdź tożsamość przez odwrotne i ponowne wyszukiwanie DNS — podszywanie się pod user-agenta „Googlebot” jest częste, a sam ciąg UA niczego nie dowodzi.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Jeśli odwrotne wyszukiwanie nie kończy się domeną Google albo ponowne wyszukiwanie nie wskazuje tego samego adresu IP, nie jest to Googlebot. Możesz także porównać adres z opublikowanymi zakresami IP Google (googlebot.json).

Typowe mity o 429 i SEO

Mit: „Każdy 429 zaszkodzi mojemu SEO albo spowoduje usunięcie z indeksu”. Nie. Google zaprojektował 429 jako bezpieczny, oczekiwany sygnał ograniczania. Krótkie lub sporadyczne 429 są normalne i samoczynnie się korygują. Ryzyko usunięcia z indeksu pojawia się dopiero przy utrzymujących się 429 dla tych samych adresów URL przez wiele dni — granicą jest własna wskazówka Google o 1–2 dniach.

Mit: „429 i 503 są z punktu widzenia SEO praktycznie wymienne”. Przy ograniczaniu szybkości crawlowania Google traktuje je podobnie. Oznaczają jednak coś innego: 503 Service Unavailable to tradycyjny sygnał „tymczasowo niedostępne / konserwacja”, a 429 konkretnie komunikuje przeciążenie szybkością lub wolumenem żądań. Użycie semantycznie właściwego kodu ma znaczenie dla własnego monitoringu, narzędzi i wszystkiego, co później odczytuje kody stanu — nawet jeśli Googlebot wycofa się w obu przypadkach.

Mit: „Możesz użyć 403 lub 404, aby spowolnić Googlebota tak jak 429”. Wpis Illyesa z lutego 2023 r. bezpośrednio temu zaprzecza — zjawisko było tak powszechne, że Google napisał osobny artykuł, prosząc, aby przestać tak robić. 403/404 nie wpływają na szybkość crawlowania i aktywnie usuwają treść z indeksu. 429 jest jedynym kodem 4xx, który ogranicza szybkość.

Mit: „Ograniczanie szybkości botów wyszukiwarek powoduje trwałe cięcie budżetu crawlowania”. Zmniejszenie jest tymczasowe i automatycznie się cofa, gdy liczba błędów spadnie. Po ustaniu błędów na witrynie nie pozostaje żadna trwała flaga — dokumentacja Google mówi, że szybkość crawlowania “will automatically start increasing again.” (tłumaczenie) „automatycznie zacznie ponownie rosnąć”.

Mit: „Jeśli Googlebot dostanie 429, na zawsze rezygnuje z tego adresu URL”. Google spróbuje później ponownie. Obawą są utrzymujące się przez wiele dni 429 dla jednego adresu URL — nie jednorazowe ani sporadyczne ograniczenie, które Googlebot po prostu respektuje i po którym wraca.

Często zadawane pytania

Czy błąd 429 szkodzi SEO? Nie sam w sobie. Krótkie lub sporadyczne 429 tylko tymczasowo spowalniają Googlebota i samoczynnie ustępują. Ryzyko pojawia się dopiero wtedy, gdy te same adresy URL zwracają 429 przez wiele dni.

Jak długo mogę zwracać 429, zanim Google usunie moje strony z indeksu? Dokumentacja Google mówi, aby ograniczyć to do “a couple of hours, or 1–2 days.” (tłumaczenie) „kilku godzin lub 1–2 dni”. Później “the URL may be dropped from Google’s index.” (tłumaczenie) „adres URL może zostać usunięty z indeksu Google”. Traktuj 1–2 dni jako twardy górny limit, a nie cel.

Jaka jest różnica między 429 a 503 w SEO? Google ogranicza crawlowanie w obu przypadkach podobnie. 503 oznacza jednak “temporarily down / maintenance” (tłumaczenie) „tymczasowo niedostępne / konserwacja”, a 429 konkretnie “you’re sending too many requests.” (tłumaczenie) „wysyłasz zbyt wiele żądań”. Użyj semantycznie właściwego kodu, aby własny monitoring i narzędzia odczytywały sytuację poprawnie.

Czy powinienem blokować Googlebota kodem 429, jeśli chcę trwale ograniczyć crawlowanie? Nie — 429 jest sygnałem krótkoterminowym, a nie ustawieniem stałym. Przy trwałym zmniejszeniu szybkości Google zaleca złożenie specjalnego zgłoszenia dotyczącego wysokiej szybkości crawlowania. Aby całkowicie nie wpuszczać botów do obszaru, użyj robots.txt; aby usunąć stronę z indeksu, użyj noindex.

Czy Bingbot respektuje 429 tak samo jak Googlebot? Bingbot również wycofuje się po sygnałach przeciążenia, takich jak 429/500/503. Bing oferuje dodatkowo proaktywne mechanizmy, których Google nie ma — dyrektywę crawl-delay w robots.txt oraz siatkę żądań na sekundę Crawl Control w Bing Webmaster Tools.

Czym jest nagłówek Retry-After i czy go potrzebuję? Retry-After informuje klienta, jak długo czekać przed ponowieniem (liczba sekund albo data HTTP). Nie jest ściśle wymagany, ale stanowi najlepszą praktykę i daje crawlerom konkretny sygnał wycofania.

Czy Google wznowi normalne crawlowanie po zaprzestaniu wysyłania 429? Tak, automatycznie. Gdy liczba błędów spadnie, “the crawl rate will automatically start increasing again.” (tłumaczenie) „szybkość crawlowania automatycznie zacznie ponownie rosnąć”. Nie trzeba niczego ponownie zgłaszać i nie ma trwałej kary.

Czy narzędzia WAF lub CDN mogą przypadkowo zwrócić 429 Googlebotowi? Bardzo często. Agresywne reguły zapory, domyślne limity CDN-u lub hostingu i narzędzia zarządzania botami mogą błędnie sklasyfikować Googlebota albo Bingbota. Zanim dodasz wyjątki, zweryfikuj tożsamość crawlera (odwrotny i ponowny DNS) i poluzuj limity przechwytujące prawdziwe wyszukiwarki.

Czy 429 jest błędem klienta czy serwera? Technicznie w specyfikacji HTTP jest to błąd klienta 4xx. Jednak Google traktuje go jako błąd serwera w kontekście crawlowania — to jedyny kod 4xx grupowany z 5xx.

Co powinien zrobić klient, gdy otrzyma 429 bez nagłówka Retry-After? HTTP nie narzuca tu żadnego wzoru — specyfikacja pozostawia decyzję polityce. Rozsądny ograniczony domyślny wariant to wykładniczy backoff z jitterem, twardy limit łącznego czasu oczekiwania i liczby prób, aby nie ponawiać bez końca, oraz sprawdzenie idempotencji przed powtórzeniem żądania, którego nie można bezpiecznie wysłać dwa razy. Karta Scripts zawiera działający pseudokod.

Co zrobić z odpowiedzią 429?

Typowe problemy z 429

Googlebot dostaje 429, ale zwykli odwiedzający nie

Objaw: raporty crawlera pokazują 429, a testy w przeglądarce zwracają 200. Prawdopodobna przyczyna: zarządzanie botami, reguła UA albo ograniczanie według adresu IP. Naprawa: skoreluj zdarzenia WAF ze zweryfikowanymi adresami IP crawlera, a następnie zawęź lub popraw odpowiedzialną regułę; nie dodawaj do allowlisty samego ciągu user-agenta.

Szybkość crawlowania całego hosta spada

Objaw: crawlowanie zwalnia poza adresami URL, które zwróciły 429. Prawdopodobna przyczyna: Google stosuje sygnał przeciążenia do całego hosta. Naprawa: zatrzymaj niezamierzone 429, przywróć stabilne odpowiedzi sukcesu i pozwól szybkości crawlowania odzyskać się automatycznie.

Odpowiedzi 429 trwają po zakończeniu awarii

Objaw: serwer działa poprawnie, ale adresy URL nadal zwracają 429. Prawdopodobna przyczyna: cache CDN-u, reguła na krawędzi lub stan limitera przetrwały zdarzenie. Naprawa: wyłącz albo wygaś tymczasową regułę, usuń nieprawidłowo zcache’owaną odpowiedź i zweryfikuj wynik na reprezentatywnych ścieżkach oraz w regionach.

Nagłówka Retry-After brakuje albo jest bezużyteczny

Objaw: klienci wiedzą, że zostali ograniczeni, ale nie wiedzą, kiedy ponowić próbę. Prawdopodobna przyczyna: odpowiedź wygenerowała ogólna reguła bezpieczeństwa. Naprawa: spraw, aby warstwa wystawiająca odpowiedź wysyłała prawidłowe opóźnienie lub datę HTTP, i przetestuj surowy nagłówek.

Prompt: audyt reguły ograniczania szybkości

Review this 429 rate-limit configuration for search-crawler safety. Identify its key,
scope, threshold source, Retry-After behavior, hostname-wide SEO impact, and any
user-agent-only exceptions. Separate deliberate short-term overload protection from
permanent crawl control. Return a minimal safe revision, test matrix, monitoring
signals, and rollback conditions. Do not invent provider syntax.

[PASTE CONFIGURATION AND SANITIZED SAMPLE LOGS]

Prompt: diagnoza niewyjaśnionych odpowiedzi 429

Use these headers, access-log rows, WAF events, and timestamps to determine which
layer generated the 429 and which traffic dimension triggered it. Give competing
hypotheses ranked by evidence, the next exact check for each, and a fix that does not
trust claimed crawler user agents. Do not infer missing logs.

[PASTE EVIDENCE]

Narzędzia do badania odpowiedzi 429

• Masowy checker kodów stanu HTTP: przetestuj reprezentatywny zestaw adresów URL i wyeksportuj ścieżki, które obecnie zwracają 429.
• Checker nagłówków HTTP: sprawdź Retry-After, odciski CDN-u i kolejne przekierowania ograniczonej odpowiedzi.
• Weryfikator Googlebota: potwierdź dowody dotyczące IP przed utworzeniem wyjątku dla crawlera.
• Analizator plików logów: podziel marnowanie kodów stanu według bota i sekcji, pozostawiając przesłane logi w przeglądarce.
• Statystyki crawlowania w Search Console: porównaj czas występowania 429 ze zmianami liczby żądań crawlowania i zachowania odpowiedzi hosta.

Walidacja konfiguracji 429

Test kontraktu odpowiedzi

Test do wykonania: bezpiecznie wywołaj limit w kontrolowanym środowisku i sprawdź surową odpowiedź. Oczekiwany wynik: 429 z prawidłowym Retry-After, bez przypadkowego przekierowania ani statusu sukcesu. Interpretacja niepowodzenia: odpowiedź należy do niewłaściwej warstwy lub szablonu błędu. Okno monitorowania: natychmiast. Warunek wycofania: ograniczane są zwykłe żądania albo test destabilizuje usługę.

Test zakresu

Test do wykonania: wykonaj żądania jako klient, którego limit ma dotyczyć, jako zwykli użytkownicy i jako zweryfikowany crawler, dla reprezentatywnych klas adresów URL. Oczekiwany wynik: limit przekracza tylko zdefiniowany rodzaj ruchu. Interpretacja niepowodzenia: klucz limitu lub zakres reguły jest zbyt szeroki. Okno monitorowania: podczas testu kontrolowanego i propagacji na krawędzi. Warunek wycofania: niezwiązane trasy, użytkownicy lub hosty otrzymują 429.

Test odzyskiwania

Test do wykonania: zatrzymaj wyzwalacz, odczekaj skonfigurowany interwał ponowienia i wykonaj żądania ponownie. Oczekiwany wynik: stabilne, zwykłe odpowiedzi wracają bez ręcznej naprawy dla poszczególnych adresów URL. Interpretacja niepowodzenia: zcache’owane odpowiedzi 429 lub stan limitera nadal się utrzymują. Okno monitorowania: skonfigurowany interwał oraz propagacja wdrożenia. Warunek wycofania: host pozostaje ograniczony po usunięciu źródłowego obciążenia.

Test przechowywania w cache

Test do wykonania: umieść cache lub krawędź CDN-u przed ograniczoną trasą, wywołaj 429, a następnie po usunięciu warunku źródłowego zażądaj tego samego adresu URL ponownie. Oczekiwany wynik: drugie żądanie jest oceniane od nowa — krawędź nie zwraca zcache’owanego ani odtworzonego 429. Interpretacja niepowodzenia: pośrednik przechowuje odpowiedź, której RFC 6585 nie pozwala cache’ować; sprawdź nagłówki cache-control i konfigurację reguły krawędzi, a nie źródło. Okno monitorowania: natychmiast, na reprezentatywnym zestawie węzłów krawędzi/POP-ów. Warunek wycofania: po odzyskaniu źródła dostarczany jest jakikolwiek zcache’owany 429.

Test polityki ponowień klienta

Test do wykonania: prześlij klienta przez odpowiedź 429 zarówno z obecnym prawidłowym nagłówkiem Retry-After, jak i bez niego. Oczekiwany wynik: z nagłówkiem klient czeka wskazany interwał; bez niego stosuje ograniczony backoff z jitterem, respektuje maksymalną liczbę prób i sprawdza idempotencję przed powtórzeniem żądania nieidempotentnego. Interpretacja niepowodzenia: klient ponawiający natychmiast, bez ograniczeń albo ślepo powtarzający żądanie nieidempotentne ma błędną politykę ponowień, a nie problem ze zgodnością HTTP. Okno monitorowania: przez pełną ograniczoną sekwencję ponowień. Warunek wycofania: klient ponownie wywołuje ten sam limit przez natychmiastowe lub nieograniczone próby.

Zasoby warte Twojego czasu

Moje powiązane teksty

• Kody stanu HTTP i ich wpływ na SEO — pełny przewodnik po wpływie wszystkich kodów stanu na SEO, w tym o miejscu 429.
• Przewodnik dla początkujących po technicznym SEO — miejsce kontroli crawlowania i kodów stanu w szerszym obrazie.
• Historia zablokowania 2 wysoko pozycjonowanych stron przez robots.txt — mój eksperyment pokazujący z pierwszej ręki, co dzieje się po odcięciu crawlerów.

Moje wystąpienia

• Jak działa wyszukiwarka (SlideShare) — omówienie crawlowania, renderowania, indeksowania i rankingu, w tym sposobu, w jaki serwery sygnalizują crawlerom potrzebę zwolnienia. (Obowiązuje moje stałe zastrzeżenie: “This is my understanding of systems… not going to be 100% complete or accurate.” (tłumaczenie) „To moje rozumienie systemów… nie będzie w 100% kompletne ani dokładne.)”)

Z branży

• Nie używaj 403 ani 404 do ograniczania szybkości (Google Search Central, Gary Illyes) — kanoniczne stwierdzenie, że 429 jest wyjątkiem.
• Zmniejszanie szybkości crawlowania Google (Google) — okno 1–2 dni, ograniczenie obejmujące cały host i automatyczne odzyskiwanie.
• Google ostrzega przed używaniem kodów 403 lub 404 do ograniczania crawlowania Googlebota (Search Engine Land) — branżowe omówienie wpisu Illyesa.
• Google mówi: przestań używać 403 i 404 do ograniczania szybkości Googlebota (Search Engine Roundtable) — podsumowanie Barry’ego Schwartza przedstawiające 429 jako „jedyny wyjątek”.
• Google: nie używaj odpowiedzi błędów 403/404 do ograniczania Googlebota (Search Engine Journal) — trzecie niezależne omówienie tych samych wytycznych.
• MDN — 429 Too Many Requests — definicja HTTP i referencja Retry-After.
• Wytyczne dotyczące Bingbota — aktualne wytyczne Binga dotyczące dyrektywy crawl-delay.

Sprawdź się: 429 Too Many Requests

Pięć krótkich pytań o działanie 429 i sposób traktowania go przez Google. Wybierz odpowiedź na każde pytanie, a następnie sprawdź wynik.

Dziennik zmian