Błąd krytyczny w witrynie WordPress — jak go naprawić krok po kroku

Komunikat „W witrynie wystąpił błąd krytyczny” wygląda groźnie, ale w większości przypadków da się go usunąć w kilkanaście minut, bez utraty treści. Trudność polega na tym, że sam ekran nic nie mówi o przyczynie. Ten poradnik pokazuje, jak ją znaleźć, w kolejności, w jakiej sami diagnozujemy zgłoszenia.

Kroki oznaczyliśmy według tego, jakim dostępem dysponujesz:

• Poziom 1 — przeglądarka i poczta. Masz login do WordPressa i dostęp do skrzynki administratora. Tyle wystarczy na pierwsze kroki.
• Poziom 2 — panel hostingu lub FTP. Możesz edytować pliki na serwerze (menedżer plików, FileZilla, WinSCP).
• Poziom 3 — SSH i WP-CLI. Masz dostęp do konsoli serwera. Najszybsza droga, jeśli hosting ją udostępnia.

Jeśli Twoja strona pokazuje inny objaw (pusty biały ekran, „Error establishing a database connection”, sam błąd 500 bez komunikatu WordPressa), zacznij od pełnej diagnozy, gdy strona WordPress nie działa. Tam rozdzielamy objawy i kierujemy do właściwej instrukcji.

Co oznacza komunikat o błędzie krytycznym

WordPress jest napisany w PHP. Gdy kod wtyczki, motywu albo samego WordPressa trafi na błąd, którego PHP nie potrafi obejść (tzw. fatal error), wykonanie się zatrzymuje i strona nie powstaje. Od wersji 5.2 WordPress przechwytuje taki błąd i zamiast pustej strony pokazuje własny komunikat. Serwer odpowiada przy tym kodem HTTP 500, więc z punktu widzenia Google i narzędzi do monitoringu strona jest niedostępna.

Dwie wersje komunikatu i co z nich wynika

W polskim WordPressie 7.1 zobaczysz jeden z dwóch tekstów. Od tego, który widzisz, zależy następny krok:

Sprawdziliśmy to na WordPressie 7.1.3 z wtyczką, która celowo wywołuje błąd. Ten sam błąd na stronie głównej dał tylko pierwszy komunikat i żadnego maila. Na stronie logowania pojawił się drugi komunikat i mail został wysłany. Wynika to z kodu WordPressa: wiadomość z trybem odzyskiwania powstaje tylko wtedy, gdy błąd wystąpi na tzw. chronionej stronie, czyli w panelu lub na stronie logowania.

W starszych wersjach i tłumaczeniach komunikat brzmiał też „W tej witrynie wystąpił błąd krytyczny”, a na stronach bez polskiego pakietu: „There has been a critical error on this website”. Postępowanie jest identyczne.

Błąd krytyczny a biały ekran

To ten sam problem, tylko inaczej podany. Biały ekran zobaczysz, gdy mechanizm przechwytywania błędów jest wyłączony (stała WP_DISABLE_FATAL_ERROR_HANDLER), gdy błąd wystąpi bardzo wcześnie, zanim WordPress się załaduje, albo gdy problem leży po stronie serwera. Metody z tego poradnika (log błędów, wyłączanie wtyczek przez FTP) działają w obu przypadkach.

Czy Twoje treści są bezpieczne

Prawie zawsze tak. Błąd krytyczny przerywa wykonanie kodu, ale nie usuwa wpisów, stron, produktów ani zamówień zapisanych w bazie danych. Gdy wyłączysz winowajcę, wszystko wraca na swoje miejsce. Dane możesz natomiast stracić przez pochopne działania naprawcze, opisane w następnej sekcji.

Wyjątkiem jest sklep. W czasie awarii bramki płatności (Przelewy24, PayU, Stripe) nie mogą przekazać sklepowi informacji o wpłacie, bo strona odpowiada błędem 500. Klient zapłacił, a zamówienie wisi jako „Oczekujące na płatność”. Jak to wyprostować, piszemy w liście kontrolnej po naprawie.

Czego nie robić, zanim poznasz przyczynę

• Nie przywracaj na ślepo starej kopii zapasowej. Kopia z zeszłego tygodnia cofnie też zamówienia, wiadomości z formularzy i zmiany w treści z tego okresu. Do tego, jeśli przyczyną jest np. zmiana PHP po stronie hostingu, po przywróceniu błąd wróci. Kopia bywa najszybszą drogą tylko wtedy, gdy od jej wykonania na stronie nic się nie zmieniło: wizytówka bez nowych treści, zamówień i zgłoszeń z formularza.
• Nie usuwaj wtyczek, tylko je wyłączaj. Usunięcie wtyczki z panelu uruchamia jej procedurę odinstalowania, która u części wtyczek kasuje ustawienia i tabele w bazie. Wyłączenie (albo zmiana nazwy folderu) niczego nie kasuje.
• Nie reinstaluj WordPressa „od zera”. Instalacja w nowym katalogu albo z nową bazą to praca na kilka godzin, a problem zwykle siedzi w jednej wtyczce.
• Nie włączaj wyświetlania błędów na działającej stronie. Ustawienie WP_DEBUG na true bez WP_DEBUG_DISPLAY na false pokazuje komunikaty PHP wszystkim odwiedzającym, razem ze ścieżkami katalogów na serwerze. Bezpieczny wariant pokazujemy niżej.

