Błąd 500 w WordPressie: 6 kroków od logu do naprawy

Materiał reklamowy — linki partnerskie: LH.pl, Smarthost.

Błąd 500 w WordPressie jest ogólną informacją o niepowodzeniu po stronie serwera. Może pojawić się po aktualizacji wtyczki, zmianie PHP, uszkodzeniu konfiguracji albo przekroczeniu pamięci. Nowy hosting nie naprawi automatycznie wadliwego kodu, który przeniesiesz razem ze stroną.

Ten poradnik prowadzi właściciela serwisu od zabezpieczenia danych do ustalenia konkretnej przyczyny. Potrzebujesz dostępu do panelu hostingu, kopii plików i bazy oraz SFTP lub pomocy administratora. Jeśli błąd dotyczy cudzego serwisu, przekaż jego właścicielowi adres i czas zdarzenia. Nie masz możliwości naprawy WordPressa z poziomu własnej przeglądarki.

W tym poradniku

1. Błąd 500: zabezpiecz dane przed zmianą
2. Powiąż awarię z ostatnią zmianą
3. Odczytaj właściwy log, bez ujawniania go odwiedzającym
4. Cofnij jedną potwierdzoną zmianę
5. Sprawdź konfigurację i pamięć zamiast zwiększać wszystko
6. Potwierdź naprawę i dopiero wtedy porównaj hosting

1. Błąd 500: zabezpiecz dane przed zmianą

Nie uruchamiaj od razu przywracania całej strony. Najpierw zachowaj bieżące pliki, bazę i logi oraz sprawdź datę ostatniej sprawnej kopii. Aktualny zrzut może zawierać wadliwy kod, ale także zamówienia i wiadomości, których nie ma w starszej wersji. Powrót bazy do wczoraj usuwa późniejsze zapisy, jeśli nie zabezpieczysz ich oddzielnie.

Jeśli panel kopii jest niedostępny albo awaria dotyczy również bazy, poproś operatora o zabezpieczenie danych i potwierdzenie zakresu. Działania naprawcze ogranicz do niezbędnego elementu. Pełną procedurę kopii i jej sprawdzenia opisuje poradnik odtwarzania WordPressa.

Dla sklepu uzgodnij z osobą odpowiedzialną za sprzedaż okno naprawy oraz sposób obsługi nowych transakcji. Nie wyłączaj losowo wtyczek płatności, ochrony lub synchronizacji magazynu. Test na chronionej kopii jest bezpieczniejszy; przed jej pierwszym uruchomieniem zablokuj wysyłkę i produkcyjne integracje, żeby nie odtworzyć działań na prawdziwych klientach.

2. Powiąż awarię z ostatnią zmianą

Zapisz godzinę, strefę czasową, adres i czynność wywołującą problem. Otwórz raz stronę główną, jeden artykuł i ekran logowania. W narzędziach przeglądarki wybierz Sieć / Network, odśwież stronę i odczytaj status głównego dokumentu. „Internal Server Error” w treści nie zastępuje sprawdzenia odpowiedzi HTTP.

Sprawdź historię aktualizacji, zmiany motywu, dodatku, pliku konfiguracyjnego i wersji PHP. Jeśli WordPress wysłał e-mail o błędzie krytycznym, przeczytaj wskazany element i informację o trybie odzyskiwania. Linku odzyskiwania nie publikuj ani nie przekazuj przypadkowej osobie. Otwiera specjalny tryb naprawy, po czym nadal trzeba zalogować się na swoje konto.

Przykład: w modelowej sytuacji o 12:05 zaktualizowano wtyczkę formularza, o 12:06 zaczęły się odpowiedzi 500, a log z tej samej minuty wskazuje błąd krytyczny w jej katalogu. To dobra przesłanka do sprawdzenia tej wtyczki, ale sama zbieżność godzin nie dowodzi winy. Porównaj także zależności i zgodność z PHP.

3. Odczytaj właściwy log, bez ujawniania go odwiedzającym

W panelu hostingu przejdź do logów błędów domeny i PHP. Wybierz właściwą witrynę oraz przedział wokół awarii. Szukaj pierwszego istotnego błędu dla tego żądania, np. Fatal error, Parse error albo Allowed memory size exhausted. Późniejsze komunikaty mogą być skutkiem wcześniejszej awarii.

