Błąd krytyczny WordPress: co zrobić, gdy strona nie działa

Co oznacza komunikat „W witrynie wystąpił błąd krytyczny”

Błąd krytyczny w WordPressie to błąd PHP, po którym kod strony nie może dokończyć pracy. Od wersji 5.2 WordPress przechwytuje takie błędy i zamiast pustej strony wyświetla krótki komunikat. Jego treść zależy od miejsca:

• Na stronie, którą oglądają klienci: „W witrynie wystąpił błąd krytyczny.”, a pod spodem link do porad WordPressa.
• W panelu wp-admin i na stronie logowania: „W witrynie wystąpił krytyczny błąd. Instrukcje znajdziesz w skrzynce email administratora witryny.”
• W panelu i na stronie logowania, gdy strona należy do sieci WordPress Multisite: „Na stronie wystąpił błąd krytyczny. Skontaktuj się z administratorem witryny…”

Strona po angielsku pokazuje „There has been a critical error on this website.” To ten sam błąd. Polskie brzmienie pochodzi z oficjalnego tłumaczenia WordPressa.

Według dokumentacji WordPressa najczęstsze przyczyny to konflikt między wtyczkami, motyw niezgodny z resztą strony, wersja PHP, której kod nie obsługuje, wyczerpany limit pamięci i uszkodzone pliki WordPressa. Często błąd pojawia się tuż po aktualizacji wtyczki, motywu, samego WordPressa albo PHP na hostingu.

Biały ekran w WordPressie a błąd krytyczny

Biały ekran to strona bez żadnej treści i bez komunikatu. Dokumentacja WordPressa podaje, że tak mogą się objawiać błędy PHP i błędy bazy danych, a wśród przyczyn wymienia wtyczkę i motyw. Przy komunikacie o błędzie krytycznym WordPress zdążył błąd przechwycić, więc mógł też wysłać Ci e-mail. Gdy winna jest wtyczka albo motyw, naprawia się oba przypadki tak samo. Jeśli zamiast komunikatu WordPressa przeglądarka pokazuje kod błędu, na przykład 500 albo 503, zobacz, co sprawdzić, gdy strona internetowa jest niedostępna.

Jak naprawić błąd krytyczny: najpierw e-mail i tryb odzyskiwania

Zacznij od kroków, do których nie potrzebujesz dostępu do hostingu:

1. Zapisz, co zmieniło się przed awarią: aktualizacja, nowa wtyczka, zmiana na hostingu.
2. Wejdź na adres panelu, czyli twojadomena.pl/wp-admin. WordPress wysyła e-mail o błędzie dopiero wtedy, gdy błąd wystąpi w panelu albo na stronie logowania. Samo wejście na stronę główną go nie wyśle.
3. Sprawdź skrzynkę wpisaną w Ustawienia → Ogólne w polu „Administracyjny adres e-mail”. Zajrzyj też do spamu. Wiadomość ma temat „[nazwa strony] Twoja witryna ma problemy techniczne”. Jest w niej nazwa wtyczki albo motywu, który spowodował błąd, i link do trybu odzyskiwania.
4. Kliknij link i zaloguj się. Na liście wtyczek przy winnej zobaczysz informację, że wstrzymano jej ładowanie w trybie awaryjnym. Kliknij przy niej „Wyłącz”. Jeśli winny jest motyw, włącz inny w Wygląd → Motywy.
5. Wyjdź z trybu przyciskiem „Wyjdź z trybu awaryjnego” na górnym pasku. Otwórz stronę w oknie prywatnym przeglądarki, żeby zobaczyć ją tak jak klienci.

Jeśli panel otwiera się normalnie, a błąd widać tylko na stronie, e-mail nie przyjdzie. Wtedy wyłączaj wtyczki po jednej w Wtyczki → Zainstalowane wtyczki i po każdej sprawdzaj stronę.

Jak działa tryb odzyskiwania

