Błąd 500 w WordPress – jak zdiagnozować i naprawić Internal Server Error

Błąd 500 to ogólny komunikat serwera HTTP, który mówi tyle: coś poszło nie tak, ale serwer nie potrafi wskazać, co konkretnie. To najczęstszy i jednocześnie najbardziej frustrujący błąd WordPress, bo w odróżnieniu od błędu 404 czy 403 nie zdradza przyczyny.

Kod 500 należy do rodziny błędów 5xx, czyli problemów po stronie serwera, nie przeglądarki. To ważne rozróżnienie: czyszczenie cache, cookies czy zmiana przeglądarki nic nie da, bo problem leży w konfiguracji serwera, pliku PHP albo bazie danych.

Błąd 500 może objawiać się różnie i każdy wariant wskazuje na inną przyczynę:
- Cała strona nie działa – frontend i wp-admin
- Działa frontend, ale wp-admin zwraca 500 – zwykle wtyczka panelu lub limit pamięci
- Tylko niektóre podstrony – błąd .htaccess lub przekierowań
- Błąd dopiero po zalogowaniu – konflikt wtyczki działającej w kontekście użytkownika

Strona może działać rano i paść po południu – bo wtyczka zaktualizowała się automatycznie, hosting przełączył wersję PHP albo skończył się limit pamięci przy większym ruchu. Dobra wiadomość: w 90% przypadków da się to naprawić samodzielnie w kilka minut, jeśli postępujesz systematycznie zamiast losowo wyłączać wtyczki.

Zanim zaczniesz cokolwiek zmieniać, warto wiedzieć, czego szukać. Poniższa tabela porządkuje typowe przyczyny błędu 500 według tego, jak często je spotykamy, wraz z gotowym kierunkiem naprawy. To skraca diagnostykę z godzin do minut.

Kolejność na liście nie jest przypadkowa – odpowiada ona kolejności kroków diagnostycznych poniżej. Zaczynamy od przyczyn najczęstszych i najłatwiejszych do sprawdzenia, schodząc do tych rzadszych i bardziej pracochłonnych.

Logi to pierwsza rzecz, do której sięgamy. Sprawdzenie logu wskazuje dokładną przyczynę w zdecydowanej większości przypadków i oszczędza godziny zgadywania.

Panel hostingu (cPanel, DirectAdmin, CloudPanel): wejdź do sekcji Logi > Error Log. Szukaj wpisów z datą i godziną zbliżoną do momentu wystąpienia błędu.

Włącz tryb debugowania WordPress – dodaj do wp-config.php przed linią z komentarzem That is all:

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

Po odświeżeniu strony zajrzyj do pliku `wp-content/debug.log`. Znajdziesz tam dokładny komunikat z nazwą pliku i numerem linii, która wywołała awarię.

Najczęstsze komunikaty i ich znaczenie:
- `Allowed memory size exhausted` – za mało pamięci PHP
- `Call to undefined function` – uszkodzona lub niekompatybilna wtyczka
- `syntax error` – błąd składni w pliku (np. po edycji functions.php)
- `WordPress database error` – problem z bazą danych

Po zakończeniu diagnozy wyłącz WP_DEBUG (ustaw na false). Na produkcji aktywne logi wyświetlane na ekranie to ryzyko bezpieczeństwa – mogą ujawnić ścieżki serwera i fragmenty kodu.

Poniższa procedura prowadzi od przyczyn najczęstszych do najrzadszych. Wykonuj kroki po kolei – po każdym sprawdzaj, czy strona wróciła do życia.

Krok 1 – Napraw .htaccess. Połącz się przez FTP/SFTP (FileZilla, WinSCP) lub menedżer plików hostingu. W głównym katalogu WordPress zmień nazwę pliku `.htaccess` na `.htaccess-old` i odśwież stronę. Jeśli działa – plik był uszkodzony; wejdź w Ustawienia > Bezpośrednie odnośniki i kliknij Zapisz, by wygenerować nowy. Jeśli nie pomaga, przywróć nazwę i idź dalej.

