Google odświeżyło dokument „Reduce the Google crawl rate". Większość zmian to przeorganizowanie treści na stronie, ale w sekcji dotyczącej pilnego ograniczania ruchu crawlerów (na wypadek awarii) pojawiły się nowe informacje i przykłady użycia nagłówka HTTP Retry-After. Warto od razu uściślić: Google nie wprowadza nowego mechanizmu dławienia Googlebota. Obsługa Retry-After istniała już wcześniej i była opisana w dokumencie o tymczasowym wstrzymywaniu działania witryny; przeniesienie jej do przewodnika o tempie crawlowania ma po prostu ułatwić znalezienie tej informacji wtedy, gdy jest najbardziej potrzebna.
Jak to działa w praktyce
Jeśli crawlery Google w danym momencie obciążają serwer ponad miarę, Google zaleca, aby na krótki okres (kilka godzin, maksymalnie 1–2 dni) zwracać kod 500, 503 lub 429 zamiast 200. Gdy infrastruktura Google zobaczy znaczącą liczbę takich odpowiedzi, ogranicza tempo crawlowania dla całego hosta – także dla adresów, które nadal zwracają normalną treść – a po spadku liczby błędów automatycznie zwiększa je z powrotem.
Nowość w dokumentacji polega na tym, że przy kodach 503 lub 429 (uwaga: nie 500) można dołączyć nagłówek Retry-After zgodny z RFC 9110, który podpowiada crawlerom, kiedy mogą ponowić żądanie – jako liczbę sekund albo konkretną datę i godzinę w UTC. Przykładowo:
Retry-After: 300
albo
Retry-After: Thu, 08 Oct 2026 06:00:00 GMT
Google traktuje ten nagłówek jako dodatkowy, jawny sygnał od właściciela strony, uzupełniający same kody odpowiedzi, które już wcześniej były wykorzystywane jako wskazówka do zmniejszenia crawlowania.
Na co uważać
Dokumentacja wprost ostrzega, że ograniczanie tempa crawlowania ma szerokie skutki: Googlebot odkryje mniej nowych stron, istniejące będą odświeżane rzadziej (np. ceny i dostępność produktów wolniej trafią do wyników), a usunięte adresy dłużej pozostaną w indeksie. W Google Ads kampanie mogą zostać wstrzymane lub anulowane, a reklamy mogą przestać się wyświetlać. Jeszcze ważniejsze: jeśli Googlebot przez wiele dni widzi te kody na tym samym URL-u, adres może wypaść z indeksu – dlatego Google odradza stosowanie tej metody dłużej niż 1–2 dni.
Zanim sięgniesz po kody błędów
Dokument przypomina też, że nagły wzrost crawlowania zwykle ma konkretną przyczynę po stronie serwisu – najczęściej nawigację fasetową, sortowanie i filtrowanie generujące masę URL-i, kalendarze z osobnymi adresami dla każdej daty albo cele Dynamic Search Ads. Google zaleca zajrzenie do logów serwera i skonsultowanie się z hostingiem, zanim zacznie się „gasić pożar" kodami 503. A jeśli zwracanie błędów jest na danej infrastrukturze niewykonalne, pozostaje specjalny formularz zgłoszeniowy w Search Console, w którym podaje się optymalne tempo dla witryny – rozpatrzenie może potrwać kilka dni, a o zwiększenie tempa prosić nie można.
Dla przypomnienia: od wycofania limitera tempa indeksowania z Search Console kody odpowiedzi HTTP są w zasadzie jedynym narzędziem bezpośredniego, szybkiego hamowania Googlebota – dyrektywa crawl-delay w robots.txt jest przez Google ignorowana.
Pytania do Was:
Czy ktoś z Was stosował 503 + Retry-After podczas awarii lub migracji i obserwował, jak szybko Googlebot wraca do normalnego tempa? Macie wdrożony automatyczny tryb awaryjny na poziomie CDN/WAF, czy robicie to ręcznie? I czy Wasze serwery w ogóle wysyłają Retry-After przy 429?
Więcej informacji: https://boostwave.pl/blog/
Źródło: https://www.seroundt...date-42247.html
Dokumentacja Google: https://developers.g...duce-crawl-rate
