Błąd krytyczny na stronie WordPress: co oznacza i jak go naprawić krok po kroku

Jeśli zamiast swojej strony widzisz krótki komunikat o błędzie krytycznym, strona nie została skasowana i najpewniej nikt się na nią nie włamał. WordPress przerwał wyświetlanie, bo jeden z elementów kodu zgłosił błąd, z którym nie potrafi sobie poradzić. Twoje treści, zdjęcia i ustawienia są nadal w bazie danych i w plikach na serwerze. Zadanie polega na znalezieniu elementu, który psuje stronę, i wyłączeniu go albo naprawieniu.

Poniżej opisujemy kolejność działań, którą stosujemy przy naprawach. Zaczynamy od kroków, które nie wymagają dostępu do plików, a kończymy na tych, przy których potrzebny jest panel hostingu. Przy każdym kroku piszemy, co powinieneś zobaczyć i co zrobić, jeśli wynik jest inny.

Błąd krytyczny WordPress: co dokładnie oznacza ten komunikat

WordPress jest napisany w języku PHP. Kiedy ktoś otwiera stronę, serwer uruchamia kod WordPressa, motywu i wszystkich włączonych wtyczek. Jeśli któryś fragment wywoła tak zwany błąd krytyczny (ang. fatal error), PHP przerywa pracę i strona nie może się wyświetlić.

Do 2019 roku w takiej sytuacji odwiedzający widzieli zwykle pustą, białą stronę. W wersji 5.2 WordPress dostał mechanizm ochrony przed błędami krytycznymi: zamiast pustej strony pokazuje krótki komunikat, a na adres e-mail administratora wysyła wiadomość z opisem problemu i linkiem do trybu odzyskiwania (ang. recovery mode). W polskiej wersji komunikat brzmi: „W witrynie wystąpił błąd krytyczny”.

Ważne: komunikat mówi tylko, że wystąpił błąd. Nie mówi, gdzie. Tę informację znajdziesz w e-mailu albo w dzienniku błędów, o czym niżej.

Najczęstsze przyczyny

Na podstawie naszych napraw i dokumentacji WordPressa przyczyny układają się mniej więcej w taką kolejność:

1. Aktualizacja wtyczki. Nowa wersja wtyczki wymaga nowszego PHP, innej wersji WordPressa albo gryzie się z inną wtyczką. Typowy objaw: strona przestała działać w nocy lub zaraz po kliknięciu „Aktualizuj”.
2. Zmiana wersji PHP na serwerze. Hosting podniósł wersję PHP (np. z 7.4 na 8.x), a stara wtyczka lub motyw używa funkcji, których nowe PHP już nie ma.
3. Motyw. Zmiana w pliku functions.php motywu, wklejony fragment kodu z internetu albo aktualizacja motywu bez motywu potomnego.
4. Brak pamięci. Strona z wieloma wtyczkami przekracza limit pamięci PHP ustawiony na hostingu.
5. Przerwana aktualizacja. Aktualizacja WordPressa lub wtyczki przerwała się w połowie i część plików jest niekompletna.

Rzadziej przyczyną jest uszkodzona baza danych albo złośliwy kod po włamaniu. Te sytuacje mają zwykle dodatkowe objawy, opisujemy je na końcu.

Zanim zaczniesz: zrób kopię

Ten krok wydaje się zbędny, skoro strona i tak nie działa. Jest odwrotnie. Przy naprawie zmieniasz pliki i ustawienia, a pomyłka (np. usunięcie folderu zamiast zmiany jego nazwy) może zamienić problem na kilka minut w problem na kilka dni.

• Kopia w panelu hostingu. Większość polskich hostingów (DirectAdmin, cPanel, panele autorskie) ma przycisk „Kopia zapasowa” lub „Backup”. Zaznacz pliki i bazę danych.
• Kopia automatyczna. Sprawdź, czy hosting nie ma już kopii z dnia przed awarią. Jeśli ma, zapisz jej datę. Może się przydać jako plan B.
• Dane dostępowe. Przygotuj login do panelu hostingu. Bez niego wykonasz tylko kroki 1 i 2.

Krok 1. Sprawdź e-mail administratora

Przy błędzie krytycznym WordPress wysyła wiadomość na adres ustawiony w Ustawienia → Ogólne → Adres e-mail administratora. W treści jest nazwa wtyczki lub motywu, w którym wystąpił błąd, fragment komunikatu PHP i link do trybu odzyskiwania.

Co powinieneś zobaczyć: wiadomość z tematem o problemie technicznym na stronie, wysłaną mniej więcej w momencie awarii. Sprawdź też folder spam i oferty.

Jeśli wiadomości nie ma, powody są zwykle trzy: adres administratora jest nieaktualny (np. adres poprzedniego wykonawcy), strona nie potrafi wysyłać poczty (częsty problem, opisujemy go w artykule Formularz kontaktowy, który nie gubi zapytań) albo błąd jest tak wczesny, że mechanizm ochrony nie zdążył zadziałać. Wtedy przejdź do kroku 3.

Krok 2. Wejdź w tryb odzyskiwania i wyłącz winowajcę

