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

Według RFC 9110, sekcja 15.6.1 kod 500 oznacza nieoczekiwany stan serwera, który uniemożliwił obsłużenie żądania. To informacja o skutku, a nie diagnoza. Podobny ekran może towarzyszyć błędowi PHP, konfiguracji serwera albo problemowi infrastruktury.

Otwórz narzędzia przeglądarki, przejdź do Network i sprawdź status głównego dokumentu. Przy problemie po kliknięciu sprawdź żądanie wywołane tą czynnością. Zapisz, czy błąd dotyczy całej witryny, jednej podstrony, panelu czy konkretnej operacji. Nie powtarzaj wielokrotnie płatności lub importu: błąd odpowiedzi nie przesądza, że operacja nie została wykonana.

Porównaj dostęp do strony głównej i panelu, ale uwzględnij cache. Publiczna strona może wyglądać poprawnie dzięki zapisanej kopii, chociaż PHP już nie działa. Jeśli witryna odpowiada prawidłowo, lecz długo czeka na wynik, właściwszym punktem wyjścia jest diagnostyka wolnego WordPressa.

Przed naprawą zanotuj godzinę ze strefą czasową, adres, widoczny komunikat oraz ostatnią poprawnie działającą czynność. Sprawdź historię aktualizacji, zmian PHP, wdrożeń kodu i konfiguracji hostingu. Bliskość czasowa jest wskazówką, nie dowodem winy. Nie dokładaj kolejnych aktualizacji do nierozpoznanej awarii.

Zabezpiecz aktualne pliki i bazę, o ile infrastruktura pozwala to zrobić, oraz potwierdź datę ostatniej sprawnej kopii. Zachowaj oba stany. Bieżąca kopia może zawierać błąd, ale także zamówienia, których nie ma w starszym backupie. Ustal, kto może przywrócić witrynę i czy odtworzenie zostało wcześniej sprawdzone.

Jeżeli strona nadal zapisuje dane, plan przywracania musi uwzględnić nowe wpisy, płatności i zamówienia. Nie nadpisuj bazy starszą wersją bez ich rozliczenia. Przy braku bezpiecznej drogi powrotu zatrzymaj zmiany i skontaktuj się z administratorem. Przygotowanie środowiska do kontrolowanych zmian opisuje poradnik o aktualizacjach WordPressa.

Zacznij od dziennika błędów serwera i PHP w panelu hostingowym. Dopasuj wpis do godziny oraz żądania. Szukaj komunikatu kończącego wykonanie, ścieżki pliku i kontekstu wywołania. Ostrzeżenie zapisane obok nie musi być przyczyną awarii. Gdy log jest pusty, hosting powinien sprawdzić jego lokalizację i warstwę, która zwróciła odpowiedź.

Dokumentacja WordPressa ostrzega:

Instrukcja debugowania WordPressa wyjaśnia, że przy aktywnym debugowaniu ustawienie WP_DEBUG_LOG na true zapisuje dziennik zwykle w wp-content/debug.log; można wskazać inną ścieżkę. WP_DEBUG_DISPLAY=false ukrywa komunikaty w stronie, lecz nie blokuje pobierania pliku przez HTTP.

Debugowanie prowadź na zabezpieczonej kopii. Jeśli administrator musi czasowo zbierać dodatkowe dane na produkcji, powinien ustalić chronione miejsce zapisu i ograniczyć dostęp. Po diagnozie wyłącz dodatkowe logowanie. Udostępniaj wyłącznie potrzebny fragment po usunięciu danych klientów, tokenów, ciasteczek i sekretów konfiguracji.

Nie przechodź automatycznie przez wszystkie popularne porady. Wybierz gałąź odpowiadającą temu, co rzeczywiście zostało zapisane.

Ścieżka wtyczki w komunikacie nie zawsze wskazuje pierwotne źródło problemu. Rozszerzenie może wywoływać niedostępną funkcję innego komponentu. Zachowaj kontekst błędu i przetestuj hipotezę. Po każdej zmianie sprawdź ten sam adres oraz nowy wpis w logu.