Drzewko diagnozy: od czego zacząć

Wybierz sytuację, która pasuje do Twojej. Każda gałąź prowadzi do konkretnego kroku w dalszej części tekstu.

Strona publiczna pokazuje błąd, ale do panelu /wp-admin/ da się zalogować

Najlepszy możliwy scenariusz. Wejdź w Wtyczki i wyłącz tę, którą ostatnio instalowałeś lub aktualizowałeś. Jeśli nie wiesz którą, przejdź do sekcji o logu błędów i ustal ją z debug.log. Gdy wtyczki są czyste, sprawdź motyw (Wygląd → Motywy, przełącz tymczasowo na domyślny).

Panel też pokazuje błąd, a w skrzynce jest mail „Twoja witryna ma problemy techniczne”

Kliknij link z maila i wejdź w tryb odzyskiwania. Szczegóły w sekcji o trybie odzyskiwania. Link jest jednorazowy i ma ograniczony czas ważności.

Panel pokazuje błąd, maila nie ma, ale masz dostęp do panelu hostingu lub FTP

Włącz zapis błędów do pliku w wp-config.php, odczytaj debug.log, a potem wyłącz wskazaną wtyczkę, zmieniając nazwę jej folderu. To poziom 2: sekcje o logu błędów i o wyłączaniu wtyczek.

Masz dostęp SSH do serwera

Użyj WP-CLI z przełącznikami --skip-plugins --skip-themes. Bez nich WP-CLI też trafi na błąd krytyczny, bo ładuje te same wtyczki co strona. Wyjątek: wtyczek „must-use” i drop-inów te przełączniki nie pomijają. Komendy są w sekcji o wyłączaniu wtyczek.

Nie masz ani panelu hostingu, ani FTP, ani maila administratora

Sam niewiele zrobisz. Napisz do hostingu z prośbą o wpis z logu błędów z godziny awarii albo o dane dostępowe FTP. Jeśli stronę robiła agencja, poproś ją o te dostępy, bo należą do Ciebie. Gdy liczy się czas, to dobry moment, żeby zlecić naprawę (o tym pod koniec poradnika).

Nie widzisz komunikatu WordPressa, tylko pustą stronę lub błąd serwera

To inny objaw. Skorzystaj z diagnozy niedziałającej strony WordPress, gdzie rozdzielamy biały ekran, błędy 500 i 503 oraz problemy z bazą danych.

Tryb odzyskiwania z maila administratora

Poziom 1. Gdy wtyczka lub motyw wywoła błąd krytyczny w panelu, WordPress wysyła na adres administratora wiadomość z tematem „[Nazwa strony] Twoja witryna ma problemy techniczne” (po angielsku: „Your Site is Experiencing a Technical Issue”). W treści znajdziesz:

• nazwę wtyczki lub motywu, który spowodował błąd (np. „WordPress wykrył błąd w używanej wtyczce: …”),
• sekcję „Szczegóły błędu” z typem błędu, plikiem, numerem linii i komunikatem,
• wersje WordPressa, PHP, motywu i wtyczki,
• specjalny link logowania do trybu odzyskiwania (w polskim panelu nazywa się on „trybem awaryjnym”).

Jak użyć trybu odzyskiwania

1. Kliknij link z maila. Otworzy się strona logowania z komunikatem „Włączono Tryb awaryjny. Zaloguj się, by kontynuować.” Zaloguj się kontem administratora.
2. Otwórz Wtyczki (albo Wygląd → Motywy). Wtyczka, która spowodowała błąd, jest w trybie odzyskiwania wstrzymana tylko dla Twojej sesji i oznaczona jako „Wstrzymana”. Odwiedzający nadal widzą błąd.
3. Wyłącz wskazaną wtyczkę. Dopiero wyłączenie naprawia stronę dla wszystkich. Samo wyjście z trybu awaryjnego przywraca stan sprzed naprawy.
4. Kliknij „Wyjdź z trybu awaryjnego” na górnym pasku i sprawdź stronę w oknie prywatnym przeglądarki.
5. Zdecyduj, co dalej z wtyczką. Zaktualizuj ją, przywróć poprzednią wersję albo znajdź zamiennik. Nie włączaj jej ponownie, dopóki nie wiesz, co poszło nie tak.

Link działa jednorazowo i wygasa. Domyślnie po dobie, tyle samo co limit wysyłki maili. Jeśli wygasł, a błąd nadal występuje, WordPress wyśle nowy, ale nie wcześniej niż po upływie tej doby.

Mail nie przyszedł — co sprawdzić

