Co to jest błąd serwera 5XX?

Błąd serwera 5XX to klasa kodów odpowiedzi HTTP (500, 502, 503, 504), którymi serwer informuje, że otrzymał żądanie, ale nie potrafił go obsłużyć. Pojawia się przy przeciążeniu hostingu, błędzie wtyczki WordPressa, przerwie technicznej lub awarii serwera pośredniczącego. Użytkownik widzi wtedy komunikat o błędzie zamiast strony, a Googlebot zwalnia crawlowanie, ignoruje treść z takiego adresu i przy dłuższej awarii usuwa go z indeksu.

Czym są kody 5xx i czym różnią się od błędów 4xx?

Kody 5xx to klasa odpowiedzi HTTP, którą standard RFC 9110 (sekcja 15.6) opisuje jako błędy serwera: serwer wie, że popełnił błąd albo nie jest w stanie wykonać żądania. Do tej klasy należą między innymi 500, 502, 503 i 504. Klasa 4xx oznacza błąd po stronie żądania: serwer działa poprawnie, ale zasobu nie ma pod podanym adresem albo klient nie ma do niego dostępu.

W praktyce różnica sprowadza się do tego, co jest zepsute. Przy błędzie 404 strona nie istnieje, a naprawa polega na przekierowaniu lub poprawie linku. Przy błędzie 5xx strona zwykle istnieje, tylko nie działa serwer, wtyczka albo pośrednik między użytkownikiem a serwerem, dlatego taki kod dotyczy najczęściej wielu adresów naraz albo całej witryny.

Trzeci przypadek to soft 404: serwer zwraca kod 200 przy stronie pustej albo z komunikatem „wystąpił błąd”. Dla Google to nie awaria, bo realny błąd serwera zawsze ma kod z klasy 5xx; taki adres jest dla niego po prostu podstroną bez treści.

Czym różni się błąd 500 od 502, 503 i 504?

Kod 500 to ogólny błąd aplikacji na serwerze, 502 i 504 to błędy serwera pośredniczącego (proxy, CDN), a 503 to sygnał, że serwer jest chwilowo niedostępny z powodu przeciążenia lub planowanej konserwacji. Definicje z RFC 9110 i najczęstsze przyczyny zestawia tabela.

W WordPressie kod 500 pojawia się najczęściej po aktualizacji wtyczki lub motywu, 502 i 504 przy LiteSpeed lub Cloudflare ustawionych przed serwerem, a 503 przy limitach hostingu współdzielonego. Kod 503 jest w tej grupie jedynym, który administrator może zwrócić świadomie, na przykład na czas prac na serwerze.

Jak Google traktuje błędy 5xx przy crawlowaniu i indeksowaniu?

Google w dokumentacji Search Central pisze, że błędy serwera 5xx (oraz 429) skłaniają jego roboty do tymczasowego spowolnienia crawlowania, a treść otrzymaną z adresu z kodem 5xx robot ignoruje. Adresy, które były już w indeksie, zostają w nim, ale przy utrzymującym się błędzie Google z czasem je usuwa. Dokumentacja nie podaje, po ilu dniach to następuje.

Spadek tempa crawlowania jest proporcjonalny do liczby adresów zwracających błąd serwera: jeden uszkodzony adres nie spowalnia robota na całej witrynie, ale awaria całego hostingu już tak. Gdy serwer znów odpowiada kodem 2xx, Google stopniowo zwiększa tempo crawlowania, ale nie wraca od razu do poprzedniego poziomu. Ile adresów robot pobiera z witryny w danym czasie, wyjaśnia wpis Co to jest crawl budget?

Inaczej wygląda planowana przerwa. Google zaleca, żeby przy krótkiej przerwie (1-2 dni) zwracać dla wszystkich adresów stronę informacyjną z kodem 503 i nagłówkiem Retry-After z datą lub czasem wznowienia. Kod 503 utrzymywany dłużej niż około 2 dni prowadzi do usuwania adresów z indeksu, a gdy przerwa liczy się w tygodniach, Google nie gwarantuje, kiedy wrócą.

Gdzie widać błędy 5xx na własnej stronie?

Błędy serwera pokazuje raport Statystyki indeksowania w Google Search Console (Ustawienia → Statystyki indeksowania). W sekcji „Według odpowiedzi” jest wiersz „Błąd serwera (5XX)” z udziałem procentowym w żądaniach robota, a udział rosnący z dnia na dzień oznacza, że serwer odrzuca coraz więcej żądań Googlebota. Cały raport omawiamy we wpisie Jak czytać raport Statystyki indeksowania w GSC.

Bieżący stan pojedynczej podstrony sprawdzisz poza Search Console: polecenie curl -I z jej adresem zwraca pierwszą linię odpowiedzi, na przykład HTTP/2 503, a w Chrome klawisz F12 i zakładka Network (Sieć) pokazują kod w kolumnie Status. Oba sposoby opisują stan z tej chwili, a raport w Search Console zbiera historię żądań robota, dlatego błąd, który wraca co jakiś czas, zobaczysz tylko w nim.

