Błąd 500: co oznacza i jak go naprawić

W tym artykule dowiesz się, co oznacza błąd 500, jak reaguje na niego Google i jak go naprawić w 7 krokach. Błąd 500 (HTTP 500 Internal Server Error) to kod odpowiedzi HTTP, którym serwer informuje, że trafił na nieoczekiwany problem i nie może obsłużyć żądania. Naprawa: znajdź błędne URL-e w Google Search Console i crawlerze, przeczytaj logi serwera, usuń przyczynę i zgłoś poprawkę w GSC.

Artykuł jest dla właściciela strony i początkującego SEO-wca, który zobaczył na stronie komunikat „500 Internal Server Error” albo w Google Search Console status „Błąd serwera (5xx)”. Dokumentacja Google i dane w artykule są aktualne na październik 2026.

Błąd 500 w skrócie: co oznacza i skąd się bierze

Błąd 500 to odpowiedź serwera z kodem statusu HTTP 500, która oznacza, że serwer odebrał poprawne żądanie, ale coś po jego stronie się zepsuło. Standard HTTP RFC 9110 definiuje kod 500 jako „nieoczekiwany stan, który uniemożliwił serwerowi wykonanie żądania”. Według dokumentacji MDN kod 500 jest ogólną odpowiedzią „catch-all”, której serwer używa, gdy nie ma bardziej pasującego kodu z grupy 5xx.

Kod 500 należy do klasy 5xx, czyli błędów serwera, w odróżnieniu od klasy 4xx, czyli błędów po stronie żądania (np. błąd 404). Według RFC 9110 serwer zwracający kod z klasy 5xx powinien dołączyć opis błędu i informację, czy problem jest tymczasowy, czy trwały. Kod 500 sam w sobie nie mówi ani o przyczynie, ani o czasie trwania awarii, dlatego diagnoza błędu 500 zawsze zaczyna się od logów serwera.

Komunikat błędu 500 wygląda różnie w zależności od serwera i CMS-a: „500 Internal Server Error”, „HTTP Error 500”, „Wewnętrzny błąd serwera” albo w WordPressie „There has been a critical error on this website” (Na tej stronie wystąpił błąd krytyczny). Najczęstsze przyczyny błędu 500 to:

• błąd w kodzie po stronie serwera, np. fatal error w PHP po aktualizacji wtyczki, motywu albo wersji PHP;
• błędna dyrektywa w pliku .htaccess na serwerze Apache lub LiteSpeed;
• przekroczony limit pamięci PHP (memory_limit) albo limit czasu wykonania skryptu;
• złe uprawnienia plików i katalogów, np. skrypt bez prawa odczytu;
• brak połączenia z bazą danych albo uszkodzona tabela;
• przeciążenie serwera przy nagłym ruchu albo agresywnym crawlu botów.

Błąd 500 prawie nigdy nie jest winą odwiedzającego. Odwiedzający może odświeżyć stronę po minucie albo otworzyć ją w innej przeglądarce. Według poradnika OVHcloud, jeśli błąd 500 nie występuje w innej przeglądarce, problem nie leży po stronie hostingu.

Błąd 500, 502, 503, 504 i kody Cloudflare: porównanie

Kody z klasy 5xx różnią się miejscem awarii. Definicje kodów 500–504 pochodzą z RFC 9110, a kody 52x z dokumentacji Cloudflare.

Dokumentacja Cloudflare zaznacza, że przyczyny błędu 5xx nie zawsze widać w logach serwera źródłowego, więc przy stronie za CDN trzeba sprawdzić też load balancery, cache, proxy i firewalle po drodze. Moim zdaniem przy stronie za Cloudflare najpierw warto ustalić, czy kod 500 wysyła serwer źródłowy, czy warstwa pośrednia, bo od tej odpowiedzi zależy, do kogo pisać zgłoszenie.

Jak Google reaguje na błąd 500

Google traktuje błąd 500 jako sygnał przeciążenia serwera. Według dokumentacji Google o kodach statusu HTTP (aktualizacja z 4.02.2026) kody 5xx i 429 powodują, że roboty Google tymczasowo zwalniają crawlowanie, a przy kodzie 500 Google zmniejsza tempo crawlowania tym bardziej, im więcej URL-i zwraca błąd. Po powrocie odpowiedzi 2xx Google stopniowo przywraca tempo crawlowania.