• Błąd jest tylko na stronie publicznej. Wtedy maila nie będzie. Wejdź na twojadomena.pl/wp-admin/. Jeśli panel działa, nie potrzebujesz trybu odzyskiwania, tylko zaloguj się normalnie i wyłącz wtyczkę.
• Spam i zakładki. Szukaj po temacie „problemy techniczne” i „Technical Issue”, także w folderze Oferty lub Powiadomienia.
• Adres administratora jest nieaktualny. W polskich firmach często jest tam skrzynka agencji, która robiła stronę, albo dawnego pracownika. Adres sprawdzisz w Ustawienia → Ogólne albo komendą wp option get admin_email --skip-plugins --skip-themes.
• Limit jednego maila na dobę. Jeśli ktoś już wcześniej wywołał błąd w panelu, kolejny mail przyjdzie dopiero po 24 godzinach.
• Serwer nie wysyła poczty. Zdarza się na hostingach z wyłączoną funkcją mail() albo gdy serwer strony nie jest wpisany w rekord SPF domeny i skrzynka odbiorcy odrzuca wiadomość. Jeśli z tej strony nie przychodzą też maile z formularza kontaktowego, to prawdopodobnie ta przyczyna.
• Błąd nie dotyczy wtyczki ani motywu. Tryb odzyskiwania obsługuje tylko zwykłe wtyczki i motywy. Błędy w plikach WordPressa, w wp-config.php, we wtyczkach typu „must-use” (wp-content/mu-plugins, często instalowanych przez hosting) ani w tzw. drop-inach (plikach takich jak object-cache.php leżących bezpośrednio w wp-content) nie wygenerują maila. Maila nie będzie też, gdy wtyczka wywołała błąd, ale PHP zgłosił go w pliku z wp-includes. WordPress rozpoznaje sprawcę wyłącznie po ścieżce pliku z komunikatu błędu.
• Strona działa jako multisite. W sieci witryn tryb odzyskiwania jest wyłączony, więc maila nie będzie nigdy. Przejdź od razu do logu błędów i FTP lub WP-CLI.

Na przyszłość możesz wskazać osobny adres dla tych powiadomień, niezależny od adresu administratora. Dopisz w wp-config.php nad linią /* That's all, stop editing! */:

define( 'RECOVERY_MODE_EMAIL', 'serwis@twojafirma.pl' );

Link z parametrem entered_recovery_mode nie zadziała

W wielu poradnikach, także polskich tłumaczeniach, pojawia się rada, żeby wejść na /wp-login.php?action=entered_recovery_mode i uruchomić tryb odzyskiwania bez maila. To nie działa. Sprawdziliśmy w kodzie WordPressa i na żywej instalacji: ten adres wyświetla komunikat „Włączono Tryb awaryjny. Zaloguj się, by kontynuować.”. Brzmi jak potwierdzenie i dlatego trik wygląda wiarygodnie, ale trybu nie włącza. Prawdziwy link zawiera jednorazowy token i klucz (action=enter_recovery_mode&rm_token=…&rm_key=…), które znajdziesz wyłącznie w mailu. Bez nich po zalogowaniu trafisz na ten sam błąd.

Odczytaj przyczynę z logu błędów

Poziom 2. Gdy nie ma maila albo chcesz zobaczyć pełny obraz, potrzebujesz logu błędów PHP. W nim znajdziesz dokładny plik i linię, w której kod się zatrzymał. Bez tego wyłączanie wtyczek to zgadywanie.

Jak bezpiecznie włączyć tryb debugowania (WP_DEBUG)

Otwórz wp-config.php w głównym katalogu strony (zwykle public_html albo domains/twojadomena.pl/public_html) przez menedżer plików lub FTP. Jeśli plik zawiera już linię define( 'WP_DEBUG', false );, zastąp ją. Pozostałe linie dopisz nad komentarzem /* That's all, stop editing! */:

// Diagnostyka — USUŃ po naprawie
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );          // zapis do wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );     // nie pokazuj błędów odwiedzającym
@ini_set( 'display_errors', 0 );

Linia WP_DEBUG_DISPLAY jest tu najważniejsza. Gdy włączysz samo WP_DEBUG, WordPress domyślnie wyświetla komunikaty PHP w treści strony, czyli każdemu odwiedzającemu i robotom Google. Dokumentacja WordPressa wprost odradza debugowanie na działającej stronie, ale gdy strona i tak leży, zapis do pliku jest najmniej ryzykowną formą.

Od WordPressa 5.1 zamiast true możesz podać własną ścieżkę pliku. Ustaw ją poza katalogiem publicznym, jeśli hosting na to pozwala:

define( 'WP_DEBUG_LOG', dirname( __DIR__ ) . '/wp-debug.log' );

Plik trafi wtedy piętro wyżej niż public_html i nie da się go pobrać z przeglądarki. Jeśli po odświeżeniu strony plik się nie pojawi, hosting blokuje zapis poza katalogiem strony (ograniczenie open_basedir). Wróć wtedy do true i usuń debug.log zaraz po diagnozie.

Na poziomie 3 to samo zrobisz bez edytora:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Komendy wp config działają, zanim WordPress się załaduje, więc błąd krytyczny im nie przeszkadza.

Teraz odśwież stronę, na której widzisz błąd (stronę główną i /wp-admin/), i otwórz plik wp-content/debug.log.

Jeśli błąd pojawia się tylko przy jednej czynności (dodanie do koszyka, przejście do kasy, zapis wpisu w edytorze), wykonaj ją jeszcze raz po włączeniu logu. Takie operacje często idą w tle (AJAX, REST API), więc zamiast ekranu z komunikatem widzisz kręcące się kółko albo ogólne „Wystąpił błąd”. Wpis w debug.log pojawi się mimo to.

Testując, pamiętaj o cache. Wtyczka cache (np. LiteSpeed Cache, WP Rocket) albo Cloudflare mogą pokazywać zapisaną wersję strony: sprzed awarii albo z czasu awarii, już po naprawie. Sprawdzaj stronę jako zalogowany administrator albo z dopisanym do adresu parametrem, za każdym razem innym, np. ?test=123, ?test=124.

