Jak naprawić błąd 500 w WordPressie krok po kroku?

Wordpress / Przez / / 8 minut czytania

Błąd 500 w WordPressie (Internal Server Error) to odpowiedź serwera, który natrafił na nieoczekiwany problem i nie obsłużył żądania. Wywołuje go zwykle wtyczka, motyw, limit PHP, plik .htaccess albo baza danych, a sam komunikat nie zdradza, który z tych elementów zawiódł. Naprawa polega więc na wykluczaniu przyczyn po kolei, od sprawdzenia najszybszego do najbardziej technicznego. Czym kod 500 różni się od 502, 503 i 504, wyjaśnia wpis Co to jest błąd serwera 5XX?

Od czego zacząć naprawę błędu 500 w WordPressie?

Zacznij od kopii zapasowej plików i bazy danych, a zaraz potem sprawdź skrzynkę e-mail administratora strony. Kopię zrobisz w panelu hostingu (sekcja „Kopie zapasowe”, dla samej bazy phpMyAdmin). Każdy z dalszych kroków zmienia pliki lub bazę danych, więc bez takiego zabezpieczenia pomyłki nie da się cofnąć.

Kolejność kroków wynika z tego, gdzie zwykle leży przyczyna i ile wiedzy technicznej wymaga każde sprawdzenie:

1

Tryb odzyskiwania

E-mail od WordPressa z linkiem, gdy błąd krytyczny wywołała wtyczka lub motyw.

2

Wtyczki przez FTP

Gdy maila nie ma, a panel wp-admin też zwraca 500.

3

Motyw

Przełączenie na domyślny przez zmianę nazwy folderu.

4

Plik .htaccess

Test przez zmianę nazwy pliku.

5

Log błędów

WP_DEBUG_LOG i log serwera, gdy winowajca dalej jest nieznany.

6

Limity PHP

Gdy błąd pojawia się tylko przy logowaniu, imporcie lub wgrywaniu plików.

7

Baza danych

Wbudowane narzędzie naprawy tabel.

8

Hosting

Zgłoszenie, gdy żaden krok nie pomógł.

Sam objaw skraca tę listę. Jeśli błąd pojawił się tuż po aktualizacji wtyczki lub motywu, zacznij od kroków 1-3; po ręcznej edycji .htaccess albo po zmianie ustawień wtyczki bezpieczeństwa – od kroku 4; a jeśli problem wraca tylko przy jednej, cięższej akcji – od kroku 6. Gdy błąd objął całą witrynę i nie poprzedziła go żadna zmiana z Twojej strony, diagnostyka najczęściej kończy się na kroku 7 albo 8.

Strona pokazuje błąd 500 i nie wiesz, co go wywołało?

Napisz do nas, sprawdzimy logi serwera i WordPressa, wskażemy przyczynę i naprawimy usterkę.

Napisz do nas

Jak działa tryb odzyskiwania WordPressa i jak z niego skorzystać?

Tryb odzyskiwania (Recovery Mode) działa w WordPressie od wersji 5.2. Gdy wtyczka lub motyw wywoła błąd krytyczny PHP (fatal error), system wysyła na adres e-mail administratora wiadomość z unikalnym linkiem. Link jest jednorazowy i ważny przez ograniczony czas; po jego kliknięciu wchodzisz do wp-admin, a WordPress tymczasowo wyłącza element, który spowodował błąd.

W tym trybie panel działa normalnie, więc w zakładce Wtyczki albo Wygląd → Motywy możesz winowajcę dezaktywować na stałe, zaktualizować albo zastąpić innym.

Gdy wiadomość nie dochodzi, bo adres administratora jest nieaktualny albo hosting nie wysyła poczty, odbiorcę nadpiszesz w wp-config.php, przed linią „That’s all, stop editing!”:

define('RECOVERY_MODE_EMAIL', 'twoj@adres.pl');

Tryb odzyskiwania wychwytuje tylko błędy krytyczne PHP zgłaszane przez WordPressa, dlatego błąd 500 wywołany przez limity hostingu, plik .htaccess albo bazę danych nie generuje żadnej wiadomości i wymaga kolejnych kroków. Funkcję da się wyłączyć stałą WP_DISABLE_FATAL_ERROR_HANDLER, ale przy naprawie nie ma powodu tego robić.

Jak wyłączyć wtyczki przez FTP, gdy panel wp-admin też pokazuje błąd 500?