Jeżeli logi operatora nie wystarczają, dodatkowe logowanie WordPressa włączaj przede wszystkim na środowisku testowym. Dokumentacja opisuje WP_DEBUG, WP_DEBUG_LOG i WP_DEBUG_DISPLAY. W pliku wp-config.php sprawdź istniejące definicje, zachowaj kopię i edytuj je zamiast dopisywać duplikaty. Definicje umieść przed komentarzem /* That's all, stop editing! Happy blogging. */ i przed załadowaniem wp-settings.php.

Do logowania ustaw WP_DEBUG na logiczne true, a WP_DEBUG_DISPLAY na false, bez cudzysłowów wokół tych wartości. Dla WP_DEBUG_LOG wskaż pełną ścieżkę do prywatnego pliku poza publicznym katalogiem strony, w miejscu zapisywalnym przez PHP i potwierdzonym przez operatora. Sprawdź, że log faktycznie powstaje, a nie jest dostępny przez WWW. Jeśli nie potrafisz potwierdzić prywatnej ścieżki, skorzystaj z logu panelu lub pomocy administratora.

Nie pozostawiaj domyślnego publicznie osiągalnego wp-content/debug.log z danymi serwisu. W ustawieniach PHP tej domeny pozostaw także display_errors i display_startup_errors wyłączone; jeśli nie widzisz tych opcji, poproś operatora o potwierdzenie. Chroni to również przed ujawnieniem błędu, który wystąpi, zanim WordPress odczyta ustawienia diagnostyki. Po zebraniu potrzebnych informacji wyłącz dodatkową diagnostykę, zachowaj bezpieczny fragment i usuń zbędny log zgodnie z zasadami przechowywania danych. Pliki mogą zawierać ścieżki, adresy i dane formularzy.

4. Cofnij jedną potwierdzoną zmianę

Jeśli log wskazuje konkretną wtyczkę po aktualizacji, zacznij od niej. Przy działającym panelu lub trybie odzyskiwania wyłącz wskazany dodatek i powtórz test. Zanotuj, która funkcja przestała być dostępna. Jeśli panel nie działa, administrator może czasowo zmienić nazwę dokładnie tego katalogu w wp-content/plugins przez SFTP, zachowując oryginalną nazwę i kopię. Nie zmieniaj całego zestawu wtyczek na publicznym sklepie bez planu.

Po odzyskaniu dostępu sprawdź ekran Wtyczki i stan dodatku. Przywrócenie nazwy katalogu nie zawsze oznacza ponowną aktywację: aktywuj dopiero wersję sprawdzoną jako zgodna. Jeśli wyłączenie nie zmieniło wyniku, odtwórz poprzedni stan i zbadaj następną hipotezę. Nie pobieraj starszych wersji z nieznanych serwisów ani nie wracaj trwale do wersji z niezałataną luką.

Przy błędzie po zmianie PHP porównaj wymagania WordPressa, motywu i dodatków z ustawioną wersją oraz dostępnymi rozszerzeniami. Tymczasowy powrót do poprzedniej, nadal wspieranej wersji można rozważyć po zabezpieczeniu danych. Docelowo napraw zgodność; utrzymywanie niewspieranego PHP tylko po to, żeby komunikat zniknął, nie jest rozwiązaniem.

Jeśli podejrzany jest motyw, testuj domyślny zgodny motyw na kopii i sprawdź funkcje, które zależą od poprzedniego. Zmiana motywu może wpłynąć na układ i formularze. Przy ręcznej poprawce pliku porównaj go z zachowaną poprawną wersją i przywróć tylko potrzebny element.

5. Sprawdź konfigurację i pamięć zamiast zwiększać wszystko

Na serwerach obsługujących .htaccess wadliwa dyrektywa może spowodować 500 zanim WordPress zapisze swój log. Zachowaj plik i cofnij konkretną ostatnią zmianę wskazaną w logu. Nie usuwaj całej konfiguracji w ciemno: może chronić katalog lub zawierać ważne przekierowania. Nginx nie interpretuje tego pliku tak jak Apache; instrukcji nie wolno przenosić między serwerami bez sprawdzenia.

