Znam ten moment. Wchodzisz na swoją stronę, a zamiast niej widzisz biały ekran i komunikat "Wystąpił błąd krytyczny na twojej witrynie". Albo zaglądasz do Stanu witryny i WordPress straszy Cię czerwonym alertem. Serce staje, a w głowie jedna myśl: "zepsułam stronę".
Spokojnie. Przez ponad 10 lat pracy z WordPressem naprawiłam setki takich błędów i nauczyłam tego tysiące kursantek. W tym artykule pokażę Ci dokładnie, co zrobić krok po kroku. Bez paniki i bez dzwonienia do drogiej agencji.
Zacznę od najważniejszego rozróżnienia, bo to ono najczęściej wprowadza zamieszanie.
"Błąd krytyczny" ma dwa różne znaczenia
WordPress używa słów "błąd krytyczny" w dwóch zupełnie różnych sytuacjach i to źródło ogromnej konfuzji.
Sytuacja 1: prawdziwy błąd krytyczny. Strona nie działa. Zamiast niej wyświetla się komunikat "Wystąpił błąd krytyczny na twojej witrynie. Sprawdź skrzynkę odbiorczą administratora witryny, aby uzyskać instrukcje". To awaria: coś w kodzie (najczęściej wtyczka lub motyw) wywołało błąd PHP, który zatrzymał ładowanie strony.
Sytuacja 2: alert w Stanie witryny. Strona działa normalnie, ale w panelu, w zakładce Narzędzia → Stan witryny, widzisz komunikat oznaczony jako "błąd krytyczny", np. "Pamięć podręczna strony nie jest wykrywana i czas odpowiedzi serwera jest powolny". To nie awaria, tylko zalecenie. WordPress podpowiada, co warto poprawić, żeby strona była szybsza i bezpieczniejsza.
Pierwsza sytuacja wymaga natychmiastowego działania. Druga to lista zadań na spokojne popołudnie. Omówię obie.
Prawdziwy błąd krytyczny: strona nie działa
Krok 1: sprawdź skrzynkę mailową
WordPress w momencie awarii wysyła wiadomość na adres administratora z tematem "Twoja witryna ma problemy techniczne". Ten mail to złoto z dwóch powodów. Po pierwsze, zawiera link do trybu ratunkowego, który pozwala zalogować się do panelu mimo awarii. Po drugie, wskazuje winowajcę: nazwę wtyczki lub motywu, który wywołał błąd, oraz konkretny komunikat.
Sprawdź też folder spam. Jeśli maila nie ma, upewnij się w panelu hostingu, jaki adres e-mail jest przypisany do konta administratora.
Krok 2: wejdź w tryb ratunkowy i wyłącz winowajcę
Kliknij link z maila. Zalogujesz się do panelu w trybie ratunkowym, w którym WordPress tymczasowo wycisza problematyczny element. Przejdź do zakładki Wtyczki, znajdź tę wskazaną w mailu i ją wyłącz. W większości przypadków strona natychmiast wraca do życia.
Co dalej z wyłączoną wtyczką? Sprawdź, czy jest dostępna jej aktualizacja. Jeśli tak, zaktualizuj i włącz ponownie. Jeśli błąd wraca, poszukaj zamiennika. Żadna wtyczka nie jest warta niedziałającej strony.
Krok 3: nie masz maila? Wyłącz wtyczki przez FTP lub menedżer plików
Jeśli nie możesz dostać się do panelu, wejdź na serwer przez menedżer plików w panelu hostingu (albo przez FTP). Przejdź do katalogu wp-content i zmień nazwę folderu "plugins" na "plugins-off". To wyłącza wszystkie wtyczki naraz. Jeśli strona wróciła, wiesz już, że winna jest któraś z wtyczek.
Teraz przywróć nazwę folderu na "plugins" i wyłączaj wtyczki pojedynczo z poziomu panelu (po awarii WordPress zostawi je wyłączone). Włączaj je po jednej i po każdej sprawdzaj stronę. Ta, po której błąd wraca, to winowajca.
Ważna wskazówka z mojego forum: jeśli robisz taki test na działającej stronie, włącz najpierw tryb konserwacji albo testuj późnym wieczorem, kiedy ruch jest minimalny. Wyłączenie wszystkich wtyczek na oczach klientek nie wygląda dobrze.
Krok 4: sprawdź motyw
Jeśli wtyczki są niewinne, sprawdź motyw. I tu ciekawostka, o którą często pytają moje kursantki: po co WordPressowi motyw domyślny (np. Twenty Twenty-Four), skoro używasz Astry albo innego motywu? Właśnie po to. Gdy Twój motyw się wysypie, WordPress automatycznie przełączy stronę na motyw domyślny zamiast pokazać błąd krytyczny. Dlatego zalecam trzymać jeden motyw domyślny zainstalowany (nie włączony, po prostu zainstalowany). To Twoja poduszka bezpieczeństwa, która kosztuje kilka megabajtów.
Krok 5: błąd przy aktualizacji WordPressa
Osobny przypadek to błąd podczas aktualizacji, np. "Poprawność pliku nie mogła zostać zweryfikowana z powodu braku sygnatury" albo "Nie można było skopiować pliku. Instalacja nie powiodła się". To prawie nigdy nie jest Twoja wina. Najczęstsze przyczyny to brak miejsca na serwerze, uprawnienia do plików albo chwilowy problem po stronie hostingu.
Co robić: najpierw sprawdź w panelu hostingu, ile masz wolnego miejsca. Jeśli jest go mało, wyczyść stare kopie zapasowe i nieużywane pliki. Jeśli miejsce jest, napisz do supportu hostingu i wklej dokładną treść komunikatu. W przypadku moich kursantek na polskich hostingach support rozwiązuje takie zgłoszenia zwykle w kilka godzin.
I moja żelazna zasada, którą powtarzam od lat: nie aktualizuję WordPressa w dniu premiery nowej wersji. Czekam kilka dni, aż pierwsze poprawki załatają ewentualne wpadki. Przed każdą większą aktualizacją robię kopię zapasową.
Alert w Stanie witryny: "pamięć podręczna strony nie jest wykrywana"
To najczęstszy "błąd krytyczny", z jakim zgłaszały się kursantki na moim forum. Wygląda groźnie, a znaczy tyle: Twoja strona nie używa wtyczki cache, przez co ładuje się wolniej, niż mogłaby.
Czym jest pamięć podręczna? Wyobraź sobie, że przy każdej wizycie na Twojej stronie serwer buduje ją od zera: pobiera dane z bazy, składa szablon, generuje kod. Wtyczka cache robi zdjęcie gotowej strony i serwuje je kolejnym odwiedzającym. Serwer nie pracuje za każdym razem od nowa, więc strona ładuje się znacznie szybciej.
Jak naprawić ten alert:
- Zainstaluj wtyczkę cache. Sprawdzone opcje to WP Super Cache (prosta, bezpłatna), LiteSpeed Cache (jeśli Twój hosting działa na serwerze LiteSpeed) albo WP Rocket (płatna, najbardziej kompleksowa).
- Włącz cache w ustawieniach wtyczki. W WP Super Cache to dosłownie jedno kliknięcie: Caching On.
- Odśwież Stan witryny i sprawdź, czy alert zniknął.
A co, jeśli masz wtyczkę cache, a alert dalej się wyświetla? To też realny przypadek z forum. WordPress wykrywa cache po nagłówkach odpowiedzi serwera, a niektóre konfiguracje ich nie wysyłają. Sprawdź w ustawieniach wtyczki, czy cache jest faktycznie włączony (a nie tylko wtyczka aktywna). Jeśli wyłączasz cache na czas edycji strony, pamiętaj o ponownym włączeniu. Jeśli wszystko wygląda dobrze, a komunikat nie znika, dopytaj support hostingu, czy serwer nie nadpisuje nagłówków.
Drugi element tego alertu to czas odpowiedzi serwera. WordPress chce, żeby był poniżej 600 milisekund. Jeśli Twój wynik to np. 750 ms, wtyczka cache zwykle załatwia sprawę. Jeśli nie, to sygnał, że warto rozważyć wyższy pakiet hostingu albo szybszy hosting.
Więcej o wyborze i konfiguracji wtyczki cache przeczytasz w moim osobnym artykule o pamięci podręcznej w WordPressie.
Inne częste komunikaty ze Stanu witryny
"Powinieneś używać trwałej pamięci podręcznej obiektów". To NIE to samo co cache strony i żadna zwykła wtyczka cache tego nie załatwi. Trwała pamięć podręczna obiektów (najczęściej Redis) przyspiesza zapytania do bazy danych i jest włączana po stronie hostingu. Uwaga: nie każdy pakiet hostingowy ją oferuje, często dostępna jest dopiero od średniej półki cenowej. Sprawdź w panelu lub zapytaj support, czy Twój pakiet wspiera Redis. Jeśli nie, ten komunikat możesz spokojnie zignorować. Strona będzie działać dobrze bez niego, to usprawnienie dla wymagających.
"Witryna nie ma żadnego domyślnego motywu". Jak pisałam wyżej: zainstaluj (bez włączania) jeden motyw domyślny, np. najnowszy Twenty. Komunikat zniknie, a Ty zyskujesz zabezpieczenie na wypadek awarii głównego motywu.
"Zaplanowane wydarzenie jest opóźnione" (np. action_scheduler_run_queue). WordPress wykonuje zadania w tle (publikacje zaplanowane, wysyłki, synchronizacje) przy okazji ruchu na stronie. Na stronach z małym ruchem zadania potrafią się opóźniać. Wejdź w Narzędzia → Zaplanowane akcje i sprawdź, czy są zadania oczekujące. Możesz uruchomić je ręcznie. Jeśli komunikat wraca regularnie, przyczyną bywa konfliktowa wtyczka albo zbyt niski limit czasu wykonywania skryptów PHP na hostingu.
Błędy krytyczne przy sklepie i platformie kursowej (WooCommerce, LearnPress). Konflikt wtyczek sklepowych i kursowych to częsty scenariusz. Diagnoza jest taka sama jak w kroku 3: wyłączasz, włączasz pojedynczo, obserwujesz. Dodatkowo po każdej większej aktualizacji WooCommerce sprawdź, czy proces zakupu i dostęp do produktów działają. Zrób testowe zamówienie, zanim zrobi je klientka.
Jak zdiagnozować błąd krytyczny z pomocą AI
Tu dochodzimy do narzędzia, które zmieniło rozwiązywanie takich problemów: czat AI (ChatGPT, Claude, Gemini). Dobrze poprowadzony, skróci diagnozę z godzin do minut. Kluczem jest sposób, w jaki opiszesz problem. AI odpowiada trafniej, gdy dostanie pełny kontekst i dokładną treść błędu, zamiast ogólnego "strona mi nie działa".
Mój sprawdzony prompt diagnostyczny:
Jestem początkującą użytkowniczką WordPressa. Moja strona [adres lub opis: blog / sklep WooCommerce / platforma kursowa] przestała działać po [co robiłaś ostatnio: aktualizacji wtyczki X / zmianie w motywie / niczym konkretnym]. Widzę taki komunikat: [wklej DOKŁADNĄ treść błędu]. Mój hosting to [nazwa], motyw to [nazwa], kluczowe wtyczki to [lista]. Podaj mi listę najbardziej prawdopodobnych przyczyn od najczęstszej do najrzadszej oraz instrukcję sprawdzenia każdej z nich krok po kroku, po polsku, dla osoby nietechnicznej. Zanim zaproponujesz zmianę w plikach, wyjaśnij, co ona robi i jakie niesie ryzyko.
Trzy zasady bezpieczeństwa, których pilnuję:
- Nigdy nie wklejam do czatu danych logowania, haseł ani kluczy API. Treść błędu tak, dane dostępowe nigdy.
- Zanim wykonam sugestię dotyczącą edycji plików (np. wp-config.php czy functions.php), robię kopię zapasową pliku. Jedna literówka w tych plikach potrafi położyć stronę.
- Jeśli AI proponuje polecenie lub kod, proszę o wyjaśnienie każdej linii. Jeśli wyjaśnienie brzmi niejasno, nie wdrażam i doprecyzowuję pytanie.
W ten sposób AI pełni rolę cierpliwego konsultanta technicznego dostępnego 24/7. A jeśli chcesz nauczyć się wykorzystywać AI w prowadzeniu całej strony, od budowy po treści, dokładnie tego uczę w Akademii WordPress + AI.
Kiedy napisać do hostingu, a kiedy poradzisz sobie sama
Poradzisz sobie sama: konflikt wtyczek, problem z motywem, brak wtyczki cache, brak motywu domyślnego, opóźnione zadania.
Napisz do hostingu: nieudana aktualizacja z komunikatem o kopiowaniu plików lub sygnaturze, brak miejsca na serwerze, czas odpowiedzi serwera stale powyżej 600 ms mimo cache, włączenie Redis, podejrzenie problemu z PHP po stronie serwera.
Do zgłoszenia zawsze wklejaj dokładną treść komunikatu i napisz, co robiłaś tuż przed wystąpieniem błędu. Skrócisz czas obsługi o połowę.
Krok po kroku
Wdróż te kroki dziś, a następny błąd krytyczny będzie tylko drobną przygodą:
- Sprawdź, czy znasz adres e-mail administratora swojej strony i czy masz do niego dostęp. Tam przyjdzie mail ratunkowy.
- Zainstaluj jeden motyw domyślny (bez włączania), jeśli jeszcze go nie masz.
- Zainstaluj i włącz wtyczkę cache, a potem sprawdź Stan witryny.
- Ustaw automatyczne kopie zapasowe (wtyczką lub w panelu hostingu) i zanotuj, jak przywrócić kopię.
- Zapisz sobie prompt diagnostyczny z tego artykułu w notatkach, żeby był pod ręką w sytuacji awaryjnej.
