„Błąd krytyczny” w WordPressie to zwykle fatalny błąd PHP, który zatrzymuje działanie strony — najczęściej z powodu problemów z wtyczką, motywem, wersją PHP, plikami lub bazą danych.

Aby szybko znaleźć przyczynę i przywrócić stronę, włącz tryb debugowania, przeanalizuj plik debug.log, a następnie krok po kroku wykluczaj wtyczki, motyw, plik .htaccess, niezgodną wersję PHP, uszkodzone pliki i błędy w bazie danych.

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

Od kilku wersji WordPress zamiast „białej strony śmierci” wyświetla komunikat w stylu: „W witrynie wystąpił błąd krytyczny” lub „There has been a critical error on this website”. To sygnał, że wystąpił fatal error — błąd, którego PHP nie potrafi obsłużyć i przerywa wykonanie skryptu.

Najczęstsze przyczyny tego komunikatu to:

  • Błędna lub zaktualizowana wtyczka – powoduje konflikt z inną wtyczką, motywem lub wersją PHP;
  • Motyw (szablon) – zawiera błędny kod lub jest niekompatybilny z aktualnym WordPressem;
  • Niekompatybilna wersja PHP – zbyt stara lub zbyt nowa względem używanych wtyczek/motywu;
  • Zbyt niski limit pamięci PHP – brak zasobów wywołuje krytyczne błędy podczas ładowania strony;
  • Uszkodzone pliki WordPressa – np. po przerwanej aktualizacji lub błędnym nadpisaniu plików;
  • Problemy z bazą danych – uszkodzone tabele, nieprawidłowe dane logowania lub błędna struktura;
  • Plik .htaccess – zmodyfikowany lub uszkodzony, powodujący błędy konfiguracji serwera;
  • Złośliwe oprogramowanie (malware) – nieautoryzowana ingerencja w pliki strony.

Zanim zaczniesz cokolwiek zmieniać, wykonaj kopię zapasową plików i bazy danych. Nawet jeśli strona nie działa, backup pozwoli cofnąć ewentualne nieudane naprawy.

Krok 1 – włącz tryb debugowania i zbierz informacje

Najważniejsze na starcie to poznać dokładny komunikat błędu. Umożliwia to tryb debugowania i log błędów.

Modyfikacja pliku wp-config.php

Wykonaj poniższe czynności przez FTP lub menedżera plików w panelu hostingu:

  1. Połącz się z serwerem i wejdź do katalogu głównego WordPressa, gdzie znajduje się plik wp-config.php.
  2. Otwórz wp-config.php do edycji.
  3. Znajdź linijkę (jeśli istnieje):

define('WP_DEBUG', false);

  1. Zmień ją (lub dodaj, jeśli jej nie ma) na:

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

Dzięki temu WordPress zapisze błędy do pliku logów, ale nie pokaże ich odwiedzającym.

  1. Zapisz plik i odśwież stronę, aby ponownie wywołać błąd i zapisać go w logu.

Odczyt pliku debug.log

Po włączeniu debugowania wykonaj te kroki:

  • przejdź do katalogu wp-content na serwerze,
  • znajdź plik debug.log (zazwyczaj WordPress tworzy go sam; jeśli nie ma — utwórz go ręcznie),
  • otwórz debug.log i odszukaj ostatnie wpisy — wskazują plik, funkcję lub wtyczkę powodującą błąd.

W logu zazwyczaj zobaczysz:

  • ścieżkę do pliku, w którym wystąpił błąd (np. wp-content/plugins/nazwa-wtyczki/...),
  • numer linii,
  • rodzaj błędu (np. Fatal error: Uncaught Error, Call to undefined function, Allowed memory size exhausted).

Na tej podstawie z dużym prawdopodobieństwem wskażesz winowajcę — wtyczkę, motyw, własny fragment kodu lub ustawienie PHP. Kolejny krok to tymczasowe wyłączenie problematycznego elementu i dalsza analiza.

Krok 2 – wyłączenie wtyczek (najczęstsza przyczyna)

Wtyczki najczęściej powodują błędy krytyczne — zwłaszcza po aktualizacjach lub instalacji nowych dodatków.

Wyłączenie wszystkich wtyczek przez FTP

Gdy nie możesz zalogować się do panelu WordPress, zrób tak:

  1. Połącz się z serwerem przez FTP / SFTP lub menedżer plików hostingu.
  2. Przejdź do katalogu:

/wp-content/plugins

  1. Aby zbiorczo wyłączyć wszystkie wtyczki, zmień nazwę całego folderu plugins, np. na:

