Błędy serwera 5XX – co oznaczają kody 500, 502, 503 i jak je naprawić

Kody 5XX to błędy serwera: żądanie było poprawne, ale serwer (albo stojący przed nim proxy, CDN czy load balancer) nie potrafił go obsłużyć. Najczęściej spotkasz 500 Internal Server Error (ogólna awaria, zwykle błąd w kodzie lub konfiguracji), 502 Bad Gateway i 504 Gateway Timeout (problem między serwerem pośredniczącym a docelowym) oraz 503 Service Unavailable (chwilowe przeciążenie lub prace serwisowe). Google przy błędach 5XX zwalnia indeksowanie, a adresy, które zwracają je uporczywie, z czasem usuwa z indeksu.

Wyobraź sobie, że wchodzisz do restauracji, składasz poprawne zamówienie, a kelner wraca z kuchni z zakłopotaną miną: „Najmocniej przepraszam, ale nie możemy zrealizować zamówienia. W kuchni wybuchł pożar”. Twoje zamówienie (żądanie HTTP) było bezbłędne, ale zawiodło zaplecze restauracji (serwer). To jest właśnie esencja błędów z rodziny 5XX: serwer przyznaje się do porażki, a dostęp do strony tracą jednocześnie użytkownicy i roboty wyszukiwarek.

W tym artykule wyjaśniam, co oznacza każdy kod 5XX (także niestandardowe kody Cloudflare 520–530), jak Google reaguje na błędy serwera i jak bezpiecznie użyć kodu 503 przy pracach serwisowych. Pokazuję też, gdzie szukać błędów 5XX w Google Search Console i jak dojść do ich przyczyny. To trzecia część serii o kodach odpowiedzi HTTP. Wcześniej pisałem o kodach odpowiedzi 3xx (przekierowaniach) i o błędach 404 i 410 (kody 4XX).

Co oznaczają kody 5XX (błędy serwera)?

Kod odpowiedzi HTTP to trzycyfrowa liczba, którą serwer dołącza do każdej odpowiedzi. Pierwsza cyfra określa klasę: 2XX to sukces, 3XX to przekierowania, 4XX to błędy po stronie klienta, a 5XX to błędy po stronie serwera. Według specyfikacji HTTP (RFC 9110) kod 5XX oznacza, że serwer wie, że popełnił błąd albo nie jest w stanie wykonać żądania.

Różnica między 4XX a 5XX jest ważna w diagnozie. Przy 404 serwer działa poprawnie, tylko nie ma żądanej treści. Przy 500 czy 503 problem leży w infrastrukturze: w kodzie aplikacji, konfiguracji serwera, bazie danych, limitach zasobów albo w łańcuchu serwerów pośredniczących. Jako użytkownik zwykle niewiele możesz zrobić poza odświeżeniem strony po chwili. Naprawa jest po stronie właściciela witryny lub hostingu.

Lista kodów 5XX – tabela

Poniżej zebrałem kody 5XX, które możesz spotkać w praktyce. Pierwsze sześć definiuje główna specyfikacja HTTP (RFC 9110), pozostałe pochodzą z rozszerzeń protokołu.