Krok 2 – Wyłącz wtyczki. W `wp-content/plugins/` zmień nazwę folderu `plugins` na `plugins-off` i odśwież stronę. Jeśli działa – winna jest jedna z wtyczek. Przywróć nazwę i włączaj wtyczki pojedynczo (zmieniając nazwy ich folderów), sprawdzając stronę po każdej.

Krok 3 – Wyłącz motyw. W `wp-content/themes/` zmień nazwę aktywnego motywu (np. `astra` na `astra-off`). WordPress przełączy się na domyślny Twenty Twenty-Five. Jeśli pomogło – problem jest w motywie; zaktualizuj go lub zgłoś autorowi.

Krok 4 i 5 – zwiększenie limitu pamięci oraz naprawa rdzenia i bazy opisane są w kolejnych sekcjach.

Nie chcesz przechodzić przez to ręcznie pod presją czasu? W ramach stałej opieki nad WordPress przejmujemy diagnostykę i naprawę takich awarii, zanim klient zdąży je zauważyć.

WordPress domyślnie przydziela 64–128 MB pamięci PHP. Rozbudowane strony, sklepy WooCommerce i ciężkie buildery często potrzebują więcej, zwłaszcza w panelu administracyjnym.

Limit podniesiesz w jednym z trzech miejsc:

W wp-config.php (przed That is all):

define('WP_MEMORY_LIMIT', '256M');

W php.ini (jeśli masz dostęp):

memory_limit = 256M
max_execution_time = 120

W .htaccess (Apache):

php_value memory_limit 256M

Uwaga praktyczna: nie każdy hosting na to pozwala. Tanie hostingi współdzielone często blokują zmiany powyżej 128 MB, niezależnie od tego, co wpiszesz. Jeśli realnie potrzebujesz więcej, rozważ hosting z konfigurowalnymi limitami PHP, np. CyberFolks.

Jeśli 256 MB nie pomaga, problem nie leży w limicie, lecz w wtyczce, która zjada pamięć w pętli. Wróć do kroku z wyłączaniem wtyczek – pamięć to często objaw, nie przyczyna.

Jeśli wcześniejsze kroki nie pomogły, problem leży głębiej – w plikach rdzenia, bazie danych albo konfiguracji serwera.

Uszkodzony rdzeń WordPress (np. po przerwanej aktualizacji):
1. Pobierz świeżą paczkę z wordpress.org i rozpakuj
2. Wgraj przez FTP foldery `wp-admin/` i `wp-includes/`, nadpisując istniejące
3. NIE nadpisuj `wp-content/` ani `wp-config.php` – tam są Twoje treści i ustawienia

Uszkodzona baza danych:
1. Dodaj do wp-config.php: `define('WP_ALLOW_REPAIR', true);`
2. Otwórz `twojadomena.pl/wp-admin/maint/repair.php` i kliknij Repair Database
3. Po naprawie USUŃ tę linię – pozostawiona, jest dziurą bezpieczeństwa, bo repair.php nie wymaga logowania

Wersja PHP: sprawdź w panelu hostingu, czy hosting nie przełączył jej automatycznie. W 2026 roku bezpieczny wybór to PHP 8.1 lub 8.2. Zbyt nowa bywa niekompatybilna ze starszymi wtyczkami, zbyt stara – z rdzeniem.

Uprawnienia plików: po migracji serwera często sypią się prawa dostępu. Standard to katalogi 755, pliki 644, a wp-config.php nawet 600. Nieprawidłowe uprawnienia (np. 777 albo 444) potrafią wywołać błąd 500.

Część przyczyn błędu 500 leży poza WordPressem i poza Twoim zasięgiem – tu jedynym sensownym ruchem jest zgłoszenie do supportu hostingu.

Skontaktuj się z hostingiem, gdy:
- W logach widzisz `503 Service Unavailable` lub `Premature end of script headers` mimo czystej instalacji – to często przeciążenie serwera lub limit procesów po stronie dostawcy
- Błąd pojawia się losowo, na różnych podstronach, bez związku z Twoimi zmianami
- Nie masz dostępu do logów ani edycji php.ini, a panel nie pozwala zmienić wersji PHP
- Strona działała i nagle padła, choć niczego nie zmieniałeś – mogła to być zmiana po stronie infrastruktury