plugins-dezaktywowane

WordPress przy ładowaniu strony nie znajdzie katalogu i potraktuje wszystkie wtyczki jako wyłączone.

  1. Odśwież stronę.

Jeśli błąd krytyczny zniknął, przyczyną była któraś z wtyczek.

Jeśli komunikat nadal się pojawia, problem leży gdzie indziej (motyw, baza, pliki, PHP).

Znalezienie konkretnej wtyczki powodującej błąd

Jeśli po wyłączeniu wszystkich wtyczek strona działa, przeprowadź selekcję:

  1. Przywróć nazwę folderu plugins do oryginalnej.
  2. Wyłączaj wtyczki stopniowo, zmieniając nazwy folderów poszczególnych wtyczek:
  • wejdź do wp-content/plugins/,
  • wybierz podejrzaną wtyczkę (np. ostatnio instalowaną lub aktualizowaną),
  • zmień nazwę jej folderu, np. z elementor na elementor-dezaktywowany.
  1. Po każdej zmianie nazwy odśwież stronę i sprawdź, czy błąd zniknął.
  2. Gdy po dezaktywacji konkretnej wtyczki strona działa poprawnie — znalazłeś winowajcę.

Co dalej z problematyczną wtyczką:

  • Aktualizacja – sprawdź, czy dostępna jest nowsza wersja naprawiająca problem;
  • Kompatybilność – zweryfikuj zgodność z Twoją wersją WordPressa i PHP (zwłaszcza po ich aktualizacji);
  • Zgłoszenie błędu autorowi – opisz problem i dołącz fragmenty z debug.log;
  • Changelog – przeczytaj dziennik zmian pod kątem znanych konfliktów lub poprawek;
  • Alternatywa – tymczasowo użyj wtyczki o podobnej funkcjonalności;
  • Wtyczka autorska – skorzystaj z pomocy programisty w dostosowaniu kodu do aktualnego WordPressa/PHP.

Krok 3 – sprawdzenie motywu (szablonu)

Jeśli log błędów wskazuje katalog wp-content/themes/, albo wyłączenie wszystkich wtyczek nie pomaga, następnym podejrzanym jest motyw.

Tymczasowe przełączenie na motyw domyślny

Gdy nie możesz wejść do panelu administratora:

  1. Połącz się z serwerem przez FTP / menedżer plików.
  2. Wejdź do katalogu:

/wp-content/themes

  1. Odnajdź folder aktualnie aktywnego motywu (nazwę poznasz z wcześniejszych ustawień lub logów błędów).
  2. Zmień nazwę tego folderu, np. dodając znak _ na początku:

_nazwa-motywu

Po zmianie nazwy WordPress nie odnajdzie motywu i spróbuje automatycznie przełączyć się na domyślny motyw (np. z serii Twenty Twenty‑xx), o ile jest zainstalowany.

Jeśli strona działa po przełączeniu — problem wynikał z motywu (konflikt, niekompatybilność lub błąd w plikach).

Naprawa lub wymiana motywu

Wykonaj następujące działania:

  • Wgraj świeżą kopię motywu domyślnego z repozytorium WordPress, rozpakuj lokalnie i nadpisz pliki na serwerze;
  • Aktualizacja motywu premium – sprawdź, czy dostępna jest wersja kompatybilna z bieżącym WordPressem i PHP;
  • Informacje od autora – zweryfikuj, czy nie zgłoszono znanego błędu w najnowszej wersji;
  • Motyw autorski – skontaktuj się z twórcą/programistą, by poprawić linie kodu wskazane w logach.

Krok 4 – plik .htaccess i ustawienia permalinków

Zmodyfikowany lub uszkodzony plik .htaccess potrafi wywołać liczne błędy — w tym te skutkujące błędem krytycznym.

Przywrócenie domyślnego .htaccess

  1. Połącz się przez FTP / menedżer plików.
  2. W katalogu głównym WordPressa znajdź plik:

.htaccess

  1. Dla bezpieczeństwa zrób kopię, np. zmieniając nazwę na .htaccess-backup.
  2. Utwórz nowy plik .htaccess z domyślną zawartością WordPressa dla standardowych permalinków, np.:

# Domyślny .htaccess WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

  1. Zapisz plik i odśwież stronę. Jeśli błąd ustąpi, problem wynikał z poprzedniej konfiguracji .htaccess.

Po odzyskaniu dostępu do panelu zapisz ponownie Bezpośrednie odnośniki (Permalinks), aby WordPress sam wygenerował poprawny .htaccess.