Kod	Nazwa	Co oznacza	Co zwykle sprawdzić
500	Internal Server Error	Serwer napotkał nieoczekiwany stan, który uniemożliwił obsłużenie żądania. Kod ogólny, „coś poszło nie tak”.	Logi błędów serwera i PHP, ostatnie zmiany w kodzie, wtyczkach, .htaccess, limity pamięci.
501	Not Implemented	Serwer nie obsługuje funkcji potrzebnej do realizacji żądania, np. nie rozpoznaje metody HTTP.	Rzadki na zwykłych stronach. Częściej dotyczy API lub nietypowych metod żądania.
502	Bad Gateway	Serwer działający jako brama lub proxy dostał nieprawidłową odpowiedź od serwera, z którym się łączył.	Czy działa backend (np. PHP-FPM, aplikacja za Nginx), czy proces się nie wysypał, konfiguracja proxy/CDN.
503	Service Unavailable	Serwer chwilowo nie może obsłużyć żądania z powodu przeciążenia lub prac serwisowych. Może wysłać nagłówek Retry-After.	Tryb konserwacji, limity hostingu, skoki ruchu i botów, zabezpieczenia (WAF, rate limiting).
504	Gateway Timeout	Brama lub proxy nie otrzymały odpowiedzi od serwera docelowego w wyznaczonym czasie.	Długie zapytania do bazy, wolne skrypty, zewnętrzne API, limity czasu w proxy i PHP.
505	HTTP Version Not Supported	Serwer nie obsługuje głównej wersji protokołu HTTP użytej w żądaniu.	Bardzo rzadki. Konfiguracja serwera lub nietypowy klient.
507	Insufficient Storage	Serwer nie ma miejsca, aby zapisać dane potrzebne do wykonania żądania (rozszerzenie WebDAV, RFC 4918).	Wolne miejsce na dysku i limity konta hostingowego.
508	Loop Detected	Serwer przerwał operację, bo wykrył nieskończoną pętlę (rozszerzenie WebDAV, RFC 5842).	Niektóre panele hostingowe zwracają 508 także przy przekroczeniu limitów zasobów konta.
511	Network Authentication Required	Klient musi uwierzytelnić się w sieci, zanim uzyska dostęp (np. portal logowania w hotelowym Wi-Fi). Definiuje go RFC 6585.	Nie dotyczy zwykle samej strony, tylko sieci, z której łączy się użytkownik.

Istnieją też rzadko spotykane kody 506 (Variant Also Negotiates) i 510 (Not Extended), ale w codziennej pracy z WordPressem i SEO praktycznie się z nimi nie zetkniesz.

Kody 520–530 – niestandardowe błędy Cloudflare

Jeśli strona działa za Cloudflare, możesz zobaczyć kody, których nie ma w specyfikacji HTTP. To niestandardowe kody Cloudflare. Cloudflare zwraca je, gdy coś pójdzie nie tak na drodze między jego serwerami a Twoim serwerem źródłowym (origin). Opis za dokumentacją Cloudflare:

• 520 – Web server returns an unknown error: serwer źródłowy zwrócił pustą, nieznaną lub nieoczekiwaną odpowiedź (np. po awarii procesu, zbyt dużych nagłówkach albo blokadzie adresów IP Cloudflare).
• 521 – Web server is down: serwer źródłowy odrzuca połączenia od Cloudflare, bo jest wyłączony albo firewall blokuje adresy IP Cloudflare.
• 522 – Connection timed out: Cloudflare nie zdołał nawiązać połączenia z serwerem źródłowym albo nie dostał potwierdzenia żądania w wyznaczonym czasie.
• 523 – Origin is unreachable: Cloudflare nie może dotrzeć do serwera źródłowego, np. przez błędny rekord DNS lub problem z routingiem.
• 524 – A timeout occurred: połączenie się udało, ale serwer nie wysłał odpowiedzi HTTP przed upływem limitu czasu (według aktualnej dokumentacji domyślnie 125 sekund; klienci planu Enterprise mogą go wydłużyć do 6000 sekund). Typowa przyczyna to długo działający skrypt lub ciężkie zapytanie do bazy.
• 525 – SSL handshake failed: nie udało się nawiązać połączenia SSL/TLS między Cloudflare a serwerem (tryb SSL Full lub Full (Strict)).
• 526 – Invalid SSL certificate: Cloudflare nie może zweryfikować certyfikatu SSL na serwerze źródłowym (tryb Full (Strict)).
• 530: Cloudflare nie może rozwiązać nazwy hosta serwera źródłowego. Szczegóły podaje dodatkowy kod błędu 1XXX w treści odpowiedzi.

W starszych poradnikach znajdziesz też kod 527, związany z wycofaną usługą Railgun. W aktualnej dokumentacji Cloudflare już go nie ma. Ważne dla diagnozy: przy kodach 52X przyczyny prawie zawsze szukasz na własnym serwerze lub w konfiguracji połączenia z Cloudflare, a nie w samym Cloudflare.

500 Internal Server Error – enigmatyczny błąd ogólny

To bez wątpienia najsłynniejszy i najczęściej spotykany błąd z tej rodziny. Komunikat Internal Server Error jest ogólnym, zbiorczym sygnałem, że na serwerze wystąpiła awaria, ale system nie jest w stanie (albo nie chce) precyzyjnie określić jej natury. Sama strona błędu zwykle niewiele mówi, dlatego odpowiedzi trzeba szukać w logach.