Zgłaszając problem, podaj konkret: dokładną godzinę wystąpienia, treść komunikatu z error logu i listę ostatnich działań (aktualizacja, import, migracja). Im więcej danych, tym szybciej support namierzy przyczynę.

Krótkotrwały błąd 500 raczej nie zaszkodzi SEO. Googlebot, gdy natrafia na kod 5xx, rozumie go jako tymczasową niedostępność serwera i wraca później, zamiast od razu usuwać stronę z indeksu. Jednorazowa awaria na kilkanaście minut przejdzie bez konsekwencji.

Problem zaczyna się, gdy błąd 500 utrzymuje się długo lub wraca regularnie:
- Google ogranicza budżet indeksowania (crawl budget), bo traktuje serwer jako niestabilny
- Strony niedostępne przez dłuższy czas mogą spaść w wynikach
- Przy bardzo długiej niedostępności (dni) bywają usuwane z indeksu

Dlatego ważne jest, by serwer w trakcie awarii zwracał kod 500 lub 503, a nie 200 z pustą stroną. Kod 503 z nagłówkiem Retry-After to najczystszy sygnał dla Google podczas planowanej przerwy. Jeśli strona miała już problemy z indeksacją, połącz naprawę z porządkiem w optymalizacji on-page.

Błąd 500 to nie jedyny błąd serwera, jaki możesz spotkać. Rozróżnienie ich jest kluczowe, bo prowadzą do innych ścieżek naprawy – a łatwo je pomylić, zwłaszcza za proxy w rodzaju Cloudflare.

Niuans z naszej praktyki: gdy korzystasz z Cloudflare lub innego CDN, kod widoczny w przeglądarce może pochodzić od proxy, a nie od Twojego serwera. Cloudflare często zwraca 502 lub 520 w sytuacji, którą serwer raportuje wewnętrznie jako 500. Zanim zaczniesz naprawiać WordPressa, sprawdź stronę bezpośrednio (np. przez plik hosts wskazujący na IP serwera). To prosty trik, który oszczędza godziny naprawiania nie tego problemu, co trzeba.

Większości awarii 500 da się uniknąć rutyną, nie heroizmem. Cztery nawyki, które realnie redukują ryzyko:

1. Backup przed każdą aktualizacją – pełna kopia plików i bazy, automatyczna i trzymana poza serwerem. To różnica między 5-minutowym rollbackiem a paniczną odbudową.
2. Aktualizuj pojedynczo – wtyczki po jednej, sprawdzając stronę po każdej; wtedy od razu wiesz, co coś popsuło.
3. Monitoruj logi i dostępność – zewnętrzny monitoring uptime powiadomi Cię o błędzie szybciej niż klient.
4. Trzymaj aktualne PHP i testuj na stagingu – większe zmiany rób najpierw na kopii testowej.

Poniższa checklista podsumowuje, co zrobić, gdy błąd 500 znów się pojawi:

Jeśli ten przewodnik Ci pomógł, sprawdź też powiązane awarie WordPress – każda opisana diagnostycznie, od symptomów po procedurę naprawy:

• Biały ekran śmierci (WSoD) – diagnoza i naprawa – częsty bliźniak błędu 500, gdy WordPress nie zwraca żadnego komunikatu.
• WordPress padł po aktualizacji – rollback – jak bezpiecznie cofnąć feralną aktualizację.
• WordPress zhackowany – jak wyczyścić stronę – gdy za błędem stoi złośliwy kod.
• WordPress wolno się ładuje – diagnoza – gdy serwer balansuje na granicy limitów.

Nie potrafisz zdiagnozować problemu samodzielnie? Napisz do nas przez formularz kontaktowy – bezpłatnie ocenimy, z czym masz do czynienia, i zasugerujemy najszybszą ścieżkę naprawy.

Nie chcesz grzebać w tym sam i ryzykować pogłębienia awarii? Naprawimy Twój WordPress – diagnoza w 30 minut, pełna naprawa od 299 zł, z miesięczną opieką w pakiecie.