Kod 503 kojarzy się z awarią, którą trzeba jak najszybciej ukryć przed Google. A gdy serwer naprawdę nie nadąża, to jedna z najrozsądniejszych odpowiedzi, jakie strona może dać robotowi. 6 października 2026 Google przebudował stronę dokumentacji o zmniejszaniu częstotliwości skanowania i dopisał do niej przykłady z nagłówkiem Retry-After, czyli informacją, kiedy robot może wrócić. Mechanizm nie jest nowy, ale teraz jest opisany tam, gdzie szuka się go w nagłej sytuacji. Rozpisuję, co z tego wynika dla małej strony firmowej, gdzie w Search Console widać, że serwer nie nadąża, i dlaczego na zwykłym hostingu ten przełącznik zwykle nie jest w Twoich rękach.
Co Google dopisał 6 października
Na stronie „Reduce the Google crawl rate” Google pisze, że jeśli musisz pilnie zmniejszyć skanowanie na krótki czas, na przykład na kilka godzin albo 1-2 dni, serwer może zwracać robotom kod 500, 503 albo 429 zamiast 200. Gdy robot trafi na znaczną liczbę takich odpowiedzi, zwalnia skanowanie całego hosta, czyli całej domeny albo subdomeny, także adresów, które działają poprawnie. Kiedy błędów ubywa, tempo samo zaczyna wracać do normy.
Nowe są przykłady z nagłówkiem Retry-After. Przy kodzie 503 albo 429 serwer może dopisać, po ilu sekundach robot ma spróbować ponownie, albo podać konkretną datę i godzinę w czasie UTC. Google zaznaczył przy tej zmianie, że obsługa nagłówka nie jest nowością, bo była już opisana w poradniku o czasowym wyłączaniu strony. Search Engine Roundtable porównał nową wersję dokumentu z archiwalną: poza tym fragmentem to głównie przestawione akapity.
Czytam to tak: Google nie dał nowego narzędzia, tylko uporządkował instrukcję na wypadek pożaru. Dobrze ją znać, zanim pożar wybuchnie, bo w trakcie nie ma czasu na czytanie dokumentacji po angielsku.
Hamulec dla robota też kosztuje
Ta sama strona dokumentacji zaczyna się od ostrzeżenia, które warto przeczytać dwa razy. Mniejsza częstotliwość skanowania oznacza, że Googlebot znajdzie mniej nowych stron, rzadziej odświeży istniejące, na przykład ceny i dostępność produktów, a usunięte strony mogą dłużej zostać w indeksie. O Google Ads Google pisze wprost: kampanie mogą zostać anulowane albo wstrzymane, a reklamy mogą się nie wyświetlać. Jeśli reklamujesz się na tej samej domenie, hamulec dla robota może więc przyhamować też sprzedaż z reklam.
Druga granica to czas. W dokumentacji jest mowa o kilku godzinach albo 1-2 dniach. Pomoc Search Console przy raporcie statystyk indeksowania odradza zwracanie 503 lub 429 dłużej niż 2-3 dni, bo Google może potem na stałe rzadziej indeksować witrynę. A według strony o kodach HTTP adresy, które uporczywie zwracają błąd serwera, w końcu wypadają z indeksu.
Są też trzy skróty, których nie stosuję. Nie spowalniam robota kodami 403 ani 404, bo Google pisze, że kody 4xx poza 429 nie wpływają na tempo skanowania, a wcześniej zindeksowany adres z takim kodem wypada z indeksu. Nie zwracam błędu dla pliku robots.txt, bo przy jego niedostępności Google wstrzymuje skanowanie całej witryny. I nie liczę na to, że nowa reguła w robots.txt zadziała od ręki: Google korzysta z pobranej wersji tego pliku nawet przez 24 godziny, więc blokada może zacząć działać dopiero następnego dnia.
Stan hosta w Search Console i jedna zła minuta
Zanim cokolwiek zmienisz, sprawdź, czy problem w ogóle jest. W Search Console otwórz Ustawienia, a potem Statystyki indeksowania. Karta Stan hosta pokazuje trzy kategorie: pobieranie pliku robots.txt, rozpoznawanie nazw DNS i połączenie z serwerem. Na wykresie każdej z nich jest czerwona przerywana linia i jeśli wartość z danego dnia ją przekroczy, Google uznaje, że był problem. Niżej, w tabeli odpowiedzi, widać udział błędów serwera (5xx) i przekroczeń czasu oczekiwania, a po kliknięciu przykładowe adresy z dokładnymi godzinami.
Google sam pisze, że to raport dla zaawansowanych i że przy witrynie poniżej 1000 stron zwykle nie musisz się nim przejmować. Ja i tak zaglądam tam przy małych stronach w jednej sytuacji: gdy test opublikowanego adresu w Search Console kończy się błędem połączenia.
W tym tygodniu miałem dokładnie taki przypadek przy jednej ze stron, którymi się zajmuję. Test na żywo zakończył się komunikatem „Brak połączenia z serwerem”, choć w przeglądarce strona działała. W logach serwera z tej minuty nie było żadnego żądania od Google, za to w ciągu dnia powtarzały się krótkie przestoje i odpowiedzi po kilkanaście sekund. Zweryfikowany Googlebot dostawał tego samego dnia zwykłe odpowiedzi 200. Wniosek: Google strony nie zablokował, tylko trafił na chwilę, w której serwer nie odbierał połączeń. Taki pojedynczy błąd nie wymaga hamulca dla robota. Wymaga znalezienia tego, co dławi serwer. Jeśli adres w ogóle nie trafia do indeksu, przyczyn bywa więcej niż sam serwer i przechodzę przez nie po kolei we wpisie o tym, dlaczego strony nie ma w Google.
Na hostingu współdzielonym przełącznik ma ktoś inny
Żeby serwer sam odpowiadał robotom kodem 503 z Retry-After, gdy zbliża się do limitu, trzeba mieć wpływ na jego konfigurację. Na zwykłym hostingu współdzielonym, na którym stoi większość stron małych firm, tego wpływu nie masz. Konfiguracją serwera WWW, limitami i zaporą zarządza firma hostingowa, a Twoja strona dzieli zasoby z innymi kontami. Z panelu klienta nie ustawisz, jak serwer ma odpowiadać robotom pod obciążeniem.
Co możesz zrobić sam, to zmniejszyć ilość pracy, którą strona zleca serwerowi. W przypadku z poprzedniej sekcji spora część obciążenia pochodziła z samego WordPressa. Wtyczka SEO codziennie planowała około 20 tysięcy sprawdzeń adresów, z których zdecydowana większość dotyczyła stron, których dawno nie było. Zadania uruchamiał wbudowany harmonogram WordPressa (WP-Cron), czyli odwiedziny na stronie, także te od robotów. Do tego każda podstrona była składana przez PHP od zera, bez pamięci podręcznej. Tego nie zobaczysz w Search Console, tylko w logach serwera i w kolejce zadań w tle. Po wyłączeniu tych sprawdzeń i przeniesieniu harmonogramu do crona serwera kolejka spadła do zera, a WordPress przestał uruchamiać zadania przy każdej wizycie.
Dlatego szukam w takiej kolejności: logi dostępu i błędów (godziny przestojów i to, kto wtedy wysyłał żądania), zadania w tle wtyczek, WP-Cron, pamięć podręczna stron. Dopiero gdy po stronie WordPressa nic nie znajdę, piszę do hostingu z konkretnymi godzinami i komunikatami z logów. Google zresztą też zaleca, żeby przy nagłym wzroście skanowania zacząć od rozmowy z firmą hostingową i przejrzenia ostatnich logów dostępu.
Przerwa techniczna z kodem 503 zamiast ekranu „zaraz wracamy”
Jest jedna sytuacja, w której 503 z Retry-After planujesz świadomie: przerwa techniczna, przeprowadzka strony na inny serwer, większa aktualizacja. W poradniku o czasowym wyłączaniu strony Google radzi, żeby przy wyłączeniu na 1-2 dni zamiast treści zwracać stronę z informacją i kodem 503, z nagłówkiem Retry-After z przewidywaną datą albo czasem, najlepiej w prostym statycznym HTML. Plik robots.txt ma przy tym działać normalnie, bez kodu 503. Przy dłuższej przerwie Google zaleca zostawić stronę główną z kodem 200 jako stronę zastępczą, którą da się znaleźć w wyszukiwarce.
Przed każdą przerwą sprawdzam, jaki kod zwraca strona serwisowa, bo wtyczki do trybu „wkrótce wracamy” bywają ustawione różnie. Ekran z kodem 200 to dla robota zwykła treść strony, więc w najgorszym razie w wynikach zobaczysz napis o przerwie zamiast opisu oferty. Strona z kodem 404 albo z noindex według Google wypada z wyników. Kod sprawdzisz poleceniem curl -I z adresem strony albo w przeglądarce, w narzędziach deweloperskich na karcie Sieć. Google w tym samym poradniku też podaje curl jako sposób sprawdzenia, czy serwer rzeczywiście zwraca 503.
Jeśli w Search Console widzisz błędy połączenia albo strona co jakiś czas odpowiada po kilka sekund, to zadanie dla technicznej części pozycjonowania stron, a nie powód do pisania kolejnych artykułów. Napisz mi, na jakim hostingu stoi Twoja strona i kiedy widzisz błędy, a podpowiem, od których logów zacząć.
Źródła: Google: Reduce the Google crawl rate (aktualizacja 06.10.2026), Google: How HTTP status codes affect Google’s crawlers, Google: Temporarily pause or disable a website, Pomoc Search Console: raport Statystyki indeksowania, Search Engine Roundtable o zmianie w dokumentacji (06.10.2026).