Krok 5 – sprawdzenie wersji PHP i limitu pamięci

Nieprawidłowa wersja PHP lub zbyt niski limit pamięci często powodują krytyczne błędy — zwłaszcza przy rozbudowanych motywach, page builderach i WooCommerce.

Wersja PHP na serwerze

W panelu hostingu (np. dhosting) zwykle możesz sprawdzić aktualną wersję PHP i zmienić ją na wyższą lub niższą — zgodnie z wymaganiami WordPressa oraz wtyczek.

Zweryfikuj zgodność: używana wersja PHP powinna być wspierana przez Twój WordPress i wtyczki; jeśli po zmianie wersji błąd krytyczny znika, przyczyną była niekompatybilność.

Zwiększenie limitu pamięci WordPressa

Komunikaty typu Allowed memory size exhausted oznaczają, że brakuje pamięci dla skryptów PHP.

Możesz zwiększyć limit w wp-config.php:

  1. Otwórz wp-config.php.
  2. Dodaj (lub zmień) linijkę:

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

WordPress spróbuje użyć większej ilości pamięci (np. 256 MB). Upewnij się, że limit pamięci po stronie serwera pozwala na taki rozmiar — w przeciwnym razie wpis w wp-config.php nie zadziała.

Krok 6 – naprawa plików WordPressa (rdzenia)

Gdy logi wskazują na pliki w rdzeniu WordPressa (wp-admin, wp-includes) lub podejrzewasz uszkodzenie plików po nieudanej aktualizacji, rozważ ponowne wgranie „czystych” plików WordPressa.

Bezpieczne przeinstalowanie rdzenia WordPressa

  1. Pobierz najnowszą wersję WordPressa z oficjalnego źródła i rozpakuj ją lokalnie.
  2. Za pomocą FTP prześlij na serwer wszystkie pliki z paczki, z wyłączeniem katalogu wp-content oraz pliku wp-config.php (aby nie nadpisywać motywów, wtyczek, uploadów i konfiguracji).
  3. Zgódź się na nadpisanie istniejących plików rdzenia.
  4. Po zakończeniu wgrywania odśwież stronę — jeśli błąd był spowodowany uszkodzonym plikiem rdzenia, powinien zniknąć.

To bezpieczna metoda: nie ingeruje w treści i ustawienia, a naprawia jedynie „silnik” WordPressa.

Krok 7 – naprawa i diagnostyka bazy danych

WordPress intensywnie korzysta z bazy — jeśli jest uszkodzona lub dane uwierzytelniające są błędne, mogą pojawiać się błędy krytyczne.

Automatyczna naprawa bazy z poziomu WordPressa

WordPress ma wbudowane narzędzie do naprawy bazy danych, które uruchomisz przez wp-config.php:

  1. Otwórz plik wp-config.php.
  2. Dodaj linijkę:

define('WP_ALLOW_REPAIR', true);

  1. Zapisz plik.
  2. W przeglądarce wejdź pod adres:

/wp-admin/maint/repair.php

(podstaw swoją domenę przed ścieżką; logowanie nie jest wymagane).

  1. Uruchom naprawę bazy (opcjonalnie także optymalizację tabel).
  2. Po zakończeniu usuń dodaną linijkę WP_ALLOW_REPAIR z wp-config.php — pozostawienie jej publicznie udostępnia narzędzie naprawy.

Sprawdzenie integralności bazy w phpMyAdmin

Dodatkowo wykonaj te działania:

  • zaloguj się do phpMyAdmin z panelu hostingu,
  • sprawdź tabele (opcje w stylu „Sprawdź”, „Napraw”),
  • zidentyfikuj i napraw ewentualne błędy struktury tabel.

Narzędzia phpMyAdmin potrafią usunąć drobne błędy, które prowadzą do krytycznych problemów podczas działania strony.

Weryfikacja danych uwierzytelniających bazy

W niektórych konfiguracjach ustawienia połączenia z bazą możesz mieć osobno — upewnij się, że są poprawne:

  • przejdź do sekcji ustawień bazy (w panelu lub konfiguracji),
  • sprawdź poprawność nazwy bazy danych, użytkownika, hasła i hosta,
  • popraw ewentualne błędy i zapisz zmiany.

Błędne dane dostępowe uniemożliwiają połączenie z bazą, co może skutkować błędami krytycznymi lub komunikatami o błędzie połączenia.

Krok 8 – aktualizacje, bezpieczeństwo i skan w poszukiwaniu malware