Gdzie szukać logów na hostingu

Niezależnie od debug.log serwer prowadzi własny dziennik błędów. Przydaje się, gdy WordPress nie zdążył nic zapisać, bo błąd wystąpił przed jego załadowaniem.

• cPanel (wiele polskich i zagranicznych hostingów): sekcja Metryki → Błędy pokazuje ostatnie 300 wpisów z logu serwera WWW. Błędy PHP często trafiają też do pliku error_log w katalogu, w którym wykonał się skrypt, np. public_html/error_log lub public_html/wp-admin/error_log.
• DirectAdmin (m.in. hostingi oparte na tym panelu, często z serwerem LiteSpeed): Site Summary / Statistics / Logs (w polskiej wersji panelu nazwa bywa przetłumaczona), przy domenie link Error Log. Bieżący log otworzysz tylko w panelu. W katalogu domains/twojadomena.pl/logs/, widocznym przez FTP, są zwykle archiwa z poprzednich okresów (pliki .tar.gz), a nie wpisy sprzed kilku minut.
• Panele autorskie (home.pl, nazwa.pl, LH.pl i inne): nazwy i miejsca różnią się między panelami i potrafią zmieniać się po aktualizacjach. Szukaj pozycji „Logi”, „Dziennik błędów” lub „Statystyki”. Jeśli ich nie ma, debug.log WordPressa działa na każdym hostingu.

Jak czytać wpis w debug.log

Typowy plik zawiera dziesiątki ostrzeżeń „Deprecated” i „Warning”. Nie przejmuj się nimi, one nie zatrzymują strony. Szukaj linii z PHP Fatal error albo PHP Parse error z godziny, w której odświeżałeś stronę (czas w logu jest zwykle w UTC, czyli o 1–2 godziny wcześniej niż czas polski). Przykład:

[12-Oct-2026 08:14:03 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_order() in /home/firma/domains/firma.pl/public_html/wp-content/plugins/faktury-sklep/includes/class-invoice.php:88
Stack trace:
#0 /home/firma/domains/firma.pl/public_html/wp-includes/class-wp-hook.php(341): Faktury_Sklep->on_order()
#1 …

Jak to czytać:

• Typ i komunikat (Uncaught Error: Call to undefined function wc_get_order()) mówią, co się stało. Tu kod wywołał funkcję WooCommerce, której nie ma, bo WooCommerce jest wyłączony albo jeszcze się nie załadował.
• Ścieżka wskazuje sprawcę. Folder zaraz po /plugins/ to wtyczka (tu faktury-sklep), po /themes/ motyw. Ścieżka w wp-includes lub wp-admin oznacza, że błąd ujawnił się w plikach WordPressa. Wtedy patrz w Stack trace, która wtyczka je wywołała.
• Numer po dwukropku (:88) to linia w pliku. Przyda się, jeśli przekażesz sprawę autorowi wtyczki lub programiście.

Plik, w którym wystąpił błąd, nie zawsze należy do winowajcy. Gdy błąd wskazuje plik WooCommerce lub Elementora, przyczyną bywa dodatek, który przekazał mu złe dane. Pierwsze linie Stack trace pokazują, kto wywołał dany kod.

Na poziomie 3 ostatnie błędy krytyczne wyciągniesz jedną komendą:

grep -n "PHP Fatal\|PHP Parse" wp-content/debug.log | tail -n 20

Tabela: komunikat → przyczyna → co zrobić

Najczęstsze komunikaty, które widzimy w logach przy błędzie krytycznym. Wielokropek zastępuje nazwę funkcji, klasy lub pliku, która będzie inna na Twojej stronie.

Wyłącz wtyczkę, która powoduje błąd

Wiesz już z logu albo z maila, która wtyczka zawiniła. Teraz trzeba sprawić, żeby WordPress przestał ją ładować. Wybierz sposób odpowiedni do swojego dostępu.

Poziom 2: przez menedżer plików lub FTP

1. Przejdź do wp-content/plugins. Każda wtyczka ma tu swój folder.
2. Zmień nazwę folderu winnej wtyczki, np. z faktury-sklep na faktury-sklep.off. WordPress nie znajdzie jej pliku i przestanie ją ładować. Ustawienia wtyczki w bazie danych zostają.
3. Odśwież stronę, a potem wejdź do panelu → Wtyczki. WordPress pokaże komunikat, że wtyczka została wyłączona, bo nie istnieje jej plik. Dopiero od tej chwili jest nieaktywna także w bazie danych. Ten krok jest konieczny: jeśli przywrócisz nazwę folderu przed wejściem na ekran Wtyczki, WordPress znów ją załaduje i błąd wróci.
4. Przywróć oryginalną nazwę folderu. Wtyczka jest już nieaktywna, więc się nie załaduje. Zaktualizuj ją albo wgraj jej poprzednią wersję i dopiero potem włącz ją i sprawdź stronę.

Jeśli nie wiesz, która wtyczka zawiniła, zmień nazwę całego folderu plugins na plugins.off. Strona powinna ruszyć bez wtyczek. Zaloguj się wtedy do panelu i otwórz Wtyczki (WordPress odnotuje, że wszystkie zniknęły, i oznaczy je jako wyłączone), przywróć nazwę folderu i włączaj wtyczki po kolei, sprawdzając stronę po każdej.

Poziom 3: przez WP-CLI

WP-CLI ładuje WordPressa tak samo jak przeglądarka, więc bez dodatkowych przełączników zobaczysz w konsoli „Error: W witrynie wystąpił błąd krytyczny.”. Przełączniki --skip-plugins i --skip-themes pomijają wtyczki i motyw, dzięki czemu WP-CLI działa także na „leżącej” stronie. Sprawdziliśmy to na WordPressie 7.1.3 i WP-CLI 2.12.

Wyjątek: --skip-plugins nie pomija wtyczek „must-use” (wp-content/mu-plugins) ani drop-inów (object-cache.php, advanced-cache.php, db.php w wp-content). Jeśli log wskazuje któryś z tych plików, WP-CLI z przełącznikami nadal pokaże błąd krytyczny. Przenieś wtedy ten plik tymczasowo poza katalog strony, np. mv wp-content/object-cache.php ~/object-cache.php.bak, i opisane niżej kroki wykonaj potem.

# wersje PHP, WP-CLI i ścieżki
wp --info

# lista aktywnych wtyczek (bez ładowania wtyczek i motywu)
wp plugin list --status=active --skip-plugins --skip-themes

# wyłączenie jednej wtyczki
wp plugin deactivate faktury-sklep --skip-plugins --skip-themes

Gdy trzeba wyłączyć wszystko, najpierw zapisz listę aktywnych wtyczek, żeby potem przywrócić dokładnie ten sam stan:

wp plugin list --status=active --field=name --skip-plugins --skip-themes > aktywne-wtyczki.txt
wp plugin deactivate --all --skip-plugins --skip-themes

# po naprawie — włączenie z powrotem
wp plugin activate $(cat aktywne-wtyczki.txt) --skip-plugins --skip-themes

Poprzednią wersję wtyczki z katalogu WordPress.org zainstalujesz komendą wp plugin install nazwa --version=1.2.3 --force --skip-plugins --skip-themes. Przełącznik --force nadpisuje folder bez pytania, więc najpierw go skopiuj (cp -r wp-content/plugins/nazwa ~/nazwa.bak) i upewnij się, że to ta sama wtyczka, co pod adresem wordpress.org/plugins/nazwa/. Wtyczka płatna albo własna o tej samej nazwie folderu zostałaby zastąpiona obcym kodem. Wtyczki płatne (spoza WordPress.org) trzeba wgrać z paczki pobranej z konta u producenta.

Błąd wraca po włączeniu wtyczek

Strona działa bez wtyczek, ale po włączeniu wszystkich z powrotem znów pada, choć każda osobno działa. To konflikt dwóch wtyczek albo wtyczki z motywem. Włączanie po jednej przy 30 wtyczkach zajmuje dużo czasu, więc stosujemy metodę połówkową:

1. Włącz połowę wtyczek. Jeśli strona działa, problem jest w drugiej połowie. Jeśli pada, w tej.
2. Podejrzaną połowę znów podziel na pół i powtarzaj.
3. Przy 30 wtyczkach po pięciu takich rundach zostaje jedna podejrzana wtyczka, najwyżej dwie.
4. Gdy znajdziesz parę, która razem powoduje błąd, zostaw włączoną ważniejszą i poszukaj zamiennika drugiej albo zgłoś konflikt obu autorom z treścią logu.

Gdy panel działa, a błąd dotyczy tylko części strony, istnieje też wtyczka Health Check & Troubleshooting od zespołu WordPress.org. Jej tryb rozwiązywania problemów wyłącza wtyczki i podmienia motyw tylko w Twojej sesji, a klienci widzą stronę bez zmian. Uwaga: w październiku 2026 r. wtyczka nie miała aktualizacji od 2024 r. i nie jest oznaczona jako testowana z WordPressem 7.x, więc w sklepie wypróbuj ją najpierw na kopii.

Wtyczki must-use i drop-iny

Jeśli błąd nie znika nawet po zmianie nazwy całego folderu plugins, sprawdź dwa miejsca, których zwykła lista wtyczek nie pokazuje.

Wtyczki „must-use” w wp-content/mu-plugins. Nie da się ich wyłączyć z panelu i nie wyłącza ich zmiana nazwy folderu plugins. Instalują je np. hostingi (cache, bezpieczeństwo) albo deweloperzy. Jeśli log wskazuje ścieżkę mu-plugins, przenieś na chwilę wskazany plik poza ten folder.

Drop-iny, czyli pliki advanced-cache.php, object-cache.php i db.php leżące bezpośrednio w wp-content. Tworzą je wtyczki cache i bezpieczeństwa, ale ładują się niezależnie od folderu plugins, a tryb odzyskiwania ich nie obejmuje. Typowe przypadki to advanced-cache.php po odinstalowanej lub przeniesionej wtyczce cache (w logu Failed opening required ze ścieżką do nieistniejącej wtyczki) oraz object-cache.php po wyłączeniu Redisa. Zmień nazwę wskazanego pliku, np. na object-cache.php.off. Przy advanced-cache.php ustaw też w wp-config.php define( 'WP_CACHE', false );, dopóki nie skonfigurujesz cache od nowa.

Sprawdź motyw i plik functions.php

Gdy ścieżka w logu prowadzi do wp-content/themes/…, winny jest motyw. Najczęściej to plik functions.php po wklejeniu fragmentu kodu z poradnika albo motyw potomny niezgodny z nowszą wersją motywu nadrzędnego.

• Panel działa: Wygląd → Motywy i włącz tymczasowo motyw domyślny (np. Twenty Twenty-Five). Strona będzie wyglądać inaczej, ale zacznie działać, a Ty zyskasz czas na poprawkę.
• Poziom 2: zmień nazwę folderu aktywnego motywu w wp-content/themes, a potem wejdź do panelu w Wygląd → Motywy. Dopiero wtedy WordPress wykryje brak motywu i przełączy się na motyw domyślny (Twenty Twenty-Five), a gdy go nie ma, na najnowszy zainstalowany motyw z serii Twenty. Motywu komercyjnego sam nie wybierze. Do tego czasu strona publiczna może być pusta, co jest normalne. Jeśli w wp-content/themes nie ma żadnego motywu Twenty, najpierw pobierz go ze strony motywu Twenty Twenty-Five na WordPress.org i wgraj przez FTP. Jeśli błąd jest w functions.php po Twojej zmianie, szybciej będzie usunąć ostatnio dodany fragment albo wgrać plik z kopii.
• Poziom 3: sprawdź listę motywów i włącz domyślny komendami poniżej.

wp theme list --skip-plugins --skip-themes
wp theme activate twentytwentyfive --skip-plugins --skip-themes

Sprawdź wersję PHP i limit pamięci

Wersja PHP

Jedną z częstszych przyczyn masowych błędów krytycznych jest zmiana wersji PHP po stronie hostingu. Strona działała latami, nikt niczego nie aktualizował, a jednego dnia pada. Przyczyną bywa stara wtyczka lub motyw, który nie działa na nowszym PHP (w tabeli wyżej: TypeError, Undefined constant, usunięte funkcje).

Stan na październik 2026:

• WordPress 7.0 i 7.1 wymagają co najmniej PHP 7.4 (wymóg podniesiono w wersji 7.0). Oficjalne minimum zalecane na wordpress.org to PHP 8.3, a zespół hostingowy WordPressa dla nowych instalacji rekomenduje już 8.4 lub 8.5.
• Według harmonogramu PHP wsparcie bezpieczeństwa dla PHP 8.2 kończy się 31 grudnia 2026 r., dla 8.3 — 31 grudnia 2027 r., a dla 8.4 — 31 grudnia 2028 r. Hostingi będą przenosić konta na nowsze wersje, więc spodziewaj się kolejnej fali błędów w stronach z nieaktualizowanymi wtyczkami.

Aktualną wersję PHP sprawdzisz w panelu WordPressa w Narzędzia → Stan witryny → Informacja → Serwer, w panelu hostingu (w cPanel np. „MultiPHP Manager” lub „Select PHP Version”, w DirectAdmin w ustawieniach PHP domeny) albo komendą wp --info. Jeśli błąd pojawił się zaraz po zmianie PHP, możesz tymczasowo wrócić do poprzedniej wersji, o ile hosting jeszcze ją oferuje. To jednak tylko odroczenie, bo przestarzałą wtyczkę i tak trzeba zaktualizować albo wymienić.

Cofając PHP, uważaj na skutek uboczny. Część aktualnych wtyczek wymaga nowszego PHP i po obniżeniu wersji zgłosi własny błąd krytyczny, np. Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.1.0". Cofaj PHP tylko o jedną wersję, tylko na czas naprawy, i nie schodź poniżej 7.4, którego wymaga WordPress 7.x.

Limit pamięci PHP w WordPressie

Komunikat Allowed memory size … exhausted oznacza, że skrypt zużył całą pamięć przydzieloną przez PHP. WordPress pozwala podnieść limit w wp-config.php. Wstaw tę linię nad komentarzem /* That's all, stop editing! */:

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

WordPress sam podniesie limit PHP (memory_limit) do tej wartości, o ile hosting pozwala zmieniać go z poziomu skryptu. Jeśli po dopisaniu stałej w logu nadal widzisz tę samą liczbę bajtów (np. 134217728), hosting zablokował zmianę albo ma twardy limit pamięci dla konta. Podnieś wtedy memory_limit w ustawieniach PHP w panelu hostingu albo poproś o to obsługę. W panelu /wp-admin/ WordPress używa osobnej stałej WP_MAX_MEMORY_LIMIT (domyślnie 256M), więc błąd pamięci tylko w panelu, np. przy imporcie, rozwiążesz nią. Gdy błąd wraca nawet przy 512 MB, problem leży w kodzie (np. pętla albo wtyczka wczytująca naraz wszystkie zamówienia), a nie w samym limicie.

Uszkodzone pliki WordPressa i sumy kontrolne

Rzadziej przyczyną są same pliki WordPressa: przerwana aktualizacja, błąd przy wgrywaniu przez FTP albo zmiany wprowadzone przez złośliwy kod. Na poziomie 3 sprawdzisz to w kilka sekund, porównując pliki z oryginałem z WordPress.org:

wp core verify-checksums --skip-plugins --skip-themes
wp plugin verify-checksums --all --skip-plugins --skip-themes

Wynik „Success: WordPress installation verifies against checksums.” oznacza, że pliki rdzenia są nienaruszone. Ostrzeżenia „File doesn’t verify against checksum” wskazują pliki zmienione względem oryginału. Sprawdzanie wtyczek obejmuje tylko te z katalogu WordPress.org. Dla płatnych WP-CLI nie ma wzorca.

Pliki rdzenia nadpiszesz czystą kopią tej samej wersji i tego samego języka bez ruszania treści, motywów i wtyczek. Najpierw sprawdź wersję i język pakietu (wiersze WordPress version i Package language):

wp core version --extra --skip-plugins --skip-themes

Potem pobierz rdzeń z tymi samymi parametrami (przykład dla polskiej wersji 7.1.3):

wp core download --version=7.1.3 --locale=pl_PL --skip-content --force

Bez --locale WP-CLI wgra pakiet angielski i zmieni zapis języka instalacji, a późniejsza weryfikacja sum kontrolnych porówna pliki z innym pakietem. Na poziomie 2 odpowiednikiem jest pobranie tej samej wersji WordPressa z WordPress.org i wgranie przez FTP folderów wp-admin i wp-includes oraz plików z katalogu głównego. Nie wgrywaj folderu wp-content i nie nadpisuj wp-config.php.

Błąd krytyczny po aktualizacji WordPressa

Najwięcej zgłoszeń z błędem krytycznym przychodzi zaraz po aktualizacjach: wtyczki, motywu, WooCommerce albo PHP na serwerze. Dobrym przykładem z tego roku jest incydent z WordPressem 6.9.2.

10 marca 2026 r. ukazało się wydanie bezpieczeństwa 6.9.2. Wkrótce po nim część właścicieli zgłosiła, że po aktualizacji do WordPressa 6.9.2 strona publiczna pokazuje biały ekran zamiast treści. Jak napisał zespół WordPressa w komunikacie o wersji 6.9.3, przyczyną był niestandardowy sposób, w jaki niektóre motywy wczytywały pliki szablonów. Poprawka 6.9.3 wyszła tego samego dnia, a 11 marca wersja 6.9.4 uzupełniła poprawki bezpieczeństwa, które nie weszły w całości do poprzednich wydań.

Objawem był biały ekran, bez komunikatu o błędzie krytycznym. Diagnoza jest jednak ta sama: log błędów i sprawdzenie motywu.

Wnioski dla właściciela strony:

• Problem może wywołać nawet drobne wydanie bezpieczeństwa, instalowane przez WordPress automatycznie. Wyłączanie automatycznych aktualizacji bezpieczeństwa to jednak gorszy pomysł niż szybkie wykrycie awarii.
• O awarii najlepiej wiedzieć przed klientami. Monitoring dostępności sprawdzający kod odpowiedzi co minutę wykrywa błąd krytyczny (HTTP 500) od razu. Biały ekran bywa jednak zwracany z kodem 200, więc dobry monitoring sprawdza też, czy na stronie jest konkretny tekst, np. nazwa firmy w stopce.
• Automatyczne aktualizacje wtyczek mają zabezpieczenie, ale częściowe. Od wersji 6.6 WordPress po automatycznej aktualizacji wtyczki sprawdza stronę główną i przy błędzie krytycznym przywraca poprzednią wersję wtyczki. Nie wykryje jednak błędu, który występuje tylko na podstronie, np. w koszyku, ani nie chroni przy aktualizacji uruchomionej ręcznie.

Jeśli błąd pojawił się po aktualizacji wtyczki, najszybciej pomaga wyłączenie jej i wgranie poprzedniej wersji (komenda WP-CLI wyżej). Jeśli po aktualizacji PHP, sprawdź, którą wtyczkę wskazuje log, i zaktualizuj ją lub wymień.

Kiedy błąd krytyczny jest skutkiem włamania

Zainfekowane strony często się wywracają, bo złośliwy kod jest pisany niechlujnie albo koliduje z aktualizacjami. Podejrzewaj włamanie, gdy:

• log wskazuje pliki, których nie instalowałeś: losowe nazwy w wp-content/plugins, pliki .php w wp-content/uploads, nieznane pliki w katalogu głównym,
• w komunikacie pojawia się eval()'d code, czyli kod uruchamiany z ciągu znaków, często zaciemniony (base64_decode, gzinflate). Kilka legalnych wtyczek też tak działa, więc to tylko poszlaka, ale w połączeniu z nieznanym plikiem to mocny sygnał,
• błąd wystąpił, choć nikt niczego nie aktualizował ani nie zmieniał,
• hosting przysłał powiadomienie o złośliwych plikach albo przeniósł część plików do kwarantanny (w logu: Failed opening required),
• wp core verify-checksums pokazuje zmienione pliki rdzenia.

Wtedy samo wyłączenie wtyczki nie wystarczy, bo strona zostaje zainfekowana i może wrócić do złego stanu po kilku dniach. Opisaliśmy to w poradniku co zrobić, gdy strona WordPress została zhakowana: jak zabezpieczyć dowody, oczyścić pliki i bazę oraz kiedy zgłosić incydent.

Kiedy przestać i zlecić naprawę

Większość błędów krytycznych sprowadza się do jednej wtyczki i naprawisz je sam w kwadrans do godziny. Są jednak sytuacje, w których dalsze samodzielne próby kosztują więcej niż zlecenie. Przestań, gdy:

• nie masz dostępu do FTP ani panelu hostingu, a link z maila nie działa albo maila nie ma,
• sklep nie przyjmuje zamówień i każda godzina to utracona sprzedaż,
• błąd wraca po wyłączeniu wtyczki albo po kilku godzinach od naprawy,
• log wskazuje pliki WordPressa, nieznane pliki albo masz którykolwiek z sygnałów włamania,
• naprawa wymaga zmian w kodzie płatnej wtyczki lub motywu pod nową wersję PHP,
• nie masz kopii zapasowej, a następny krok to nadpisywanie plików,
• minęła ponad godzina, a nadal nie wiesz, co jest przyczyną.

Gdy zlecasz naprawę WordPress, przyspieszysz ją, przygotowując:

1. adres strony i dokładną treść komunikatu (zrzut ekranu wystarczy),
2. informację, co działo się przed awarią: aktualizacja, nowa wtyczka, zmiana na hostingu, wklejony kod,
3. fragment debug.log albo mail „Twoja witryna ma problemy techniczne”, jeśli je masz,
4. dostępy: panel hostingu lub FTP oraz konto administratora WordPress. Najlepiej utwórz osobne, tymczasowe konta, które usuniesz po naprawie, zamiast przekazywać własne hasła.

U nas naprawa awarii kosztuje od 490 zł netto. Cenę podajemy przed rozpoczęciem pracy, odzywamy się w ciągu godziny w godzinach dyżuru, a na naprawę dajemy 30 dni gwarancji. Nie musimy być autorami Twojej strony. Zgłoś awarię przez formularz, a my najpierw ustalimy przyczynę, a potem powiemy, ile zajmie naprawa.

Po naprawie: lista kontrolna

Strona działa. Zanim zamkniesz temat, przejdź przez tę listę. Pominięcie pierwszego punktu to najczęstszy błąd, jaki widzimy po samodzielnych naprawach.

• Wyłącz diagnostykę. Ustaw WP_DEBUG na false albo usuń dodane linie i skasuj debug.log albo plik wskazany w WP_DEBUG_LOG (np. wp-debug.log poza public_html). Domyślny plik jest dostępny z przeglądarki i zdradza strukturę serwera. W WP-CLI: wp config set WP_DEBUG false --raw, wp config delete WP_DEBUG_LOG, wp config delete WP_DEBUG_DISPLAY.
• Wyjdź z trybu awaryjnego, jeśli z niego korzystałeś.
• Wyczyść cache wtyczki (np. LiteSpeed Cache, WP Rocket), serwera i CDN (np. Cloudflare), a stronę sprawdź w oknie prywatnym przeglądarki.
• Przywróć nazwy folderów zmienionych w trakcie (plugins, motyw) albo usuń te, których już nie potrzebujesz.
• Usuń tymczasowe konta FTP i administratora utworzone na potrzeby naprawy.
• Sprawdź najważniejsze funkcje: formularz kontaktowy, koszyk i płatność w sklepie, logowanie klientów, wysyłkę maili.
• Sklep: uzgodnij płatności z czasu awarii. Porównaj wpłaty w panelu bramki (Przelewy24, PayU, Stripe) z zamówieniami w WooCommerce. Zamówienia opłacone, a wiszące jako „Oczekujące na płatność”, oznacz ręcznie i wyślij klientom potwierdzenie. Jeśli bramka na to pozwala, ponów z jej panelu powiadomienia, które nie dotarły.
• Zaktualizuj lub wymień winną wtyczkę, zamiast zostawiać ją wyłączoną bez planu.
• Zrób świeżą kopię zapasową stanu, który działa.
• Zaktualizuj adres administratora albo dodaj RECOVERY_MODE_EMAIL, żeby następny mail trafił do właściwej osoby. Zmiana w Ustawienia → Ogólne wymaga kliknięcia linku wysłanego na nowy adres. Jeśli serwer nie wysyła poczty, użyj wp option update admin_email nowy@adres.pl albo stałej RECOVERY_MODE_EMAIL.
• Zapisz, co się stało: data, przyczyna, co zrobiłeś. Przy następnej awarii zaoszczędzisz czas.

Jak sprawić, żeby błąd się nie powtórzył

Błąd krytyczny prawie zawsze poprzedza zmiana: aktualizacja, nowa wtyczka albo zmiana PHP przez hosting. Ryzyko ograniczają cztery nawyki:

• Aktualizacje na kopii strony, a na produkcji po jednej wtyczce naraz, z kontrolą strony po każdej.
• Kopie zapasowe poza hostingiem, z regularnie sprawdzanym przywracaniem. Kopia, której nikt nie próbował przywrócić, potrafi okazać się niekompletna akurat wtedy, gdy jest potrzebna.
• Monitoring dostępności strony i kluczowych podstron, z powiadomieniem na telefon.
• Porządek we wtyczkach: mniej wtyczek, bez porzuconych przez autorów i bez nieaktualizowanych od lat.

Jeśli nie masz na to czasu, możesz to oddać. W ramach stałej opieki technicznej aktualizujemy strony na kopii, monitorujemy je co minutę i reagujemy na błąd, zanim zgłosi go klient. Jeśli zastanawiasz się, czy to się opłaca, przeczytaj, ile kosztuje utrzymanie strony internetowej, i porównaj to z kosztem jednej awarii. Więcej poradników o awariach znajdziesz w dziale Awarie i błędy.

Dokumentacja, na której oparliśmy techniczne szczegóły: debugowanie w WordPressie, konfiguracja wp-config.php, WP-CLI: weryfikacja sum kontrolnych, wymagania PHP dla WordPressa 7.0.