W e-mailu ten tryb nazywa się trybem odzyskiwania, a w panelu trybem awaryjnym. Według zapowiedzi zespołu WordPressa wstrzymuje on wadliwą wtyczkę albo motyw tylko w przeglądarce osoby, która kliknęła link. Klienci dalej widzą błąd, dopóki nie wyłączysz wtyczki. Wyłączona wtyczka nie działa, więc jeśli obsługiwała na przykład formularz, formularz zniknie do czasu poprawki.

Link z e-maila jest domyślnie ważny przez dobę i w tym czasie WordPress nie wyśle kolejnego. E-mail nie przyjdzie wcale, jeśli WordPress nie powiąże błędu z konkretną wtyczką lub motywem. Nie przyjdzie też, gdy wysyłka poczty ze strony nie działa. Wtedy potrzebny jest dostęp do plików.

Jak wyłączyć wtyczki bez dostępu do wp-admin

Do tego potrzebujesz dostępu do plików strony: menedżera plików w panelu hostingu albo konta FTP, na przykład w programie FileZilla. Kroki opisuje FAQ WordPressa:

1. Otwórz katalog strony, czyli ten, w którym są foldery wp-admin, wp-content i wp-includes. Wejdź do wp-content.
2. Zmień nazwę folderu plugins, na przykład na plugins.hold. WordPress przestanie ładować wszystkie wtyczki.
3. Zaloguj się do panelu i wejdź na listę wtyczek pod adresem twojadomena.pl/wp-admin/plugins.php. WordPress pokaże, że plików wtyczek brakuje, i je wyłączy.
4. Przywróć folderowi nazwę plugins. Wtyczki wrócą na listę jako wyłączone. Według FAQ ich ustawienia zostają.
5. Włączaj je po jednej i po każdej sprawdzaj stronę. Wtyczka, po której włączeniu błąd wraca, jest winna.

Jeśli z e-maila albo z logu znasz nazwę wtyczki, wystarczy zmienić nazwę tylko jej folderu w wp-content/plugins. Przy wyłączonych wtyczkach nie działa nic, co dają wtyczki, na przykład formularze, a przy WooCommerce cały sklep. Nie zostawiaj strony w tym stanie dłużej, niż musisz. Folderów nie usuwaj, bo zmianę nazwy łatwo cofnąć, a usunięcia nie.

Jak przełączyć motyw na domyślny, gdy panel nie działa

Jeśli po wyłączeniu wtyczek błąd został, sprawdź motyw. W folderze wp-content/themes zmień nazwę folderu aktywnego motywu, na przykład dopisując na końcu _old. Potem zaloguj się do panelu i otwórz Wygląd → Motywy. WordPress wyświetli komunikat „Wybrany motyw jest uszkodzony. Przywracam domyślny.” i przełączy stronę na jeden z domyślnych motywów WordPressa, o ile jest zainstalowany.

Strona będzie wyglądać inaczej, ale jeśli błąd zniknie, wiesz już, że winny jest motyw. Gdy motyw zostanie poprawiony, przywróć jego folderowi starą nazwę i włącz go z powrotem w Wygląd → Motywy.

Gdzie znaleźć log błędów WordPressa

Log błędów mówi, w którym pliku i w której linijce kod się zatrzymał. Szukaj wpisu ze słowami „PHP Fatal error”. Ścieżka w rodzaju wp-content/plugins/nazwa-wtyczki/ wskazuje wtyczkę, a wp-content/themes/ motyw. Wpis „Allowed memory size … exhausted” oznacza, że strona przekroczyła limit pamięci ustawiony na serwerze.

Podgląd logów błędów PHP ma wiele paneli hostingowych. Jeśli go nie widzisz, zapytaj pomoc techniczną hostingu.

Jak włączyć debug.log

WordPress może też zapisywać błędy sam. Zrób kopię pliku wp-config.php z katalogu strony, a potem dopisz w nim nad komentarzem „That's all, stop editing” trzy linijki:

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