Połącz się z serwerem przez klienta FTP (dane logowania znajdziesz w panelu hostingu) albo przez menedżer plików w tym samym panelu, a potem zmień nazwę folderu wp-content/plugins/, na przykład na plugins-old. WordPress przestanie wtedy widzieć wtyczki i potraktuje je jak wyłączone.

Jeśli strona po tej zmianie znów się otwiera, przyczyną była jedna z wtyczek. Przywróć folderowi nazwę plugins, a potem zmieniaj nazwy pojedynczych podfolderów wtyczek po kolei i po każdym kroku odświeżaj stronę. Wtyczka, po której wyłączeniu błąd znika, to winowajca: zostaw ją wyłączoną, zaktualizuj albo zastąp inną.

Jeśli błąd nie zniknął po wyłączeniu wszystkich wtyczek, przyczyna leży poza nimi: w motywie, pliku .htaccess, limitach PHP albo bazie danych.

Jak sprawdzić, czy błąd 500 wywołuje motyw?

Motyw sprawdzisz tak samo. Zmień nazwę folderu aktywnego motywu w wp-content/themes/, a WordPress przełączy stronę na domyślny motyw z serii Twenty, o ile jest zainstalowany. Gdy błąd zniknie, przyczyna leży w motywie, najczęściej w pliku functions.php albo w kodzie dopisanym po ostatniej aktualizacji.

Strona na domyślnym motywie wygląda inaczej, ale działa, więc zyskujesz czas na naprawę albo na kontakt z jego autorem. Gdy na serwerze nie ma żadnego motywu domyślnego, pobierz go najpierw z katalogu na WordPress.org i wgraj do wp-content/themes/.

Jak sprawdzić, czy błąd 500 wywołuje plik .htaccess?

Zmień nazwę pliku .htaccess w katalogu głównym witryny na .htaccess-old i odśwież stronę. Jedna literówka albo błędna dyrektywa w tym pliku wyłącza całą witrynę kodem 500. To samo ryzyko opisujemy przy ręcznym dopisywaniu przekierowań we wpisie Jak naprawić błąd 404 w WordPressie?

Jeśli strona znów się wczytuje po zmianie nazwy, przyczyną był ten plik. Nowy, poprawny .htaccess WordPress wygeneruje sam: w wp-admin wejdź w Ustawienia → Bezpośrednie odnośniki i kliknij „Zapisz zmiany”, a domyślny blok od # BEGIN WordPress do # END WordPress odtworzy się automatycznie. Drugi sposób to przywrócenie kopii pliku sprzed zmiany.

Nowy plik zawiera tylko domyślne wpisy WordPressa, więc reguły dopisane wcześniej ręcznie przenieś ze starej kopii pojedynczo i po każdej sprawdzaj stronę. Ta, po której błąd wraca, jest winowajcą.

Jak włączyć log błędów WordPressa i znaleźć w nim przyczynę?

Dopisz w wp-config.php, przed linią „That’s all, stop editing!”, trzy stałe:

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

Od tej chwili błędy PHP trafiają do pliku wp-content/debug.log, a WP_DEBUG_DISPLAY ustawione na false pilnuje, żeby nie pokazywały się odwiedzającym. Wpis zaczynający się od „Fatal error” zawiera ścieżkę do pliku, który zatrzymał stronę, więc od razu wskazuje winną wtyczkę lub motyw, bez sprawdzania ich po kolei.

Ten krok możesz wykonać wcześniej, przed wyłączaniem wtyczek, jeśli masz dostęp do FTP. Log skraca wtedy krok drugi do jednej zmiany nazwy. Po naprawie ustaw WP_DEBUG z powrotem na false, bo log rośnie z każdym ostrzeżeniem.

Drugim źródłem jest log błędów samego serwera, w panelu hostingu w sekcji „Logi” lub „Error log”. Znajdziesz w nim także błędy spoza WordPressa, na przykład przekroczone limity konta i błędy składni .htaccess, których debug.log nie rejestruje.

Jak podnieść limity PHP, gdy błąd 500 pojawia się tylko przy cięższych akcjach?

Błąd 500, który pojawia się tylko przy logowaniu do wp-admin, wgrywaniu dużego zdjęcia, imporcie produktów albo generowaniu raportu, oznacza zwykle przekroczony limit pamięci (memory_limit) lub czasu wykonania skryptu (max_execution_time). Najpewniejsze miejsce zmiany to panel hostingu, sekcja „PHP” albo „Wybór wersji PHP”, bo część dostawców blokuje nadpisywanie limitów z poziomu WordPressa.

Limit pamięci dla WordPressa podniesiesz też w wp-config.php, przed linią „That’s all, stop editing!”:

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