Błąd 500 trwający dłużej usuwa strony z indeksu. Dokumentacja Google o kodach statusu HTTP podaje, że URL-e już zaindeksowane zostają w indeksie, ale w końcu wypadają, a potok indeksowania usuwa URL-e, które stale zwracają błąd serwera. Google nie podaje twardej liczby dni.

Najbliższym oficjalnym progiem jest strona Google o ograniczaniu tempa crawlowania Googlebota (aktualizacja z 6.10.2026). Google pozwala zwrócić kod 500, 503 albo 429 zamiast 200, żeby spowolnić crawl, ale tylko na „kilka godzin albo 1–2 dni”. Według tej samej strony, jeśli Googlebot widzi kody błędu na tym samym URL-u przez kilka dni, strona może wypaść z indeksu Google.

Błąd 500 na pliku robots.txt działa na całą witrynę. Według specyfikacji robots.txt w dokumentacji Google, gdy robots.txt zwraca kod 5xx:

1. Przez pierwsze 12 godzin Google przestaje crawlować witrynę i ponawia pobieranie robots.txt.
2. Przez kolejne 30 dni Google używa ostatniej poprawnej wersji robots.txt z cache, a gdy jej nie ma, zakłada brak ograniczeń.
3. Po 30 dniach Google zachowuje się jak przy braku robots.txt, jeśli witryna jest ogólnie dostępna, albo wstrzymuje crawlowanie, jeśli witryna ma problemy z dostępnością.

Specyfikacja robots.txt dodaje, że timeouty i błędy DNS Google traktuje tak samo jak błędy serwera. Dlatego robots.txt sprawdzam przy każdym błędzie 500 jako pierwszy URL: jeden plik z kodem 500 potrafi zatrzymać crawl całej domeny. Szczegóły o tym, jak spowolniony crawl przekłada się na liczbę odwiedzanych stron, opisałem we wpisie o crawl budget.

Błąd 500 a 503: który kod zwrócić przy przerwie technicznej

Kod 503 jest właściwą odpowiedzią na planowaną przerwę, a kod 500 opisuje awarię, której nikt nie planował. Wpis na blogu Google Search Central z 2011 roku zaleca na czas prac serwisowych kod 503 zamiast strony z kodem 404 albo 200. Według tego wpisu Googlebot może użyć opcjonalnego nagłówka Retry-After (czas przerwy w sekundach albo data końca), żeby zdecydować, kiedy wrócić.

Kod 503 nie jest ochroną bez limitu. Ten sam wpis Google z 2011 roku ostrzega, że długo trwające 503 mogą zostać uznane za trwałą niedostępność serwera i skończyć się usunięciem URL-i z indeksu. Aktualna dokumentacja Google o kodach statusu HTTP opisuje 500, 502 i 503 wspólnie jako błędy 5xx, więc dla Google liczy się przede wszystkim czas trwania awarii.

WordPress obsługuje oba kody automatycznie. Funkcja wp_maintenance() w pliku wp-includes/load.php zwraca podczas aktualizacji (plik .maintenance) kod 503 z nagłówkiem Retry-After: 600, czyli 10 minut. Ekran błędu krytycznego z klasy WP_Fatal_Error_Handler wysyła kod 500. Komunikat „Na tej stronie wystąpił błąd krytyczny” w WordPressie oznacza więc dla Googlebota zwykły błąd 500.

Jak naprawić błąd 500 w 7 krokach

Naprawa błędu 500 to najpierw ustalenie zakresu awarii (jeden URL czy cała strona), a dopiero potem szukanie przyczyny. Kroki układam od diagnozy do potwierdzenia poprawki:

1. Sprawdź raport Indeksowanie stron w Google Search Console. Status „Błąd serwera (5xx)” w raporcie Indeksowanie stron oznacza, że serwer zwrócił Googlebotowi błąd z grupy 500. Przykładowe URL-e przetestuj w Narzędziu do sprawdzania adresów URL przyciskiem „Testuj wersję opublikowaną”. Pomoc Google ostrzega, że błędy serwera bywają przejściowe, więc test na żywo może przejść, choć crawl Google się nie udał. Obsługę obu narzędzi opisałem w poradniku Google Search Console: jak korzystać.
2. Sprawdź stan hosta w raporcie Statystyki indeksowania. Raport Statystyki indeksowania (Ustawienia w Google Search Console) pokazuje według pomocy Google stan hosta, wykres łączności z serwerem i odpowiedzi według kodów. Odpowiedzi „Błąd serwera (5XX)” powodują ostrzeżenia o dostępności, a stan hosta bez problemów Google oznacza kolorem zielonym.
3. Zrób crawl strony. W Screaming Frog SEO Spider filtr Server Error (5XX) w zakładce Response Codes pokazuje URL-e z kodem 500 i 503, a filtr No Response pokazuje timeouty i odrzucone połączenia. Według instrukcji Screaming Frog błędy 5xx podczas crawla mogą wskazywać serwer, który nie wytrzymuje obciążenia. W takim przypadku obniż liczbę wątków crawla i powtórz test.
4. Przeczytaj logi serwera. Log błędów serwera WWW (error.log w Apache i Nginx) i log PHP zapisują konkretną linię kodu, która wywołała błąd 500. Log dostępu (access.log) pokazuje, od kiedy kod 500 się pojawia i czy dotyczy Googlebota, czy wszystkich odwiedzających.
5. Cofnij ostatnią zmianę. Błąd 500 najczęściej pojawia się zaraz po aktualizacji wtyczki, motywu, wersji PHP albo edycji pliku .htaccess. Przywrócenie poprzedniej wersji jednego elementu szybciej potwierdza przyczynę niż przegląd całej konfiguracji.
6. W WordPressie przejdź listę kontrolną z dokumentacji. Dokumentacja WordPressa wskazuje jako najczęstszą przyczynę błędu 500 uszkodzony plik .htaccess i zaleca zmianę jego nazwy przez FTP, a potem ponowne zapisanie ustawień w Ustawienia > Bezpośrednie odnośniki. Kolejne kroki to wyłączenie wszystkich wtyczek, przełączenie na domyślny motyw, podniesienie limitu pamięci PHP i ponowne wgranie katalogów wp-admin i wp-includes.
7. Zgłoś poprawkę w Google Search Console. Po usunięciu wszystkich wystąpień błędu kliknij „Sprawdź poprawkę” na stronie szczegółów statusu „Błąd serwera (5xx)”. Według pomocy Google walidacja trwa zwykle do około dwóch tygodni i nie warto klikać przycisku ponownie przed jej zakończeniem.

Debugowanie WordPressa włączają trzy stałe w pliku wp-config.php. Według dokumentacji WordPressa o debugowaniu poniższe ustawienie zapisuje błędy do pliku wp-content/debug.log i nie pokazuje ich odwiedzającym:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Plik debug.log leży w katalogu wp-content, czyli w katalogu publicznym strony, dlatego po diagnozie wyłączam WP_DEBUG i usuwam log. Limit pamięci WordPressa ustawia stała WP_MEMORY_LIMIT: według dokumentacji wp-config.php domyślnie wynosi 40 MB dla pojedynczej strony i 64 MB dla multisite, a przykładowa zmiana to define( 'WP_MEMORY_LIMIT', '96M' );. Jeśli zmiana w wp-config.php nie działa, dokumentacja WordPressa zaleca edycję php.ini albo prośbę do hostingu o wyższy limit.

Przykład: błędy serwera w audycie bynajmniej.pl

Crawl Screaming Frog bynajmniej.pl z 14.10.2026 (441 wewnętrznych URL-i) pokazał 25 stron, które linkują do adresów z kodem 4xx lub 5xx. Raport z tego crawla grupuje 4xx i 5xx razem, więc na jego podstawie nie da się powiedzieć, ile linków prowadzi do błędu 500. Ten sam crawl wykazał, że 92 ze 186 wewnętrznych przekierowań kończy się błędem lub brakiem odpowiedzi. Pełne wyniki opisałem w poradniku jak zrobić audyt SEO.

Wniosek z audytu bynajmniej.pl dla błędu 500: filtr zbiorczy „4xx lub 5xx” trzeba rozbić na osobne filtry Client Error (4xx) i Server Error (5XX) w zakładce Response Codes, bo naprawa obu grup jest inna. Link do strony z kodem 404 poprawia się w treści, a link do strony z kodem 500 wymaga naprawy serwera.

Błąd 500 a AI Overviews i AI Mode

