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

HTTP 500 oznacza, że serwer napotkał problem, którego nie potrafił poprawnie obsłużyć podczas realizacji żądania. Sam kod nie wskazuje jednak przyczyny. W WordPressie może wynikać z błędu PHP, wtyczki, motywu, konfiguracji serwera, reguły w .htaccess albo problemu występującego jeszcze przed pełnym uruchomieniem aplikacji.

Dlatego najskuteczniejsza diagnostyka nie zaczyna się od kasowania plików ani zwiększania wszystkich limitów PHP. Najpierw trzeba ustalić, które żądanie zwraca 500, kiedy problem się pojawił i co zapisano wtedy w logach.

Błąd 500 jest kodem odpowiedzi, a nie diagnozą. Najwięcej informacji daje połączenie czasu wystąpienia błędu, logu serwera lub PHP oraz wiedzy o ostatniej zmianie wykonanej na stronie.

Co oznacza HTTP 500?

Specyfikacja HTTP opisuje kod 500 jako Internal Server Error: serwer napotkał nieoczekiwany warunek, który uniemożliwił mu wykonanie żądania.

To celowo szeroka definicja. Kod 500 nie mówi, czy źródłem problemu jest PHP, WordPress, konfiguracja Apache, proxy, uprawnienia do pliku czy jeszcze inna warstwa.

W praktyce dwa serwisy mogą zwracać identyczne HTTP 500 z całkowicie różnych powodów. Dlatego sam komunikat widoczny w przeglądarce zwykle nie wystarcza do naprawy.

Najpierw sprawdź, gdzie dokładnie występuje błąd

Przed zmianą konfiguracji warto ustalić zakres problemu.

Sprawdź osobno:

stronę główną,
zwykły wpis lub podstronę,
/wp-admin/,
/wp-login.php,
konkretną operację, która wywołała błąd, na przykład zapis wpisu, upload lub checkout.

Jeżeli 500 pojawia się tylko przy jednej operacji, diagnoza będzie inna niż wtedy, gdy cała domena przestaje odpowiadać.

Przykładowo błąd tylko przy imporcie może kierować uwagę na kod tej operacji, pamięć lub timeout. Błąd na każdym URL po edycji .htaccess znacznie mocniej wskazuje na konfigurację serwera.

Log błędów jest ważniejszy niż sam ekran 500

WordPress może pokazać tylko ogólny komunikat, podczas gdy log PHP zawiera konkretny fatal error, plik oraz numer linii.

Najlepsza procedura to:

zanotować dokładny czas,
wykonać jedną czynność powodującą 500,
sprawdzić wpisy z tego samego przedziału czasu,
jeśli to możliwe, zawęzić je do tego samego URI lub żądania,
znaleźć pierwszy istotny błąd dotyczący tej operacji.

Jeżeli potrzebujesz pomocy przy interpretacji wpisów, zobacz poradnik Logi błędów PHP i WordPress — jak czytać error_log i debug.log?.

Jeśli błąd pojawił się po jednej zmianie, zacznij właśnie od niej

Czas wystąpienia problemu jest jednym z najcenniejszych sygnałów diagnostycznych.

Jeżeli strona działała poprawnie, a HTTP 500 pojawił się bezpośrednio po:

aktualizacji wtyczki,
aktualizacji motywu,
zmianie wersji PHP,
edycji .htaccess,
wdrożeniu własnego kodu,
zmianie konfiguracji serwera,

to najpierw warto sprawdzić właśnie ten element. Nie dowodzi to jeszcze przyczyny, ale pozwala ograniczyć liczbę zmiennych.

Diagnostyka jest znacznie trudniejsza, gdy jednocześnie aktualizuje się WordPressa, kilkanaście wtyczek, PHP i konfigurację hostingu. Przy pracach produkcyjnych dobrze więc rozdzielać większe zmiany na osobne kroki.

Wtyczka lub motyw jako źródło fatal errora

Wtyczki

Błąd w pluginie może zakończyć wykonanie PHP jeszcze zanim WordPress wygeneruje prawidłową odpowiedź.

Jeżeli log wskazuje plik konkretnej wtyczki albo problem pojawił się zaraz po jej aktualizacji, można przeprowadzić kontrolowany test z jej wyłączeniem.

Gdy panel WordPressa działa, najbezpieczniej wyłączyć podejrzaną wtyczkę standardowo i ponowić dokładnie tę samą operację.

Jeżeli panel jest niedostępny, WordPress opisuje procedurę polegającą na tymczasowej zmianie nazwy katalogu wp-content/plugins, wejściu do /wp-admin/plugins.php w celu oznaczenia brakujących rozszerzeń jako nieaktywnych, a następnie przywróceniu nazwy katalogu. Wszystkie zwykłe wtyczki można potem aktywować pojedynczo i obserwować, przy której problem wraca.

Trzeba też pamiętać o mu-plugins oraz kodzie ładowanym przez hosting lub własną aplikację. Zmiana nazwy zwykłego katalogu pluginów nie wyłącza każdej możliwej warstwy rozszerzeń WordPressa.