Po przywróceniu działania strony sprawdź, czy przyczyną nie były nieaktualne komponenty lub złośliwy kod.

Aktualizacja WordPressa, wtyczek i motywów

Nieaktualne, niewspierane wersje to częste źródło problemów i luk bezpieczeństwa. Warto:

  • Rdzeń WordPressa – zaktualizować do najnowszej stabilnej wersji;
  • Wtyczki i motywy – zaktualizować wszystkie po sprawdzeniu kompatybilności;
  • Usuwanie nieużywanych – pozbywać się dodatków, których nie używasz, by zmniejszyć ryzyko konfliktów i ataków.

Skanowanie strony pod kątem złośliwego oprogramowania

Przy nawracających błędach lub podejrzanych wpisach w logach wykonaj skan w poszukiwaniu malware. Możesz użyć wtyczek bezpieczeństwa (skanerów plików i sygnatur) oraz narzędzi hostingodawcy (często oferują skan antywirusowy plików strony).

Jeśli pliki okażą się zainfekowane, wykonaj:

  • usunięcie nieautoryzowanych plików,
  • przywrócenie strony z czystej kopii zapasowej,
  • zabezpieczenie dostępu (zmiana haseł, kluczy, włączenie 2FA).

Jak postępować w różnych sytuacjach – dwa scenariusze

W praktyce błędy krytyczne występują w dwóch wariantach: brak dostępu zarówno do frontu, jak i panelu; front nie działa, ale panel admina działa (lub odwrotnie).

Gdy nie masz dostępu do panelu admina

Wszystkie działania wykonujesz z poziomu FTP lub panelu hostingu:

  • włączasz debugowanie przez edycję wp-config.php,
  • czytasz debug.log w wp-content,
  • wyłączasz wtyczki, zmieniając nazwę folderu plugins lub pojedynczych wtyczek,
  • wyłączasz motyw, zmieniając nazwę jego folderu w wp-content/themes,
  • naprawiasz .htaccess, wersję PHP, pamięć i pliki WordPressa,
  • uruchamiasz naprawę bazy przez WP_ALLOW_REPAIR.

Gdy masz dostęp do panelu admina

Jeśli panel działa, a front pokazuje błąd krytyczny, będzie łatwiej:

  • możesz wyłączać i włączać wtyczki w sekcji „Wtyczki”, by znaleźć problematyczną,
  • możesz zmienić motyw na domyślny w „Wygląd”,
  • możesz przeinstalować WordPress w „Aktualizacje”.

Mimo to włącz WP_DEBUG i WP_DEBUG_LOG, aby mieć dokładny zapis błędów w debug.log.

Kiedy skontaktować się z hostingiem lub specjalistą?

Jeśli po wykonaniu powyższych kroków błąd krytyczny nadal się pojawia lub logi wskazują problemy z serwerem, których nie możesz samodzielnie rozwiązać, skontaktuj się z dostawcą hostingu albo zewnętrznym specjalistą od WordPressa.

W takim przypadku warto:

  • przesłać hostingodawcy fragmenty z debug.log i dziennika błędów serwera,
  • poprosić o weryfikację limitów zasobów, ustawień PHP i logów serwera (np. error_log),
  • w razie potrzeby poprosić o przywrócenie kopii zapasowej z określonej daty.

Jeśli problem wynika z niestandardowego kodu (autorska wtyczka lub motyw), konieczna może być pomoc programisty, który poprawi wskazane w logach fragmenty.

Jak zapobiegać błędom krytycznym w przyszłości?

Błędom krytycznym można w dużej mierze zapobiegać, stosując kilka sprawdzonych praktyk:

  • Regularne kopie zapasowe – wykonuj backup plików i bazy przed większymi aktualizacjami oraz instalacją nowych dodatków;
  • Aktualizowanie WordPressa, wtyczek i motywów – utrzymuj najnowsze stabilne wersje i śledź kompatybilność z PHP;
  • Unikanie nadmiaru wtyczek – im więcej dodatków, tym większe ryzyko konfliktów i błędów;
  • Testy na środowisku staging – sprawdzaj zmiany przed wdrożeniem na stronę produkcyjną;
  • Monitorowanie logów błędów – okresowo kontroluj debug.log i logi serwera, by wychwycić problemy zawczasu;
  • Bezpieczeństwo – silne hasła, aktualne wtyczki bezpieczeństwa, ograniczenia dostępu do panelu i 2FA.

Stosowanie tych zasad znacząco zmniejsza ryzyko wystąpienia błędu krytycznego i przyspiesza diagnostykę w razie problemów.