Nie ustawiaj uprawnień 777 jako uniwersalnej naprawy. Ustal z operatorem właściwego właściciela plików i wymagane uprawnienia. Jeśli przyczyną jest brak rozszerzenia PHP, sprawdź, czy można je włączyć dla tej domeny i tej wersji; zakup większego dysku niczego tu nie rozwiąże.

Przykładowy komunikat o wyczerpaniu 268435456 bytes wskazuje limit 256 MiB. Nie mówi, że konto zużywa cały RAM serwera. Powodem może być import dużego pliku, zapętlenie albo nieefektywna wtyczka. Parametr WordPressa nie daje pamięci ponad faktyczny limit hostingu. Najpierw spróbuj mniejszej porcji danych i porównaj zużycie; dopiero potwierdzona potrzeba uzasadnia zmianę limitu lub pakietu.

Rozróżnienie RAM konta, pamięci procesu i liczby równoległych żądań opisuje przewodnik po limitach hostingu. W zgłoszeniu podaj konkretny komunikat, godzinę, wersję PHP i wykonaną już próbę, zamiast samego „strona nie działa”.

6. Potwierdź naprawę i dopiero wtedy porównaj hosting

Jeśli korzystasz z trybu odzyskiwania, po naprawie wybierz wyjście z tego trybu: wadliwe rozszerzenie może być pomijane tylko w Twojej sesji. Otwórz pierwotnie wadliwy adres i reprezentatywny artykuł także jako niezalogowany odwiedzający, a następnie sprawdź panel. Przetestuj formularz na testowym odbiorcy, a w sklepie uzgodnioną ścieżkę zakupową bez przypadkowego obciążania klientów. Sprawdź świeże logi i wynik operacji, nie tylko kod 200. Zapisz przyczynę, poprawkę i sposób powrotu; pozostaw obserwację najbliższego zadania cyklicznego, jeśli to ono wywoływało awarię.

Hosting warto zmienić, jeżeli potwierdzona potrzeba aplikacji nie mieści się w dostępnych limitach, brakuje wymaganej wspieranej konfiguracji albo zakres obsługi nie odpowiada firmie. Jeśli przyczyną był błąd składni własnego pliku, migracja przeniesie ten błąd. Rachunek decyzji rozwija poradnik kiedy opłaca się zmiana hostingu.

LH.pl Mango kosztuje 37,50 zł netto na pierwszy rok i 399 zł netto przy odnowieniu; karta podaje startowe 46,12 zł brutto. Model zakłada aktualną wspieraną wersję PHP. Starsze wersje u tego operatora mogą wymagać osobnej opłaty. Smarthost pro-www kosztuje 249 zł netto rocznie; program lojalnościowy może obniżyć kolejne odnowienia, dlatego tabela zachowuje ostrożną sumę katalogową bez warunkowego rabatu.

Sprawdź LH.pl Mango, gdy projekt mieści się w jego zakresie i uzyskasz potwierdzenie potrzebnej konfiguracji. Smarthost pro-www może być kandydatem dla mniejszej strony; 10 GB trzeba policzyć łącznie z pocztą i bazami według zasad pakietu. Żadna cena nie jest gwarancją zgodności nieprzetestowanej wtyczki.

Do trzyletnich kwot dodaj domenę, ewentualne dodatki, pracę przy kodzie i przenosiny; obecne odnowienia nie są gwarantowane na przyszłość. Model 3 godzin diagnozy po 150 zł brutto to 450 zł jednorazowo — koszt może być uzasadniony także wtedy, gdy pozostajesz u dotychczasowego operatora. Sięgnij po porównanie hostingu po ustaleniu przyczyny awarii, a przed migracją wykonaj próbne odtworzenie, zabezpiecz zmieniające się dane i zachowaj poprzednią usługę do powrotu.

Oficjalne źródła

Sprawdzono 31.10.2026. Procedura i przykłady logów służą diagnozie; nie są raportem naprawy konkretnej strony.

• MDN — HTTP 500.
• WordPress — typowe błędy, diagnostyka i prywatny log, konfiguracja wp-config.php oraz wyłączanie wtyczek przy niedostępnym panelu.
• LH.pl — ceny i wersje PHP; Smarthost — pakiety pro i warunki programu lojalnościowego.