Motyw

Motyw jest kodem wykonywanym przez WordPress tak samo jak plugin. Błąd składni, niezgodność z wersją PHP albo problem w functions.php może doprowadzić do HTTP 500.

Jeżeli log wskazuje katalog aktywnego motywu albo problem pojawił się po jego aktualizacji, warto wykonać test z motywem domyślnym na stagingu lub w kontrolowanych warunkach.

Nie należy kasować aktywnego motywu bez przygotowania. Jeżeli witryna zawiera child theme albo własne modyfikacje, przypadkowa operacja na katalogach może utrudnić późniejsze odtworzenie stanu.

.htaccess, permissions i ownership mogą zatrzymać żądanie przed WordPressem

Na serwerach korzystających z Apache lub zgodnej obsługi plików .htaccess błędna dyrektywa może spowodować błąd konfiguracji. Dyrektywa niedozwolona w danym kontekście, nieodpowiedni AllowOverride albo błąd składni mogą doprowadzić do HTTP 500 jeszcze przed pełnym uruchomieniem WordPressa.

To ważne, ponieważ w takim przypadku WordPress może w ogóle nie dojść do etapu, na którym zapisze coś do własnego debug.log. Właściwego komunikatu trzeba wtedy szukać w logu serwera WWW.

Jeżeli błąd pojawił się bezpośrednio po zmianie .htaccess, zamiast edytować kolejne ustawienia PHP warto najpierw przywrócić ostatnią poprawną wersję tego pliku.

Po migracji, rozpakowaniu kopii albo zmianie właściciela plików warto sprawdzić również błędy dostępu do plików i katalogów. Nie należy jednak mechanicznie ustawiać szerokich uprawnień typu 777 jako sposobu naprawy HTTP 500. Właściwe prawa i ownership zależą od architektury serwera oraz sposobu uruchamiania PHP.

Błąd PHP może wyglądać dokładnie jak problem z serwerem

HTTP 500 może być końcowym efektem fatal errora PHP.

Typowe wpisy to między innymi:

PHP Fatal error: Uncaught TypeError: ...

albo:

Allowed memory size of ... bytes exhausted

W pierwszym przypadku trzeba analizować konkretny kod i stack trace. W drugim wiadomo jedynie, że wykonywany skrypt przekroczył aktywny limit pamięci.

Podniesienie memory_limit może być uzasadnione dla rzeczywiście ciężkiej operacji, ale nie powinno zastępować sprawdzenia, dlaczego zużycie pamięci było tak wysokie.

Relacje między memory_limit, czasem wykonywania i innymi parametrami opisuje poradnik Limity PHP na hostingu.

Zmiana wersji PHP może ujawnić stary lub niezgodny kod

Jeżeli HTTP 500 pojawił się bezpośrednio po przełączeniu wersji PHP, rozsądnym pierwszym rollbackiem jest powrót do poprzedniej działającej wersji, jeśli hosting nadal ją udostępnia.

Następnie można spokojnie sprawdzić logi i zgodność komponentów.

Duży skok między wersjami PHP może ujawnić kod korzystający z usuniętych funkcji, niezgodnych typów albo konstrukcji, które wcześniej były jedynie ostrzeżeniem.

Pełną procedurę takiej zmiany opisuje poradnik Jak zmienić wersję PHP na hostingu i nie zepsuć WordPressa?.

500 po zapisie, imporcie albo checkout może mieć inną przyczynę niż 500 na całej stronie

Zakres błędu często mówi więcej niż sam kod HTTP.

Jeżeli strona główna działa, a 500 występuje tylko przy jednej ciężkiej operacji, warto sprawdzić:

log PHP dokładnie z czasu tej operacji,
zużycie pamięci,
czas wykonywania,
wywoływany plugin lub integrację,
zewnętrzne API, z którym aplikacja próbuje się połączyć.

Jeżeli natomiast każdy URL zaczyna zwracać 500 natychmiast, większe znaczenie mają błędy składni, bootstrap aplikacji, konfiguracja PHP albo serwera.

Ta różnica pozwala uniknąć sytuacji, w której problem checkoutu diagnozuje się przez przebudowę całego .htaccess.

Brak wpisu w debug.log nie wyklucza problemu

debug.log WordPressa powstaje dopiero wtedy, gdy spełnione są warunki jego działania. Jeżeli błąd występuje wcześniej — na poziomie serwera WWW, konfiguracji PHP albo jeszcze przed uruchomieniem mechanizmów WordPressa — plik może nie zawierać przydatnego wpisu.

Dlatego przy HTTP 500 warto sprawdzać również właściwy server/PHP error log. WP_DEBUG_LOG jest narzędziem do debugowania aplikacji WordPress, a nie pełnym logiem całego stosu serwera.

Nie zmieniaj kilku rzeczy naraz

Jednym z najczęstszych błędów diagnostycznych jest jednoczesne:

wyłączenie wszystkich wtyczek,
zmiana motywu,
podniesienie limitów PHP,
usunięcie .htaccess,
wyczyszczenie cache,
zmiana wersji PHP.

Jeśli strona zacznie wtedy działać, nadal nie wiadomo, która zmiana rozwiązała problem.

Lepsza metoda to jedna hipoteza i jeden test. Po każdej zmianie powtórz tę samą operację oraz zanotuj wynik.

Kiedy warto przywrócić backup?

Backup jest zabezpieczeniem, ale nie zawsze pierwszym narzędziem diagnostycznym.

Jeżeli wiadomo, że awaria pojawiła się bezpośrednio po wdrożeniu konkretnych plików, prostszy może być rollback właśnie tego wdrożenia. Jeżeli zmieniono tylko wersję PHP, szybciej przywrócić poprzedni interpreter.

Pełne odtworzenie kopii ma większy sens, gdy:

nie wiadomo, które pliki lub dane zostały zmienione,
aktualizacja objęła jednocześnie wiele komponentów,
doszło do uszkodzenia danych,
nie ma pewnego sposobu ręcznego cofnięcia zmian.

Przed odtworzeniem trzeba także uwzględnić dane, które powstały już po wykonaniu backupu, szczególnie w sklepie lub serwisie często zapisującym informacje.

Kiedy problem jest raczej po stronie hostingu?

Sam HTTP 500 nie wystarcza, aby przypisać winę operatorowi.

Więcej wskazuje na warstwę hostingową, gdy:

problem występuje również dla prostego statycznego pliku albo minimalnego skryptu PHP niezależnego od WordPressa — zależnie od tego, którą warstwę chcesz sprawdzić,
log serwera pokazuje błąd konfiguracji lub procesu, którego użytkownik nie kontroluje,
kilka niezależnych aplikacji na koncie zaczyna mieć problemy jednocześnie,
panel pokazuje awarię usługi lub procesu,
support potwierdza problem po stronie infrastruktury.

Z kolei fatal error wskazujący konkretny plik wtyczki jest znacznie mocniejszym tropem aplikacyjnym.

Przy podejrzeniu problemów z CPU, RAM, procesami albo I/O można dodatkowo zestawić logi z diagnostyką zasobów hostingu.

Bezpieczna procedura diagnostyki HTTP 500

Ustal zakres. Cała strona, wp-admin czy jedna operacja?
Zanotuj dokładny czas.
Odtwórz problem jednym żądaniem.
Sprawdź server/PHP error log.
Jeśli WordPress działa wystarczająco daleko, sprawdź także kontrolowany debug.log.
Zidentyfikuj pierwszy istotny błąd dotyczący tego żądania.
Powiąż problem z ostatnią zmianą.
Przetestuj jedną hipotezę.
Po każdej zmianie powtórz ten sam test.
Po rozwiązaniu problemu przywróć bezpieczne ustawienia produkcyjne i wyłącz tymczasowe debugowanie.

Jeżeli po tych krokach nie masz dostępu do właściwego logu albo błąd wskazuje warstwę zarządzaną przez operatora, wtedy warto przekazać supportowi dokładny czas testu, URL, kod odpowiedzi i znalezione wpisy zamiast samej informacji „WordPress pokazuje 500”.

Najważniejsze wnioski

HTTP 500 jest ogólnym kodem błędu serwera i sam nie wskazuje źródła problemu;
najważniejszym źródłem diagnostycznym jest właściwy log z czasu konkretnego żądania;
wtyczki, motyw, PHP, .htaccess oraz problemy z dostępem do plików mogą prowadzić do podobnego efektu widocznego w przeglądarce;
brak wpisu w debug.log nie wyklucza błędu na wcześniejszej warstwie;
po zmianie wersji PHP warto najpierw rozważyć szybki rollback interpretera, a następnie diagnozować zgodność;
błąd przy jednej operacji należy diagnozować inaczej niż 500 obejmujący całą stronę;
zmiana kilku elementów jednocześnie utrudnia znalezienie rzeczywistej przyczyny;
pełne odtworzenie backupu nie zawsze jest pierwszym ani najbezpieczniejszym krokiem;
nie należy używać 777 jako uniwersalnej naprawy problemów z uprawnieniami;
przed zgłoszeniem problemu hostingowi warto zebrać czas zdarzenia, URL, log i zakres awarii.

Źródła

RFC 9110 — HTTP Semantics — znaczenie odpowiedzi 500 Internal Server Error.
WordPress Developer Resources — Debugging in WordPress — WP_DEBUG, WP_DEBUG_LOG i diagnostyka błędów.
WordPress Documentation — FAQ Troubleshooting — procedura dezaktywacji pluginów bez dostępu do panelu.
WordPress Documentation — Manage Plugins — zarządzanie i diagnozowanie rozszerzeń.
Apache HTTP Server — .htaccess files — kontekst dyrektyw, AllowOverride i diagnostyka błędów konfiguracji.
PHP Manual — Errors and Logging Configuration — konfiguracja logowania i wyświetlania błędów PHP.