Link z e-maila otwiera panel WordPressa w specjalnym trybie. Winna wtyczka lub motyw są w nim wstrzymane tylko dla Ciebie, więc możesz się zalogować i działać normalnie.

1. Kliknij link z e-maila i zaloguj się swoim kontem administratora.
2. Na górze panelu zobaczysz informację o trybie odzyskiwania i nazwę elementu, który spowodował błąd.
3. Wejdź w Wtyczki i przy wskazanej wtyczce kliknij Wyłącz. Jeśli winny jest motyw, wejdź w Wygląd → Motywy i włącz inny motyw, najlepiej domyślny motyw WordPressa.
4. Kliknij Wyjdź z trybu odzyskiwania i otwórz stronę w oknie prywatnym przeglądarki.

Co powinieneś zobaczyć: strona działa. Jeśli wyłączyłeś wtyczkę, część funkcji może zniknąć (np. formularz, galeria). To normalne, wtyczkę włączysz ponownie po naprawie.

Uwaga na czas: link do trybu odzyskiwania jest ważny przez ograniczony czas (domyślnie dobę). Jeśli wygasł, WordPress wyśle nowy przy kolejnym wystąpieniu błędu, ale nie częściej niż co jakiś czas. Jeśli nie chcesz czekać, przejdź do kroku 3.

Krok 3. Włącz dziennik błędów i przeczytaj, co się stało

To najważniejszy krok, bo zamienia zgadywanie w konkretną odpowiedź. Potrzebny jest dostęp do plików strony: menedżer plików w panelu hostingu albo program FTP (np. FileZilla).

1. W głównym folderze strony (zwykle public_html lub domains/twojadomena.pl/public_html) znajdź plik wp-config.php. Pobierz jego kopię na komputer.
2. Otwórz plik do edycji i znajdź linię z WP_DEBUG. Zamień ją na trzy poniższe linie. Jeśli takiej linii nie ma, wklej je nad linią z komentarzem, który kończy edycję (w polskiej wersji zaczyna się od „To wszystko”).

define( 'WP_DEBUG', true );          // włącza zgłaszanie błędów
define( 'WP_DEBUG_LOG', true );      // zapisuje błędy do pliku wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // nie pokazuje błędów odwiedzającym

3. Zapisz plik i odśwież stronę, na której widać błąd. To zapisze błąd do dziennika.
4. Otwórz plik wp-content/debug.log i przewiń na sam dół.

Co powinieneś zobaczyć: linię zaczynającą się od PHP Fatal error. Najważniejsza jest w niej ścieżka do pliku. Przykład:

PHP Fatal error: Uncaught Error: Call to undefined function create_function()
in /home/.../public_html/wp-content/plugins/stary-slider/slider.php:112

Fragment wp-content/plugins/stary-slider mówi, że winna jest wtyczka w folderze stary-slider. Gdyby ścieżka zawierała wp-content/themes/nazwa-motywu, winny byłby motyw. Treść błędu też coś mówi: w tym przykładzie funkcja create_function() została usunięta w PHP 8.0, więc najpewniej hosting podniósł wersję PHP, a wtyczka jest za stara.

Inne częste komunikaty i ich znaczenie:

Jeśli pliku debug.log nie ma, sprawdź dziennik błędów w panelu hostingu (zwykle „Logi”, „Error log” lub „Dziennik błędów”). Niektóre serwery zapisują błędy PHP tylko tam.

Po naprawie przywróć w wp-config.php linię define( 'WP_DEBUG', false ); i usuń plik debug.log. Dziennik może zawierać ścieżki serwera i fragmenty danych, nie powinien leżeć na stronie.

Krok 4. Wyłącz wtyczkę bez panelu WordPressa

Jeśli wiesz, która wtyczka jest winna, przejdź w menedżerze plików do wp-content/plugins i zmień nazwę jej folderu, np. z stary-slider na stary-slider-wylaczona. WordPress nie znajdzie wtyczki i automatycznie ją wyłączy.

Jeśli nie wiesz, która to wtyczka, zmień nazwę całego folderu plugins na plugins-stary. Wyłączysz w ten sposób wszystkie wtyczki naraz.

1. Odśwież stronę. Jeśli działa (bez funkcji z wtyczek), problem jest w jednej z wtyczek.
2. Przywróć folderowi nazwę plugins. Wtyczki pozostaną wyłączone w panelu.
3. Zaloguj się do panelu i włączaj wtyczki po jednej, za każdym razem sprawdzając stronę. Ta, po której włączeniu wraca błąd, jest winna.

Uwaga: zmiana nazwy folderu nie usuwa danych wtyczki. Nie usuwaj jednak folderu ani wtyczki z panelu, dopóki nie wiesz, czy ustawienia są Ci potrzebne. Niektóre wtyczki przy usuwaniu kasują też swoje dane z bazy.

Gdy znasz winowajcę, masz trzy wyjścia: zaktualizować wtyczkę (jeśli wyszła poprawka), wrócić do poprzedniej wersji albo zastąpić ją inną. Jeśli wtyczka nie była aktualizowana od ponad roku, w repozytorium WordPressa zobaczysz ostrzeżenie o braku testów z nowymi wersjami. To sygnał, żeby szukać zamiennika.