Jeśli w pliku jest już linijka z WP_DEBUG, zmień w niej false na true i nie dopisuj drugiej. Potem odśwież stronę z błędem. Błędy trafią do pliku wp-content/debug.log, a ustawienie WP_DEBUG_DISPLAY na false ukrywa je przed odwiedzającymi.

Dokumentacja debugowania WordPressa odradza używanie tych ustawień na działającej stronie, bo są przeznaczone do testów. Gdy znajdziesz przyczynę, ustaw WP_DEBUG z powrotem na false i usuń plik debug.log.

Wersja PHP a błąd krytyczny

PHP to język, w którym napisane są WordPress i wtyczki. Wersję PHP zmienia czasem hosting, a czasem właściciel w panelu hostingu. Wtyczka albo motyw, których nikt dawno nie aktualizował, mogą na nowszym PHP przestać działać i wywołać błąd krytyczny.

WordPress zaleca PHP w wersji 8.3 lub nowszej. Na starszych, od 7.4, też działa, ale ta sama strona ostrzega, że to wersje po końcu oficjalnego wsparcia, które mogą narażać stronę na ataki. Wersję PHP swojej strony zobaczysz w panelu w Narzędzia → Stan witryny, w zakładce „Informacja”, w sekcji „Serwer”.

W katalogu wtyczek na WordPress.org przy wtyczce widać pole „Wersja PHP”, jeśli autor je podał, oraz „Testowano do” i „Ostatnia aktualizacja”. Wersja PHP jest tam minimalna, górnej granicy nie ma. Dlatego przed zmianą PHP zaktualizuj wtyczki i motyw i sprawdź, czy autor wydawał je w ostatnich miesiącach. Jeśli błąd pojawił się zaraz po zmianie PHP, najszybciej pomoże powrót do poprzedniej wersji w panelu hostingu. To rozwiązanie na chwilę, do czasu aktualizacji wtyczek.

Błąd po aktualizacji WordPressa: przykład 6.9.2

Czasem przyczyna leży po stronie samego WordPressa. 10 marca 2026 roku wyszedł WordPress 6.9.2 z poprawkami bezpieczeństwa. Część właścicieli zobaczyła po tej aktualizacji pustą stronę w miejscu swojej witryny. Według ogłoszenia na WordPress.org dotyczyło to motywów, które wczytywały pliki szablonów w nietypowy sposób, nieobsługiwany oficjalnie przez WordPressa. Jeszcze tego samego dnia wyszła wersja 6.9.3 z poprawką, a dzień później 6.9.4, która uzupełniła poprawki bezpieczeństwa.

Takie drobne wersje WordPress domyślnie instaluje sam, w tle. Właściciel mógł więc niczego nie klikać, a strona i tak przestała działać. Jeśli awaria zaczęła się bez Twojego udziału, zajrzyj na wordpress.org/news. Gdy jest już nowsza wersja z poprawką, zaktualizuj stronę w Kokpit → Aktualizacje. Nie cofaj WordPressa do starszej wersji, bo wróciłyby luki, które aktualizacja załatała.

Kiedy przywrócić kopię zapasową

Kopia zapasowa pomaga, gdy wiesz, kiedy zaczęła się awaria, i masz kopię sprzed tej chwili. Wiele firm hostingowych robi kopie automatycznie i pozwala je przywrócić z panelu. Przywrócenie całej strony cofa też bazę danych, więc znikną wpisy, zamówienia ze sklepu i wszystko, co dodano po dacie kopii.

Kopia nie usuwa przyczyny. Po przywróceniu wtyczka albo motyw dalej czeka na aktualizację, która raz już zepsuła stronę. Jeśli ma włączone automatyczne aktualizacje, WordPress może ją zainstalować ponownie. Odkładanie aktualizacji na długo zostawia z kolei stronę bez poprawek bezpieczeństwa. W sklepie z bieżącymi zamówieniami lepiej najpierw ustalić przyczynę z logu i naprawić sam błąd.