Trzeci sposób to linia php_value memory_limit 256M w pliku .htaccess, ale zadziała tylko na Apache lub LiteSpeed z PHP uruchomionym jako moduł serwera, nie na PHP-FPM. Gdy nie wiesz, w którym trybie pracuje Twój hosting, zmień limit w panelu.

W tym samym panelu sprawdź wersję PHP. Minimalną i zalecaną podaje WordPress.org na stronie wymagań (link w Źródłach), a PHP starsze od tego minimum to częsta przyczyna błędów krytycznych po aktualizacji wtyczek.

Jak naprawić bazę danych WordPressa?

WordPress ma wbudowane narzędzie naprawy tabel. Zrób kopię bazy w panelu hostingu albo w phpMyAdmin, a potem dopisz w wp-config.php:

define('WP_ALLOW_REPAIR', true);

Następnie wejdź na adres https://twojadomena.pl/wp-admin/maint/repair.php. Zobaczysz stronę z dwoma przyciskami: „Repair Database” (napraw bazę danych) i „Repair and Optimize Database” (napraw i zoptymalizuj bazę danych). Narzędzie sprawdza i naprawia strukturę tabel bez utraty treści. Nie przywraca natomiast usuniętych danych, bo od tego jest kopia zapasowa.

Strona repair.php nie wymaga logowania, dopóki stała WP_ALLOW_REPAIR jest włączona, więc po zakończeniu naprawy usuń tę linię z wp-config.php. Inaczej narzędzie pozostaje dostępne dla każdego, kto zna adres.

Ten krok ma sens, gdy poprzednie nie pomogły albo log wskazuje na bazę danych. Komunikat „Error establishing a database connection” to osobny błąd o innych przyczynach; różnicę opisuje FAQ na końcu wpisu.

Kiedy zgłosić błąd 500 do hostingu?

Gdy strona zwraca 500 po wyłączeniu wtyczek i motywu, przy domyślnym .htaccess, z pustym logiem debugowania i po naprawie bazy, przyczyna leży najprawdopodobniej w infrastrukturze hostingu, na którą nie masz wpływu z poziomu WordPressa. W zgłoszeniu podaj godzinę, od której trwa błąd, listę wykonanych kroków i fragment logu serwera z tego czasu. Taki komplet oszczędza rundę pytań od dostawcy.

Hosting widzi to, czego z WordPressa nie widać: obciążenie serwera, limity procesów konta i konfigurację PHP. Przy dłuższej przerwie po stronie hostingu lepiej, żeby strona zwracała kod 503 z nagłówkiem Retry-After niż przypadkowe 500, bo Google traktuje te dwa kody inaczej.

Nie masz dostępu do FTP albo baza danych wymaga naprawy?

Napisz do nas, zrobimy to bezpiecznie, z kopią zapasową przed każdą zmianą.

Napisz do nas

FAQ

Nie. Wpisy, strony i ustawienia zostają w bazie danych, a błąd 500 tylko blokuje ich wyświetlanie, dopóki aktywna jest uszkodzona wtyczka, motyw lub reguła. Narzędzie repair.php poprawia strukturę tabel, nie kasuje wierszy; treść przepada dopiero przy nadpisaniu bazy bez kopii zapasowej.

Krótka awaria nie zmienia pozycji, bo Google zachowuje zaindeksowane adresy i tylko tymczasowo zwalnia tempo skanowania. Przy dłuższym błędzie robot ignoruje treść z takich adresów i z czasem usuwa je z indeksu, a po naprawie wraca do poprzedniego tempa stopniowo. Ile podstron Google pobiera z witryny w danym czasie, wyjaśnia wpis Co to jest crawl budget?

Komunikat o błędzie połączenia z bazą to osobny, częstszy problem: WordPress w ogóle się do niej nie dostał, bo jej serwer nie odpowiada albo w wp-config.php są błędne dane dostępowe. Uszkodzone tabele przy działającym połączeniu dają natomiast błąd 500 albo pustą stronę i dopiero wtedy pomaga narzędzie naprawy opisane wyżej.

Nie, chyba że dostawca sam informuje o awarii na stronie statusu usług. Większość błędów 500 w WordPressie wywołuje wtyczka lub motyw po aktualizacji, a taką usterkę naprawisz sam w kilka minut trybem odzyskiwania albo przez FTP. Zgłoszenie do hostingu, z listą wykonanych kroków i logiem, wysyłasz dopiero wtedy, gdy te sposoby zawiodą.

Źródła

Podobne artykuły

Kontakt
Kontakt
Przewijanie do góry