Krok 5. Sprawdź motyw i wersję PHP

Motyw. Jeśli ścieżka w dzienniku prowadzi do wp-content/themes, zmień nazwę folderu aktywnego motywu. WordPress przełączy się na inny zainstalowany motyw, najczęściej domyślny (jego nazwa zaczyna się od „Twenty”). Strona będzie wyglądać inaczej, ale zacznie działać i odzyskasz dostęp do panelu. Jeśli w folderze themes nie ma żadnego innego motywu, wgraj domyślny motyw pobrany z wordpress.org.

Wersja PHP. Jeśli błąd pojawił się bez żadnej aktualizacji z Twojej strony, zapytaj hosting albo sprawdź w panelu, czy nie zmieniła się wersja PHP. W większości paneli zmienisz ją w sekcji „Wybór wersji PHP” lub „PHP Selector”. Powrót do poprzedniej wersji to dobre rozwiązanie awaryjne, ale tymczasowe. Starsze wersje PHP przestają dostawać poprawki bezpieczeństwa, a WordPress podaje aktualnie zalecaną wersję na stronie z wymaganiami. Docelowo trzeba zaktualizować lub wymienić wtyczkę, która nie działa na nowym PHP.

Krok 6. Gdy brakuje pamięci

Komunikat Allowed memory size ... exhausted oznacza, że strona chciała użyć więcej pamięci, niż pozwala ustawienie. W pliku wp-config.php, nad linią kończącą edycję, możesz dodać:

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

To ustawienie działa tylko do limitu, który pozwala hosting. Jeśli limit serwera jest niższy, trzeba go podnieść w panelu hostingu albo poprosić o to obsługę. Warto też zapytać, dlaczego strona potrzebuje tyle pamięci. Często przyczyną jest jedna źle napisana wtyczka, a podnoszenie limitu tylko odsuwa problem.

Kiedy przestać i poprosić o pomoc

Powyższe kroki rozwiązują większość przypadków. Są jednak sytuacje, w których dalsze samodzielne działania zwiększają szkody:

• Dziennik pokazuje błędy w plikach, których nie rozpoznajesz, np. o dziwnych nazwach w folderze wp-includes albo w wp-content/uploads. To może być ślad włamania, opisany w poradniku WordPress po włamaniu: pierwsze 24 godziny. Pliki PHP w folderze uploads są szczególnie podejrzane.
• Błąd dotyczy bazy danych (komunikaty z mysqli lub wpdb), a nie wtyczki.
• Strona to sklep. Wyłączenie wtyczki płatności czy WooCommerce w złym momencie może zablokować zamówienia lub zepsuć ich stany.
• Po wyłączeniu wszystkich wtyczek i zmianie motywu błąd nadal występuje.

W takiej sytuacji zostaw stronę w obecnym stanie, zapisz, co już zmieniłeś, i przekaż te informacje osobie, która będzie naprawiać. Lista zmian i fragment dziennika skracają naprawę o połowę.

Jak zapobiegać

• Aktualizuj świadomie. Duże aktualizacje (wtyczki do sklepu, kreatory stron, nowa wersja WordPressa) najpierw na kopii testowej albo przynajmniej w godzinach, w których możesz zareagować. Więcej piszemy w artykule Aktualizacje WordPressa i wtyczek: jak często i jak to robić bezpiecznie.
• Kopia przed każdą aktualizacją. Automatyczna, codzienna, przechowywana poza serwerem strony, zgodnie z zasadą 3-2-1.
• Aktualny adres administratora. Bez niego nie dostaniesz e-maila z trybem odzyskiwania.
• Mniej wtyczek. Każda wtyczka to kolejny kod, który może się zepsuć. Usuń te, których nie używasz.
• Kontrola wersji PHP. Raz w roku sprawdź w Narzędzia → Zdrowie witryny, czy WordPress nie zgłasza przestarzałej wersji PHP, i zaplanuj zmianę, zanim zrobi ją hosting.
• Własny kod w motywie potomnym lub w osobnej wtyczce, nigdy bezpośrednio w motywie, który się aktualizuje.

Jeśli zamiast błędu krytycznego widzisz komunikat o połączeniu z bazą danych, zobacz poradnik Error establishing a database connection. Jeśli strona działa, ale nie możesz wejść do panelu, przejdź do poradnika Nie mogę zalogować się do WordPressa.

Źródła

• WordPress Core: Fatal Error Recovery Mode in 5.2 (dostęp: 9.11.2026)
• WordPress Developer Resources: Debugging in WordPress (dostęp: 9.11.2026)
• WordPress Developer Resources: Editing wp-config.php (WP_MEMORY_LIMIT) (dostęp: 9.11.2026)
• WordPress.org: Requirements (zalecana wersja PHP) (dostęp: 9.11.2026)
• PHP Manual: Backward Incompatible Changes in PHP 8.0 (usunięcie create_function) (dostęp: 9.11.2026)
• PHP: Supported Versions (dostęp: 9.11.2026)