Brak dostępu do panelu nie oznacza utraty możliwości diagnostyki. Nadal mogą działać panel hostingu i bezpieczny dostęp do plików. Jeżeli WordPress udostępnił link trybu odzyskiwania, traktuj go jak poufny dostęp administracyjny. Nie publikuj go w zgłoszeniu ani na forum. Tryb ten pomaga wejść do panelu w określonych awariach, ale nie rozwiązuje każdego błędu 500.

Jeżeli log wskazuje konkretną wtyczkę, administrator może czasowo wyłączyć właśnie ją przez dostęp do plików, po zapisaniu pierwotnej nazwy i planu przywrócenia. Najpierw sprawdź skutki na kopii. Na produkcji takie działanie może zatrzymać płatności, logowanie lub integrację magazynową, nawet gdy przywróci samą stronę główną.

Nie zmieniaj nazw wszystkich katalogów naraz. Nie zakładaj też, że usunięcie aktywnego motywu zapewni działający zamiennik. Bez dostępu administracyjnego, wskazania podejrzanego komponentu lub znajomości zależności lepiej przekazać pracę osobie odpowiedzialnej za naprawę WordPressa.

Wartość memory_limit dobiera się do rzeczywistego zużycia i zasobów konta. Jeżeli proces ma wyciek pamięci lub przetwarza nieograniczony zestaw danych, samo zwiększenie limitu może tylko odsunąć awarię. Sprawdź obowiązującą konfigurację z hostingiem, zamiast zakładać, że wpis w WordPressie ją zmieni.

Nie cofaj PHP do przypadkowej starej gałęzi. Według wykazu zakończonego wsparcia PHP wsparcie PHP 8.1 zakończyło się 31 grudnia 2025 roku. Aktualny harmonogram PHP wskazuje poprawki bezpieczeństwa dla PHP 8.2 do 31 grudnia 2026 roku. Wybierz wspieraną gałąź zgodną z używanym kodem, po testach, i zaplanuj jej dalsze aktualizacje.

Plik .htaccess ma znaczenie tylko w konfiguracjach, które go obsługują. Dyrektywy PHP zależą od sposobu uruchamiania interpretera; nieprawidłowy wpis może sam wywołać błąd. Zachowaj oryginał i poproś administratora o sprawdzenie składni. Usunięcie całego pliku może naruszyć reguły dostępu, przekierowania i adresy podstron.

Jeżeli aktualizacja została przerwana lub brakuje plików rdzenia, administrator korzystający z WP-CLI może wykonać odczytową kontrolę wp core verify-checksums. Dokumentacja polecenia opisuje porównanie plików z sumami kontrolnymi WordPress.org. Weryfikacja musi odpowiadać zainstalowanej wersji i lokalizacji językowej. Wynik nie jest pełnym skanem bezpieczeństwa wtyczek, motywów i bazy.

Nie nadpisuj rdzenia przypadkowym pakietem ani nie wykonuj reinstalacji całej witryny na podstawie samego kodu 500. Naprawa plików powinna zachować konfigurację, treści i zgodność wersji. Gdy pojawiają się nieznane konta lub podejrzane zmiany, potrzebna jest osobna analiza bezpieczeństwa.

Po korekcie sprawdź pierwotnie uszkodzone żądanie, panel, podstrony i najważniejsze integracje. Testy płatności prowadź w trybie testowym. Potwierdź status odpowiedzi oraz brak nowych błędów w odpowiadającym jej logu. Sama widoczna strona główna nie wystarcza do zamknięcia awarii.

Zatrzymaj samodzielną naprawę, gdy nie ma sprawdzonej kopii, trzeba nadpisać bazę z nowymi zamówieniami, błąd obejmuje wiele witryn albo brakuje uprawnień do logów. Hosting powinien zbadać warstwę serwera; programista analizuje kod i zależności. Przy niepewności co do integralności danych najpierw zabezpiecz stan, dopiero potem zmieniaj konfigurację.

W zgłoszeniu podaj czas ze strefą, adres, czynność, kod odpowiedzi, ostatnie zmiany i wykonane próby. Dołącz zanonimizowany fragment logu oraz informację o kopiach. Nie przesyłaj pełnego pliku konfiguracji ani hasła w treści wiadomości. Przez kontakt można ustalić zakres pomocy i bezpieczny sposób przekazania dostępów. Dalszą opiekę oraz planowanie zmian opisuje oferta WordPress.