Kiedy oddać naprawę fachowcowi

Przestań naprawiać sam, gdy:

• Nie masz dostępu do panelu hostingu ani do FTP i nie wiesz, kto go ma.
• Błąd zostaje po wyłączeniu wszystkich wtyczek i zmianie motywu.
• Log wskazuje pliki samego WordPressa, czyli foldery wp-includes albo wp-admin, albo bazę danych.
• Widzisz nieznane pliki, przekierowania na obce strony albo konta administratorów, których nie zakładałeś.
• Strona to sklep z bieżącymi zamówieniami albo nie masz żadnej kopii zapasowej.

Jak zmniejszyć ryzyko powtórki

• Przed każdą aktualizacją rób kopię plików i bazy danych. Zaleca to dokumentacja WordPressa. Jak ją zrobić, piszemy w poradniku o kopii zapasowej WordPressa.
• Aktualizuj wtyczki pojedynczo albo małymi grupami. Po każdej aktualizacji sprawdź stronę główną, kilka podstron i formularz. Kolejne kroki opisujemy w artykule o aktualizacji WordPressa.
• Przed zmianą wersji PHP zaktualizuj wtyczki i motyw.
• Sprawdź, czy adres e-mail administratora w Ustawienia → Ogólne jest aktualny, bo na niego przychodzi link do trybu odzyskiwania. Wykonawca może ustawić na te wiadomości osobny adres stałą RECOVERY_MODE_EMAIL w pliku wp-config.php.

Najczęstsze pytania

Nie mogę zalogować się do WordPressa. Czy to ten sam problem?

Tak, jeśli zamiast formularza logowania widzisz komunikat o błędzie krytycznym albo pustą stronę. Sprawdź e-mail z linkiem do trybu odzyskiwania, a gdy go nie ma, wyłącz wtyczki przez pliki na hostingu. Jeśli formularz się wyświetla, a nie pamiętasz hasła, użyj linku „Nie pamiętasz hasła?” pod formularzem. Pozostałe przyczyny, na przykład pętlę logowania albo blokadę po kilku próbach, opisujemy w artykule Nie mogę zalogować się do WordPressa? Jak odzyskać dostęp.

Czy przez błąd krytyczny stracę treści strony?

Zwykle nie. Wpisy i strony leżą w bazie danych, zdjęcia w folderze wp-content/uploads, a błąd zatrzymuje kod, który je wyświetla. Treści można stracić przy nieostrożnej naprawie, na przykład przy przywróceniu starej kopii albo usunięciu folderów.

Co znaczy „There has been a critical error on this website”?

To angielska wersja komunikatu „W witrynie wystąpił błąd krytyczny.”. Pokazuje się, gdy strona ma ustawiony język angielski. Przyczyny i kroki naprawy są te same.

Jak to robimy w Kodarni

Naprawa strony WordPress zaczyna się u nas od bezpłatnej diagnozy. Wysyłasz adres strony i opis problemu, najlepiej z dostępem do panelu albo hostingu. Sprawdzamy logi błędów, wtyczki, motyw i wersję PHP, a cenę podajemy na piśmie, zanim zaczniemy pracę. Przed pierwszą zmianą robimy kopię plików i bazy danych. Po naprawie dostajesz krótki opis, co się zepsuło i jak uniknąć powtórki.

Naprawa kosztuje od 199 zł netto, do tego 23% VAT. Kwota „od” dotyczy prostych awarii, na przykład jednej wtyczki, która po aktualizacji wyłączyła stronę. Jednorazowa aktualizacja WordPressa z kopią i sprawdzeniem strony kosztuje 149 zł netto, a w opiece nad stroną, od 99 zł netto miesięcznie, aktualizacje z kopią robimy co miesiąc.

Naprawa strony WordPress: bezpłatna diagnoza, naprawa od 199 zł

Opieka nad stroną: aktualizacje z kopią od 99 zł miesięcznie