Błąd 500 na WordPressie — jak znaleźć przyczynę w 15 minut

500 Internal Server Error. Albo po polsku: „Wewnętrzny błąd serwera”. Czasem to szara strona z jedną linijką tekstu, czasem komunikat wystylizowany przez hosting.

Ten błąd bywa mylnie odbierany jako „coś się stało z serwerem”. W praktyce oznacza coś innego: serwer działa, ale aplikacja, którą uruchamia, przerwała pracę i nie potrafiła wytłumaczyć dlaczego. Kod 500 to worek na wszystko, czego nie da się przypisać do konkretniejszej kategorii.

Dobra wiadomość: prawdziwy powód prawie zawsze siedzi w logu. Wystarczy wiedzieć, gdzie zajrzeć.

Zacznij od logu, nie od zgadywania

To jedyna rada, która skraca naprawę z trzech godzin do dwudziestu minut.

W panelu hostingu poszukaj sekcji Logi albo Error log. Na DirectAdminie znajdziesz ją w zakładce statystyk domeny, na cPanelu pod nazwą Errors. Interesuje Cię ostatnie kilkanaście linii — mniej więcej z momentu, w którym zobaczyłeś błąd.

Równolegle włącz log WordPressa. W pliku wp-config.php:

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

Po odświeżeniu strony zajrzyj do wp-content/debug.log.

Z tych dwóch źródeł wyjdzie zwykle jedno z poniższych. Każde ma inną naprawę.

Uszkodzony plik .htaccess

Najczęstszy przypadek i najszybszy do sprawdzenia. Wystarczy jedna błędna reguła — dodana przez wtyczkę cache, wtyczkę bezpieczeństwa albo Ciebie przy okazji przekierowań.

Zmień przez FTP nazwę pliku .htaccess w katalogu głównym na .htaccess-old i odśwież stronę. Jeśli zadziałała, masz sprawcę. Wejdź w panelu w Ustawienia → Bezpośrednie odnośniki i kliknij „Zapisz zmiany” bez zmieniania czegokolwiek — WordPress wygeneruje czysty plik.

Jeżeli wcześniej miałeś tam własne przekierowania, dopisz je z powrotem pojedynczo, sprawdzając stronę po każdym. To męczące, ale inaczej nie dowiesz się, która reguła jest zła.

Przekroczony limit pamięci

W logu widać Allowed memory size of 134217728 bytes exhausted. WordPress nie zmieścił się w przydzielonej pamięci — jak podnieść limit i znaleźć, co go zjada.

W wp-config.php, powyżej linii z require_once:

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

Na wielu hostingach to nie wystarczy, bo limit narzuca konfiguracja serwera. Wtedy podnieś go w panelu hostingu albo napisz do dostawcy.

Zwróć jednak uwagę na sygnał, jaki daje ten błąd. Strona firmowa, która potrzebuje więcej niż 256 MB, ma gdzieś wtyczkę robiącą coś bardzo nieefektywnego. Podniesienie limitu jest plastrem, nie leczeniem.

Wtyczka albo motyw po aktualizacji

Klasyk. Aktualizacja przeszła, strona padła.

Jeśli masz dostęp do panelu, wyłącz wszystkie wtyczki naraz i włączaj po jednej. Jeśli panelu nie ma, przez FTP zmień nazwę katalogu wp-content/plugins na plugins-off — WordPress wyłączy wszystkie.

Motyw sprawdzisz analogicznie: zmień nazwę jego katalogu w wp-content/themes, a WordPress przełączy się na domyślny.

Tej sytuacji da się w dużej mierze uniknąć. Aktualizacje wykonywane najpierw na kopii testowej, a nie od razu na produkcji, to różnica między „padło i nie wiem czemu” a „nie wgraliśmy, bo się wysypało na teście”. Tak właśnie robimy aktualizacje u klientów, a jak przeprowadzić je samodzielnie i w dobrej kolejności — pokazuje nasz poradnik aktualizacji WordPressa.

Niewłaściwa wersja PHP

Hosting podniósł PHP z 7.4 na 8.3, a Twój motyw sprzed pięciu lat używa składni, która zniknęła. W logu zobaczysz Fatal error: Uncaught Error z nazwą funkcji.

Tymczasowe rozwiązanie: w panelu hostingu cofnij wersję PHP do poprzedniej. Docelowe: zaktualizuj albo wymień to, co nie działa. Zostawanie na starym PHP jest wygodne dokładnie tak długo, jak długo dostawca go utrzymuje — a potem awaria wraca, tylko już bez opcji cofnięcia.

Złe uprawnienia plików

Rzadziej, ale się zdarza — zwłaszcza po ręcznym wgrywaniu plików albo po migracji z innego serwera. Prawidłowe wartości to 755 dla katalogów i 644 dla plików. Jeżeli gdzieś widzisz 777, to nie tylko powód błędu, ale i realne zagrożenie bezpieczeństwa.

Uszkodzone pliki rdzenia

Przerwany transfer, nieudana aktualizacja, awaria dysku. Pobierz świeżą paczkę z wordpress.org i wgraj przez FTP katalogi wp-admin oraz wp-includes z nadpisaniem.

Nie ruszaj wp-content ani wp-config.php — tam są Twoje treści, motywy, wtyczki i dane dostępowe do bazy.

Czym 500 różni się od 502 i 504

Warto rozróżniać, bo naprawa jest zupełnie inna.

500 — aplikacja się wywaliła. Szukaj u siebie: wtyczki, motyw, PHP, .htaccess.

502 Bad Gateway i 504 Gateway Timeout — serwer pośredniczący nie dostał odpowiedzi na czas. To zwykle problem po stronie hostingu albo skutek zapytania, które trwa zbyt długo (import produktów, ciężki raport, backup w tle). Tutaj grzebanie we wtyczkach nic nie da.

Jeśli po białej stronie dostajesz akurat 500, warto też przeczytać, co oznacza biały ekran bez żadnego komunikatu — mechanizm jest podobny, ale diagnoza wygląda inaczej.

Ile to zwykle zajmuje

Przy dostępie do logu: 15–30 minut na ustalenie przyczyny i naprawę w typowym przypadku. Bez logu, metodą prób i błędów, potrafi zająć pół dnia — i właśnie dlatego zaczynamy od logu.

Jeśli w logu widzisz nazwy plików, których nie rozpoznajesz, funkcje typu eval albo długie ciągi zakodowane base64, to przestań naprawiać i przeczytaj, jak rozpoznać włamanie. Przy zainfekowanej stronie samo przywrócenie jej działania oznacza tylko tyle, że atakujący nadal ma dostęp.

---

Wolisz to zlecić? Zdiagnozujemy i naprawimy — sprawdzenie przyczyny nic nie kosztuje, a odpowiedź na zgłoszenie dostajesz w ciągu dwóch godzin w godzinach pracy. Naprawa rozliczana godzinowo, od 120 zł netto, płatność po wykonaniu.