Najczęstsze przyczyny i jak je diagnozować?

Kluczem do rozwiązania zagadki jest analiza logów błędów serwera (np. error.log w Apache i Nginx, log błędów PHP albo logi dostępne w panelu hostingu; w IIS m.in. Podgląd zdarzeń Windows). Do najczęstszych winowajców należą:

• Błędy w skryptach (np. PHP, Python), w tym błędy krytyczne po aktualizacji wtyczki, motywu lub wersji PHP.
• Nieprawidłowa konfiguracja pliku .htaccess (literówka w dyrektywie, nieobsługiwany moduł).
• Nieprawidłowe uprawnienia do plików i folderów.
• Przekroczenie limitów zasobów serwera, przede wszystkim pamięci PHP (memory_limit) i czasu wykonania skryptu (max_execution_time).
• Problemy z połączeniem z bazą danych (choć WordPress w takiej sytuacji często pokazuje osobny komunikat o błędzie połączenia z bazą).

502 Bad Gateway i 504 Gateway Timeout – problem w łańcuchu serwerów

Oba kody pojawiają się tam, gdzie między przeglądarką a aplikacją stoi serwer pośredniczący: reverse proxy (np. Nginx przed PHP-FPM lub Node.js), load balancer albo CDN. Różnica jest prosta:

• 502 Bad Gateway: pośrednik połączył się z serwerem docelowym, ale dostał od niego nieprawidłową odpowiedź albo połączenie zostało zerwane. Typowe przyczyny to zatrzymany lub przeciążony proces PHP-FPM, awaria aplikacji, błędna konfiguracja proxy. Jak wygląda taki układ serwerów, opisałem w porównaniu Apache, Nginx i LiteSpeed.
• 504 Gateway Timeout: pośrednik nie doczekał się odpowiedzi w wyznaczonym czasie. Serwer docelowy żyje, ale odpowiada za wolno: przez ciężkie zapytania do bazy, wolne zewnętrzne API, crony uruchamiane przy żądaniu czy brak cache.

Jeśli 504 pojawia się sporadycznie, przy obciążeniu, to zwykle znak, że serwer generuje strony na granicy wydolności. Ten sam problem widać wcześniej w wysokim czasie odpowiedzi serwera. Sposoby na jego skrócenie opisałem w artykule jak poprawić TTFB (Time to First Byte).

503 Service Unavailable – planowany przestój czy potężna broń SEO?

Błąd 503 Service Unavailable informuje, że serwer chwilowo nie może obsłużyć żądania z powodu przeciążenia lub planowanych prac konserwacyjnych. Specyfikacja HTTP zakłada, że stan ten minie po pewnym czasie, a serwer może podpowiedzieć klientowi, kiedy spróbować ponownie, w nagłówku Retry-After (w sekundach, np. Retry-After: 3600, albo jako data).

Prawidłowo użyty, kod 503 jest cennym narzędziem SEO. Google w swoich wytycznych zaleca, aby przy krótkim, celowym wyłączeniu strony (np. na 1–2 dni) zwracać stronę informacyjną z kodem 503, a nie np. 404, 403 czy zwykłą stronę z kodem 200. Dzięki temu komunikat „przerwa techniczna” nie trafi do indeksu jako treść Twojej strony. Kilka zasad:

• Zwracaj 503 tylko na krótko. Google podaje, że wyłączenie całej witryny powinno trwać najwyżej kilka dni. W starszym wpisie na blogu Google Search Central czytamy, że Googlebot ponawia próby pobrania stron z kodem 503 przez mniej więcej tydzień, a potem traktuje błąd jako trwały i strony mogą wypaść z wyników.
• Dodaj nagłówek Retry-After z szacowanym czasem powrotu. Google traktuje go jako wskazówkę, kiedy wrócić, a nie gwarancję.
• Nie zwracaj 503 dla pliku robots.txt. Według dokumentacji Google to blokuje całe indeksowanie witryny.
• Sprawdź kod odpowiedzi, np. narzędziem curl -I. Wiele wtyczek „maintenance mode” pokazuje ładną stronę, ale nie każda zwraca przy tym kod 503.