Strona z trwałym błędem 500 traci też widoczność w odpowiedziach AI Google. Według dokumentacji Google o funkcjach AI (aktualizacja z 10.12.2025) strona może być linkiem źródłowym w AI Overviews albo AI Mode tylko wtedy, gdy jest zaindeksowana i kwalifikuje się do wyświetlenia w wyszukiwarce z fragmentem. URL, który wypadł z indeksu przez błąd 500, nie spełnia tego warunku.

Twórcy ChatGPT, Claude i Perplexity nie publikują zasad, jak ich crawlery reagują na kody 5xx. Moim zdaniem rozsądnie jest założyć, że strona niedostępna w chwili wizyty bota AI po prostu nie trafi do odpowiedzi, i nie budować na tym żadnej strategii.

Czego nie robić przy błędzie 500

• Nie ukrywaj błędu 500 pod kodem 200. Strona z komunikatem o awarii i kodem 200 wygląda dla Google jak zwykła strona, a wpis Google z 2011 roku wymienia odpowiedź 200 przy błędach serwera jako częsty problem.
• Nie zwracaj kodu 500 ani 503 dłużej niż 1–2 dni w celu spowolnienia Googlebota. Google dopuszcza taki zabieg tylko na kilka godzin albo 1–2 dni.
• Nie przekierowuj stron z błędem 500 na stronę główną. Przekierowanie ukrywa awarię w raportach, a nie usuwa jej przyczyny.
• Nie zostawiaj WP_DEBUG_DISPLAY włączonego na produkcji, bo komunikaty PHP pokazują odwiedzającym ścieżki plików na serwerze.
• Nie zakładaj, że błąd 500 naprawia się sam po wyczyszczeniu cache przeglądarki. Cache przeglądarki to porada dla odwiedzającego, a właściciel strony ma w ręku logi serwera, choć poradniki „wyczyść cache wyszukiwarki” wciąż wiszą wysoko w wynikach wyszukiwania.

FAQ: najczęstsze pytania o błąd 500

Co oznacza błąd 500?

Błąd 500 (Internal Server Error) oznacza, że serwer trafił na nieoczekiwany problem i nie może obsłużyć poprawnego żądania. Kod 500 jest ogólny, więc konkretną przyczynę pokazują dopiero logi serwera.

Czy błąd 500 to wina użytkownika?

Błąd 500 to prawie zawsze problem po stronie serwera albo aplikacji, nie odwiedzającego. Odwiedzający może jedynie odświeżyć stronę po chwili, sprawdzić inną przeglądarkę i zgłosić awarię właścicielowi strony.

Czy błąd 500 szkodzi SEO?

Krótki błąd 500 tylko spowalnia crawlowanie, a Google przywraca tempo po powrocie odpowiedzi 2xx. Błąd 500 utrzymujący się na tym samym URL-u przez kilka dni może według dokumentacji Google usunąć stronę z indeksu.

Czym różni się błąd 500 od 503?

Kod 500 oznacza nieoczekiwaną awarię, a kod 503 chwilową niedostępność, np. przeciążenie albo prace serwisowe. Przy planowanej przerwie Google od 2011 roku zaleca kod 503 z opcjonalnym nagłówkiem Retry-After.

Jak naprawić błąd 500 w WordPressie?

Błąd 500 w WordPressie naprawia się zwykle przez zmianę nazwy pliku .htaccess, wyłączenie wtyczek, przełączenie na domyślny motyw albo podniesienie limitu pamięci PHP. Konkretną przyczynę pokazuje plik wp-content/debug.log po włączeniu WP_DEBUG i WP_DEBUG_LOG.

Jak długo trwa walidacja błędu serwera w Google Search Console?

Walidacja poprawki statusu „Błąd serwera (5xx)” w Google Search Console trwa według pomocy Google zwykle do około dwóch tygodni. Przycisku „Sprawdź poprawkę” nie trzeba klikać ponownie, dopóki walidacja się nie zakończy.

Paweł Zinkiewicz

Członek zarządu i współwłaściciel agencji IF.PL, w SEO od ponad 20 lat (m.in. Gazeta.pl, Wirtualna Polska, Polska Press). Na bynajmniej.pl piszę z pomocą AI: temat, dane i testy są moje, AI pomaga ubrać to w słowa.