Błąd serwera (5xx)

Co oznacza ten status

Google opisuje ten status jednym zdaniem: serwer zwrócił błąd na poziomie 500 (raport Indeksowanie stron). Strona trafia do grupy „Nie zindeksowano”. To awaria techniczna, nie ocena treści.

Według dokumentacji (jak kody HTTP wpływają na roboty Google) błędy 5xx i 429 każą robotom na jakiś czas zwolnić skanowanie. Treść zwrócona z 5xx jest ignorowana. Zindeksowane adresy Google na razie zachowuje, ale te, które stale zwracają błąd, usuwa z indeksu. Wpływ każdego kodu opisuje hasło o kodach odpowiedzi HTTP.

Najczęstsze przyczyny

Przeciążony hosting

Limit procesów PHP, pamięci albo połączeń do bazy. Serwer odpowiada 500 albo 503 tylko w szczycie, więc w przeglądarce wszystko działa, a Googlebot w nocy dostaje błąd.

Limit czasu między CDN a serwerem

Cloudflare i podobne usługi zwracają 502 albo 504, gdy serwer źródłowy nie odpowie w ustalonym czasie. W logu aplikacji nie ma śladu, bo żądanie dotarło za późno. Dotyczy zwłaszcza ciężkich listingów z filtrami.

WAF i ochrona przed botami

Część zapór wystawia stronę „sprawdzamy przeglądarkę” z kodem 503. Googlebot nie przejdzie wyzwania JavaScript, więc w raporcie wygląda to jak awaria.

Wtyczka albo aktualizacja CMS

Aktualizacja wtyczki w WordPressie czy PrestaShopie, która rzuca wyjątek. Często tylko na części szablonów: strona główna działa, wpisy z jedną taksonomią zwracają 500.

Prace serwisowe bez poprawnego 503

Tryb konserwacji z kodem 200 i komunikatem „wrócimy wkrótce” grozi zapisaniem strony jako soft 404. Z kolei 503 trzymany tygodniami kończy się wypadnięciem adresów z indeksu.

Limity zapytań

Aplikacja zwraca 503 lub 429 po przekroczeniu progu żądań na sekundę. Dokumentacja (zmniejszanie szybkości indeksowania) dopuszcza to jako hamowanie awaryjne na kilka godzin do 1-2 dni. Dłużej może skończyć się usunięciem adresów z indeksu.

Jak to potwierdzić

W Search Console kliknij adres, potem „Sprawdź URL” i uruchom test wersji opublikowanej. Pole „Pobranie strony” w sekcji Dostępność pokaże, czy Googlebot dalej dostaje 5xx (narzędzie do sprawdzania adresów URL).

Potem powtórz żądanie z własnej maszyny:

• curl -I -A "Googlebot/2.1" https://example.com/strona/ - czy serwer traktuje klienta z nazwą Googlebota inaczej niż przeglądarkę,
• curl -s -o /dev/null -w "%{http_code} %{time_total}" https://example.com/strona/ - kod i czas odpowiedzi, przydatne przy 504.

W logach znajdź wpisy 5xx z czasu skanowania podanego w Search Console. Jeśli log dostępu pokazuje 5xx, a log aplikacji milczy, błąd powstał w CDN, proxy albo serwerze WWW. IP robota sprawdź zgodnie z dokumentacją (weryfikacja żądań Googlebota): odwrotne DNS musi wskazać domenę googlebot.com albo google.com, a zwykłe DNS tej nazwy wrócić do tego samego IP.

Na koniec wyklucz przekierowanie: sprawdzarka przekierowań pokaże każdy krok łańcucha z kodem.

Jak to naprawić

1. Hosting: sprawdź w panelu zużycie procesów i pamięci w godzinie z logu. Podnieś limity albo włącz cache listingów.
2. CDN: wydłuż limit czasu na połączenie ze źródłem albo przyspiesz generowanie strony.
3. WAF: dodaj wyjątek dla zweryfikowanego Googlebota po zakresach IP, nie po nazwie klienta.
4. CMS: włącz log błędów PHP i odczytaj wyjątek. Wycofaj ostatnią aktualizację wtyczki, jeśli daty się zgadzają.
5. Prace serwisowe: zwracaj 503 z nagłówkiem Retry-After i statycznym HTML, jak w dokumentacji (tymczasowe wstrzymanie witryny). Szczegóły zbiera hasło o błędzie 503.
6. Limity zapytań: wyłącz je dla zweryfikowanych zakresów Google.
7. Po naprawie uruchom test wersji opublikowanej dla kilku adresów i kliknij „Sprawdź poprawkę”.

Kiedy to w porządku, a kiedy działać

Plik robots.txt to osobny przypadek. Według specyfikacji (jak Google interpretuje robots.txt) przy 5xx Google przez pierwsze 12 godzin przestaje skanować witrynę, potem do 30 dni używa ostatniej dobrej wersji, a po tym czasie zachowuje się tak, jakby pliku nie było. Sprawdź to w sprawdzarce robots.txt. Długa seria 5xx odbija się też w statusie Strona wykryta, obecnie niezindeksowana, bo robot odkłada skanowanie, żeby nie dociążać serwera.

Jak pilnować na co dzień

IndexRise co noc pobiera monitorowane adresy i zapisuje kod odpowiedzi. Kod 5xx na stronie, która we wzorcu odpowiadała 200, to zdarzenie krytyczne zgłaszane od razu, bez czekania na kolejne sprawdzenie, bo zwykle oznacza kłopot całego serwera. Jeśli Twój serwer często ma krótkie przerwy, w progach projektu możesz włączyć potwierdzanie. Kody 4xx potwierdzamy w kolejnym sprawdzeniu. Sytuację „nie udało się sprawdzić” (przekroczony czas, błąd DNS) raportujemy osobno od „strona odpowiedziała błędem”: pierwsza to problem z dostępnością, druga to konkretny kod do odszukania w logach. Zakres sprawdzeń opisuje strona o monitoringu SEO.