Jak rozpoznać przyczynę błędu 5xx po stronie hostingu i wtyczek?

Sam kod podpowiada warstwę, w której trzeba szukać przyczyny: 500 zwykle oznacza błąd aplikacji (WordPress, PHP, baza danych), 502 i 504 problem pośrednika lub infrastruktury hostingu, a 503 brak zasobów albo przerwę techniczną. Drugi trop to moment awarii: jeśli błąd pojawił się tuż po aktualizacji wtyczki lub motywu, najprawdopodobniej to ona go wywołała.

Osobny sygnał w tym samym raporcie to Stan hosta: gdy Google w ogóle nie może połączyć się z serwerem (nie chodzi tu o konkretny kod 5xx, tylko o brak odpowiedzi), panel oznacza to jako problem z łącznością. To dodatkowa wskazówka, że kłopot leży po stronie hostingu, a nie w samym WordPressie.

Typowe przyczyny po stronie WordPressa i hostingu:

• Błąd wtyczki lub motywu: konflikt po aktualizacji kończy się błędem krytycznym PHP (fatal error) i kodem 500 na całej stronie albo na jej części.
• Limity PHP: przekroczony memory_limit lub max_execution_time, na przykład przy imporcie produktów lub generowaniu dużego raportu.
• Baza danych: nie odpowiada, ma wyczerpany limit połączeń albo w wp-config.php są błędne dane dostępowe.
• Plik .htaccess: błędna składnia lub przekierowania w pętli po ręcznej edycji albo po zmianie ustawień wtyczki bezpieczeństwa.
• Limity hostingu: wyczerpany CPU, RAM lub liczba procesów na serwerze współdzielonym, zwykle jako 503 przy większym ruchu.
• CDN lub reverse proxy: LiteSpeed, Cloudflare lub inny pośrednik nie dostał na czas odpowiedzi od serwera źródłowego, stąd 502 lub 504 przy sprawnym WordPressie.
• Zapora aplikacji (WAF): zbyt agresywna reguła bezpieczeństwa odrzuca żądanie po stronie serwera.
• Przerwa techniczna hostingu: planowane prace, o których dostawca informuje na stronie statusu lub mailem.

Potwierdzenie daje log błędów, który znajdziesz w panelu hostingu (sekcja „Logi” lub „Error log”) albo w pliku wp-content/debug.log, jeśli w wp-config.php włączono WP_DEBUG_LOG. Wpis ze słowami „Fatal error” i ścieżką do folderu wtyczki wskazuje sprawcę bez zgadywania.

Co zrobić natychmiast, gdy strona zwraca błąd 5xx?

Najpierw ustal, czy błąd widzi każdy, czy tylko Google, a potem sprawdź ostatnią zmianę na stronie. Kolejność działań:

Ten wpis kończy się na diagnozie i pierwszych krokach, bo naprawa błędu 500 w WordPressie krok po kroku (tryb odzyskiwania, podnoszenie limitów PHP, naprawa bazy) wymaga osobnej instrukcji.

Jakie pojęcia wiążą się z błędem serwera 5xx?

• Crawlowanie i indeksowanie: pobranie strony przez robota i dodanie jej do indeksu to dwa różne etapy; przy błędzie 5xx pierwszy się nie udaje (Google ignoruje taką odpowiedź), a z czasem cofa się drugi. Oba porównujemy we wpisie Crawlowanie a indeksowanie: czym się różnią?
• Crawl budget: liczba adresów, które robot Google pobiera z witryny w danym czasie; odpowiedzi 5xx obniżają ją tym mocniej, im więcej adresów zwraca błąd.
• Retry-After: nagłówek HTTP w odpowiedzi 503, który podaje datę lub liczbę sekund do ponowienia żądania; Google zaleca go przy planowanej przerwie.
• Kod 429 Too Many Requests: odpowiedź „za dużo żądań”, formalnie z klasy 4xx, ale Google traktuje ją jak błąd serwera i też zwalnia po niej crawlowanie.
• Błąd 404 i soft 404: brak zasobu przy sprawnym serwerze oraz strona bez treści z kodem 200; oba dotyczą pojedynczych adresów, nie stanu serwera.

FAQ

Źródła

• RFC 9110 „HTTP Semantics”, sekcja 15.6 „Server Error 5xx” (15.6.1, 15.6.3, 15.6.4, 15.6.5): rfc-editor.org/rfc/rfc9110
• Google Search Central, „Kody stanu HTTP oraz błędy sieci i DNS”: developers.google.com
• Google Search Central, „Wstrzymanie lub zamknięcie działalności online”: developers.google.com