Jeśli stronę przerwy technicznej robisz sam, w PHP wystarczą dwie linijki na samym początku skryptu:

<?php
http_response_code(503);
header('Retry-After: 3600'); // spróbuj ponownie za godzinę
// tu treść strony „Wracamy za chwilę”
exit;

Sam WordPress robi to poprawnie: na czas aktualizacji tworzy plik .maintenance i jego domyślna strona przerwy odpowiada kodem 503 z nagłówkiem Retry-After: 600.

Uwaga na przesadne oczekiwania: w dokumentacji Google kody 500, 502 i 503 są opisane jednakowo. Wszystkie spowalniają indeksowanie, a adresy, które zwracają je uporczywie, wypadają z indeksu. 503 nie jest więc „tarczą” na dowolnie długi czas. Jego przewaga polega na tym, że jasno komunikuje stan tymczasowy i nie pozwala zaindeksować strony zastępczej.

501 a 503 – czym się różnią?

Kod 501 Not Implemented oznacza, że serwer w ogóle nie obsługuje danej funkcji, np. metody HTTP, i nie zanosi się, żeby to się zmieniło po chwili. Kod 503 Service Unavailable mówi coś odwrotnego: serwer zasadniczo potrafi obsłużyć żądanie, ale w tej chwili nie może (przeciążenie, konserwacja), więc warto spróbować później. Na zwykłej stronie internetowej 501 widuje się rzadko, a 503 to codzienność przy pracach serwisowych i przeciążeniach.

Skąd się wzięły kody 5XX – krótka historia

Specyfikacja HTTP/1.0 (RFC 1945 z 1996 roku) opisywała już cztery kody: 500 Internal Server Error, 501 Not Implemented, 502 Bad Gateway i 503 Service Unavailable. Wraz z rozwojem internetu architektura serwerowa stawała się coraz bardziej złożona: pojawiało się coraz więcej serwerów pośredniczących (proxy), bram (gateways) i systemów równoważenia obciążenia (load balancers). Pierwsza specyfikacja HTTP/1.1 (RFC 2068 z 1997 roku) dodała 504 Gateway Timeout i 505 HTTP Version Not Supported. Kolejne kody, np. 507, 508 i 511, wprowadziły osobne dokumenty RFC. Dziś podstawowe kody 5XX definiuje RFC 9110 z 2022 roku.

Jak błędy 5XX wpływają na postrzeganie strony przez Googlebota?

Reakcja robotów Google na błędy 5XX jest wieloetapowa i zależy od skali oraz czasu trwania problemu. Dokumentacja Google opisuje ją dość ogólnie, bez sztywnych terminów, więc poniższe etapy traktuj jako uproszczony model.

• Reakcja natychmiastowa (krótkoterminowa): Googlebot ignoruje treść odpowiedzi z kodem 5XX i spróbuje pobrać adres ponownie później. Strony już zaindeksowane na razie pozostają w indeksie. Pojedynczy, krótki błąd serwera nie powinien zaszkodzić widoczności.
• Spowolnienie indeksowania (średnioterminowe): błędy 5XX i kod 429 sprawiają, że Google tymczasowo zwalnia indeksowanie witryny. Według dokumentacji spadek jest proporcjonalny do liczby adresów zwracających błąd serwera. To mechanizm ochronny: Google nie chce dodatkowo obciążać serwera, który ma problemy. Efektem jest wolniejsze indeksowanie nowych treści i zmian na całej stronie, czyli realnie mniejszy crawl budget. Gdy serwer znów odpowiada kodem 2XX, Google stopniowo zwiększa tempo.
• Usunięcie z indeksu (długoterminowe): adresy, które uporczywie zwracają błąd serwera, są w końcu usuwane z indeksu. To prowadzi do bezpośredniej utraty widoczności i ruchu organicznego. Jeśli problem dotyczy całej witryny, może ona niemal całkowicie zniknąć z wyników do czasu naprawy.

Dwie rzeczy, o których łatwo zapomnieć. Po pierwsze, kod 429 Too Many Requests (np. z agresywnego firewalla czy limitu żądań) Google traktuje jak błąd serwera, a nie zwykły błąd 4XX. Po drugie, szczególnie groźne są błędy 5XX przy pobieraniu pliku robots.txt. Według dokumentacji Google przez pierwsze 12 godzin Google wstrzymuje wtedy indeksowanie witryny. Potem przez maksymalnie 30 dni korzysta z ostatniej dobrej wersji pliku i nadal próbuje pobrać nową. Co dzieje się po 30 dniach, zależy od tego, czy reszta witryny jest dla Google dostępna.

Jak sprawdzić błędy 5XX w Google Search Console?

W Search Console błędy serwera widać w kilku miejscach:

• Raport „Statystyki indeksowania” (Ustawienia usługi > Statystyki indeksowania). W sekcji Stan hosta zobaczysz, czy w ostatnich 90 dniach Googlebot miał problemy z dostępnością: z plikiem robots.txt, DNS lub połączeniem z serwerem. Tabela odpowiedzi według typu pokazuje odsetek żądań zakończonych kodem Błąd serwera (5XX), a po kliknięciu wiersza przykładowe adresy i godziny. Raport jest dostępny tylko dla usług najwyższego poziomu (domena lub główny prefiks URL).
• Raport „Indeksowanie stron”: status Błąd serwera (5xx) pokazuje adresy, przy których serwer zwrócił błąd, gdy Google próbował je pobrać.
• Narzędzie do sprawdzania adresów URL: test na żywo pozwala sprawdzić, czy konkretny adres odpowiada Googlebotowi poprawnie teraz, po naprawie.

Zwróć uwagę, że w Statystykach indeksowania liczone są żądania, a nie adresy. Jeśli Google pobierze ten sam adres dwa razy i raz dostanie 500, a raz 200, raport pokaże 50% błędów serwera. Pojedyncze, historyczne piki zwykle nie wymagają działań. Martwić powinny błędy powtarzające się albo utrzymujące się przez dłuższy czas.

Jak znaleźć przyczynę błędu 5XX? Diagnoza krok po kroku

1. Ustal zakres. Czy błąd dotyczy całej strony, jednego adresu, panelu administracyjnego, czy tylko części żądań (np. Googlebota lub ruchu z określonego kraju)? Sprawdź kod odpowiedzi poleceniem curl -I https://twojadomena.pl/adres/ i zanotuj, czy odpowiada Twój serwer, czy np. Cloudflare. Przy setkach adresów pomoże masowe sprawdzanie kodów odpowiedzi w Pythonie.
2. Przejrzyj logi. Log błędów serwera i PHP zwykle wprost podaje przyczynę: plik, linię kodu i komunikat. W logach dostępu (access log) sprawdzisz, od kiedy pojawiają się kody 5XX i których adresów oraz klientów dotyczą.
3. Sprawdź limity PHP. Komunikat Allowed memory size of … bytes exhausted oznacza wyczerpanie pamięci (memory_limit, w WordPressie także stała WP_MEMORY_LIMIT). Maximum execution time of … seconds exceeded to przekroczony czas wykonania skryptu (max_execution_time). Długie operacje kończą się też często kodem 504 po stronie proxy.
4. W WordPressie wyłącz podejrzane wtyczki. Najczęstszą przyczyną błędu 500 w WordPressie jest konflikt lub błąd po aktualizacji wtyczki, motywu albo PHP. Od wersji 5.2 WordPress wyświetla wtedy komunikat o błędzie krytycznym i wysyła administratorowi e-mail z linkiem do trybu odzyskiwania (recovery mode), w którym możesz wyłączyć winną wtyczkę. Jeśli nie masz dostępu do panelu, zmień przez FTP nazwę katalogu wtyczki w wp-content/plugins.
5. Włącz tryb debugowania. W wp-config.php ustaw WP_DEBUG i WP_DEBUG_LOG na true, a WP_DEBUG_DISPLAY na false. Błędy trafią wtedy do pliku wp-content/debug.log i nie będą wyświetlane odwiedzającym. Po diagnozie wyłącz debugowanie.
6. Sprawdź .htaccess, uprawnienia i ostatnie zmiany. Jeśli błąd pojawił się po wdrożeniu, cofnięcie ostatniej zmiany to często najszybsza diagnoza.
7. Sprawdź zasoby i ruch. Przy błędach 503 i 508 na hostingu współdzielonym zajrzyj do statystyk zużycia zasobów w panelu. Przyczyną bywa też nagły ruch botów albo zbyt agresywne reguły zabezpieczeń.

Jak monitorować i zapobiegać błędom 5XX?

Błędy 5XX wymagają proaktywnego podejścia. Kluczowe działania to:

• Monitoring: używaj narzędzi do monitorowania dostępności (np. UptimeRobot), które powiadomią Cię o awarii, zanim zauważą ją klienci. Regularnie sprawdzaj raport „Statystyki indeksowania” w Google Search Console.
• Dobre praktyki: wybieraj renomowany hosting, regularnie aktualizuj oprogramowanie i testuj zmiany na środowisku testowym (staging) przed wdrożeniem. Rób kopie zapasowe przed każdą większą aktualizacją.
• Optymalizacja: dbaj o wydajność kodu i zapytań do bazy danych, korzystaj z cache stron. Szybszy serwer to mniej przekroczonych limitów czasu i mniej błędów przy skokach ruchu.

Jeśli błędy 5XX powtarzają się, a ich przyczyna nie jest oczywista, warto przejrzeć stronę całościowo. W ramach audytu SEO sprawdzam m.in. statystyki indeksowania w Search Console, kody odpowiedzi i wydajność serwera.

FAQ – błędy serwera 5XX

Czy błąd 500 może być winą mojego komputera lub przeglądarki?

Prawie nigdy. Kody 5XX oznaczają problem po stronie serwera. Jako użytkownik możesz odświeżyć stronę po chwili, ale naprawić błąd może tylko właściciel strony lub hosting. Wyjątkiem jest kod 511, który dotyczy sieci, z której się łączysz (np. Wi-Fi z ekranem logowania).

Czy błędy 5XX obniżają pozycje w Google?

Krótkie, pojedyncze błędy nie powinny mieć wpływu. Problemem są błędy powtarzające się lub długotrwałe: Google zwalnia wtedy indeksowanie, a adresy uporczywie zwracające błąd serwera usuwa z indeksu, co oznacza utratę ruchu z tych adresów.

Jak długo strona może zwracać kod 503?

Google zaleca 503 przy wyłączeniu strony na 1–2 dni i podkreśla, że wyłączenie całej witryny powinno trwać najwyżej kilka dni. Według starszego wpisu Google Googlebot ponawia próby przez około tydzień, potem błąd może zostać uznany za trwały.

Czy Google respektuje nagłówek Retry-After?

Google opisuje go jako wskazówkę, z której Googlebot może skorzystać przy planowaniu ponownej wizyty. Nie traktuj go jako gwarancji, że robot wróci dokładnie o wskazanej porze ani że 503 ochroni stronę przez dowolnie długi czas.

Czy kod 429 to błąd serwera?

Formalnie 429 Too Many Requests należy do klasy 4XX. Google traktuje go jednak jak błąd serwera: sygnał przeciążenia, który spowalnia indeksowanie. Długotrwałe zwracanie 429 Googlebotowi działa podobnie jak długotrwałe błędy 5XX.

Co oznacza błąd 520, 522 lub 524?

To niestandardowe kody Cloudflare. 520 to nieoczekiwana odpowiedź serwera źródłowego, 522 to przekroczony czas nawiązywania połączenia, a 524 to zbyt długie oczekiwanie na odpowiedź serwera. Przyczyna leży zwykle na Twoim serwerze, a nie w Cloudflare.

Czym różni się 502 od 504?

Przy 502 serwer pośredniczący dostał od serwera docelowego nieprawidłową odpowiedź (albo połączenie zostało zerwane). Przy 504 nie dostał żadnej odpowiedzi w wyznaczonym czasie. 502 częściej oznacza awarię backendu, 504 jego przeciążenie lub zbyt wolne skrypty.

W skrócie: pojedynczy błąd 5XX to nie powód do paniki, ale powtarzające się 500, 502 czy 504 to sygnał, że serwer nie wyrabia albo coś się w nim zepsuło. Zacznij od logów, przy pracach serwisowych zwracaj 503 z Retry-After i pilnuj, żeby plik robots.txt nigdy nie odpowiadał błędem 5XX.