ITPER

„Na tej stronie wystąpił błąd krytyczny” – naprawa strony WordPress krok po kroku, bez paniki

21 października 2026
Michał Pervinenko
8 min czytania
Błąd krytyczny w WordPressie i biały ekran – co zrobić krok po kroku

Komunikat „Na tej stronie wystąpił błąd krytyczny” oznacza, że WordPress natrafił na błąd w kodzie PHP – najczęściej we wtyczce, motywie albo po zmianie wersji PHP na serwerze – i zatrzymał wyświetlanie strony. Twoje treści i zamówienia zwykle są całe, a pierwszym krokiem jest sprawdzenie skrzynki administratora: WordPress wysyła tam mail z linkiem do trybu odzyskiwania.

Ten komunikat wygląda groźnie, a biały ekran bez żadnej treści jeszcze bardziej. Dobra wiadomość jest taka, że w większości przypadków to usterka do naprawienia w kilkadziesiąt minut, a nie utrata strony. Zła – że nerwowe klikanie na ślepo potrafi ją pogorszyć.

Poniżej opisuję, co oznacza ten błąd, co możesz bezpiecznie zrobić sam jako właściciel firmy, a w którym momencie lepiej zatrzymać się i oddać sprawę komuś, kto na co dzień zajmuje się naprawą stron WordPress.

Co oznacza komunikat „Na tej stronie wystąpił błąd krytyczny”?

Oznacza, że podczas ładowania strony jakiś fragment kodu PHP spowodował błąd, którego WordPress nie umiał obejść, więc zamiast strony wyświetlił ogólny komunikat. Od wersji 5.2 WordPress ma wbudowaną ochronę: wyłapuje taki błąd, wskazuje winną wtyczkę lub motyw i wysyła o tym maila do administratora.

Czasem komunikat dotyczy całej strony, a czasem tylko panelu administracyjnego albo jednej podstrony (np. koszyka). Starsze instalacje lub poważniejsze błędy zamiast komunikatu pokazują po prostu biały ekran – to ten sam problem, tylko bez podpowiedzi.

Ważne: błąd krytyczny nie oznacza, że strona została skasowana. Pliki i baza danych zwykle są nietknięte, po prostu kod, który je wyświetla, w danej chwili się wysypuje.

Jakie są najczęstsze przyczyny białego ekranu w WordPressie?

Najczęstsze przyczyny to: świeżo zaktualizowana lub zainstalowana wtyczka, aktualizacja motywu, zmiana wersji PHP przez firmę hostingową oraz brak pamięci na serwerze. Rzadziej winna jest ręczna edycja plików motywu albo uszkodzony plik po przerwanej aktualizacji.

Rozbijam to na przypadki, które widzę najczęściej:

  • Wtyczka – nowa wersja ma błąd albo gryzie się z inną wtyczką. Typowy scenariusz: wieczorem automatyczne aktualizacje, rano biały ekran.
  • Motyw – szczególnie motywy kupione kilka lat temu, które nie są już rozwijane, albo motyw potomny z własnymi modyfikacjami.
  • Wersja PHP – hosting podnosi wersję PHP (np. z 7.4 na 8.x), a stara wtyczka lub motyw nie jest z nią zgodny. Strona działała latami i nagle przestaje, choć nikt nic nie zmieniał.
  • Pamięć – rozbudowany sklep lub page builder potrzebuje więcej pamięci, niż pozwala serwer. Często objawia się błędem tylko na niektórych podstronach.
  • Ręczne zmiany – ktoś edytował plik motywu z poziomu panelu i zostawił literówkę.
Dobrze zadać sobie pytanie: co zmieniło się tuż przed awarią? Aktualizacja, nowa wtyczka, zmiana na hostingu? To zwykle najkrótsza droga do przyczyny.

Gdzie znaleźć mail z linkiem do trybu odzyskiwania?

WordPress wysyła mail na adres e-mail administratora ustawiony w Ustawieniach ogólnych, zwykle z tematem w rodzaju „Twoja witryna ma problem techniczny”. W treści jest nazwa wtyczki lub motywu, który spowodował błąd, oraz specjalny link, który pozwala zalogować się do panelu w trybie odzyskiwania.

Jeśli maila nie widzisz:

  • Sprawdź folder spam i oferty, a także skrzynkę osoby, która zakładała stronę – często adres administratora to stary mail wykonawcy.
  • Pamiętaj, że link działa przez ograniczony czas. Jeśli wygasł, kolejny mail przyjdzie przy następnym wystąpieniu błędu.
  • Na niektórych serwerach WordPress w ogóle nie potrafi wysyłać maili (brak skonfigurowanego SMTP) – wtedy wiadomość po prostu nie przychodzi.

Jak skorzystać z trybu odzyskiwania

Po kliknięciu linku logujesz się normalnie, a WordPress tymczasowo wyłącza dla Ciebie problematyczną wtyczkę lub motyw. Na górze panelu zobaczysz informację o trybie odzyskiwania. Przejdź do listy wtyczek, znajdź tę wskazaną w mailu i kliknij „Wyłącz”. Następnie wyjdź z trybu odzyskiwania i sprawdź stronę w oknie prywatnym przeglądarki.

Jeśli strona działa, problem jest zlokalizowany. Teraz trzeba zdecydować, czy wtyczka jest potrzebna, czy da się ją zastąpić albo poczekać na poprawkę od autora. Uwaga: jeśli wyłączona wtyczka odpowiadała za płatności, wysyłkę lub formularz, część funkcji strony przestanie działać – wtedy daj znać specjaliście jeszcze tego samego dnia.

Jakie kroki mogę bezpiecznie wykonać sam?

Sam możesz bezpiecznie: skorzystać z linku trybu odzyskiwania, wyłączyć wskazaną wtyczkę, wyczyścić pamięć podręczną, przywrócić w panelu hostingu poprzednią wersję PHP i poprosić hosting o przywrócenie kopii sprzed awarii. Nie usuwaj wtyczek, plików ani bazy danych „na próbę” – wyłączenie zawsze jest bezpieczniejsze niż kasowanie.

Moja kolejność dla właściciela firmy:

  • Nie panikuj i nie klikaj losowo. Zrób zrzut ekranu komunikatu i zanotuj godzinę – przyda się przy diagnozie.
  • Sprawdź, czy błąd widać wszędzie. Otwórz stronę w oknie prywatnym i na telefonie (na danych komórkowych). Czasem to tylko pamięć podręczna Twojej przeglądarki.
  • Poszukaj maila trybu odzyskiwania i postępuj jak wyżej.
  • Sprawdź panel hostingu. Jeśli hosting niedawno zmienił wersję PHP, zwykle możesz wrócić do poprzedniej jednym przełączeniem. To rozwiązanie tymczasowe – stara wersja PHP przestaje dostawać poprawki bezpieczeństwa, więc wtyczki i tak trzeba będzie dostosować.
  • Zadzwoń lub napisz do hostingu. Firmy hostingowe często widzą w logach serwera, co dokładnie się wysypało, i mogą przywrócić kopię.

Czego nie robić

  • Nie usuwaj wtyczek z poziomu serwera, jeśli nie wiesz, co robią – niektóre trzymają ustawienia, których nie da się łatwo odtworzyć.
  • Nie instaluj „wtyczek naprawiających wszystko” znalezionych w sieci.
  • Nie edytuj pliku wp-config.php ani plików motywu, jeśli nie masz kopii i doświadczenia. Włączenie trybu debugowania WordPressa pomaga w diagnozie, ale na działającej stronie potrafi pokazać odwiedzającym szczegóły techniczne – to zadanie dla specjalisty.
  • Nie przywracaj kopii bazy danych w sklepie bez zastanowienia (o tym niżej).

Kiedy przywrócić kopię zapasową, a kiedy lepiej tego nie robić?

Przywrócenie kopii ma sens, gdy wiesz, kiedy pojawił się błąd, masz kopię sprzed tego momentu i od tego czasu na stronie nie przybyło ważnych danych. W sklepie internetowym trzeba uważać: przywrócenie całej bazy danych z wczoraj skasuje dzisiejsze zamówienia i rejestracje klientów.

Praktyczne zasady:

  • Strona firmowa bez sklepu – przywrócenie kopii sprzed awarii jest zwykle bezpieczne i najszybsze. Stracisz najwyżej zmiany wprowadzone po jej wykonaniu.
  • Sklep WooCommerce – zanim cokolwiek przywrócisz, sprawdź, czy od czasu kopii nie było zamówień. Często lepiej przywrócić tylko pliki (wtyczki, motyw), a bazę zostawić. Tę decyzję warto podjąć ze specjalistą.
  • Brak pewności, która kopia jest „zdrowa” – nie przywracaj kolejnych kopii po kolei. Każda próba nadpisuje stan strony i utrudnia diagnozę.
Jeśli kopii nie ma w ogóle, nie wszystko stracone – większość błędów krytycznych da się naprawić bez kopii. Ale to dobry moment, żeby pomyśleć o stałej opiece technicznej nad stroną WordPress, w której kopie są robione automatycznie i trzymane poza serwerem.

Kiedy dzwonić do specjalisty od naprawy stron internetowych?

Dzwoń od razu, gdy: błąd dotyczy sklepu i blokuje zamówienia, nie masz dostępu do panelu ani maila odzyskiwania, błąd wrócił po wyłączeniu wtyczki, hosting mówi o braku pamięci lub problemie z bazą danych, albo podejrzewasz, że ktoś włamał się na stronę.

Sygnały, że to coś więcej niż zwykły konflikt wtyczek:

  • Na stronie pojawiły się obce treści, reklamy albo przekierowania na inne adresy.
  • W panelu widzisz administratorów, których nie zakładałeś.
  • Hosting zablokował konto lub przysłał ostrzeżenie o złośliwym kodzie.
W takim przypadku nie zaczynaj od przywracania kopii – najpierw przeczytaj, co robić, gdy strona WordPress jest zhakowana.

Jak wygląda naprawa u mnie: dostaję dostęp do hostingu i panelu, robię kopię aktualnego stanu (nawet zepsutego – to ważne dla bezpieczeństwa danych), czytam logi błędów, wyłączam lub poprawiam winny element i sprawdzam najważniejsze ścieżki: stronę główną, formularz, koszyk i płatność. Typowy błąd krytyczny po aktualizacji to zwykle kwestia godzin, a nie dni – o ile jest dostęp do hostingu.

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

Najlepsza profilaktyka to aktualizacje robione świadomie, a nie automatycznie wszystkie naraz: z kopią przed, testem po i sprawdzeniem zgodności z wersją PHP. Do tego mniej wtyczek, motyw, który jest nadal rozwijany, i kopie przechowywane poza serwerem.

Krótka lista:

  • Usuń wtyczki, których nie używasz – każda to dodatkowy kod, który może się zepsuć.
  • Sprawdzaj, kiedy wtyczka była ostatnio aktualizowana przez autora. Rok bez aktualizacji to sygnał ostrzegawczy.
  • Większe aktualizacje (np. WooCommerce, page builder, zmiana PHP) testuj najpierw na kopii strony.
  • Ustaw adres administratora na skrzynkę, którą faktycznie czytasz.
Więcej o samej technice aktualizowania i o tym, co zrobić, gdy już coś poszło nie tak, piszę we wpisie aktualizacja WordPressa zepsuła stronę.

Czy po błędzie krytycznym strona straci pozycje w Google?

Krótka awaria, trwająca kilka godzin, zwykle nie ma trwałego wpływu na pozycje. Problem pojawia się, gdy strona nie działa przez kilka dni – wtedy Google może zacząć traktować podstrony jako niedostępne, a odzyskanie widoczności trwa.

Dlatego warto działać szybko i po naprawie zajrzeć do Google Search Console, czy nie pojawiły się nowe błędy indeksowania. O tym, jak technicznie sprawna strona przekłada się na widoczność, pisałem w tekście UX to nowe SEO. Jeśli widoczność spadła, pomogę też w ramach pozycjonowania SEO.

Podsumowanie

  • Błąd krytyczny to zwykle problem z wtyczką, motywem, wersją PHP lub pamięcią – treści strony najczęściej są całe.
  • Najpierw szukaj maila z linkiem trybu odzyskiwania i wyłącz wskazaną wtyczkę zamiast ją usuwać.
  • Bezpieczne kroki dla właściciela: tryb odzyskiwania, wyczyszczenie pamięci podręcznej, powrót do poprzedniej wersji PHP, kontakt z hostingiem.
  • W sklepie nie przywracaj całej bazy danych bez sprawdzenia, czy nie skasujesz nowych zamówień.
  • Dzwoń do specjalisty, gdy błąd blokuje sprzedaż, wraca albo widzisz oznaki włamania.
Masz błąd krytyczny teraz i nie wiesz, od czego zacząć? Napisz lub zadzwoń pod 886 126 158 – w ramach naprawy stron i sklepów WordPress najpierw bezpłatnie ocenię problem i powiem, ile potrwa naprawa.

Masz wątpliwości? Odpowiadam

Oznacza, że podczas ładowania strony jakiś fragment kodu PHP spowodował błąd, którego WordPress nie umiał obejść, więc zamiast strony wyświetlił ogólny komunikat. Od wersji 5.2 WordPress ma wbudowaną ochronę: wyłapuje taki błąd, wskazuje winną wtyczkę lub motyw i wysyła o tym maila do administratora.

Najczęstsze przyczyny to: świeżo zaktualizowana lub zainstalowana wtyczka, aktualizacja motywu, zmiana wersji PHP przez firmę hostingową oraz brak pamięci na serwerze. Rzadziej winna jest ręczna edycja plików motywu albo uszkodzony plik po przerwanej aktualizacji.

WordPress wysyła mail na adres e-mail administratora ustawiony w Ustawieniach ogólnych, zwykle z tematem w rodzaju „Twoja witryna ma problem techniczny”. W treści jest nazwa wtyczki lub motywu, który spowodował błąd, oraz specjalny link, który pozwala zalogować się do panelu w trybie odzyskiwania.

Sam możesz bezpiecznie: skorzystać z linku trybu odzyskiwania, wyłączyć wskazaną wtyczkę, wyczyścić pamięć podręczną, przywrócić w panelu hostingu poprzednią wersję PHP i poprosić hosting o przywrócenie kopii sprzed awarii. Nie usuwaj wtyczek, plików ani bazy danych „na próbę” – wyłączenie zawsze jest bezpieczniejsze niż kasowanie.

Przywrócenie kopii ma sens, gdy wiesz, kiedy pojawił się błąd, masz kopię sprzed tego momentu i od tego czasu na stronie nie przybyło ważnych danych. W sklepie internetowym trzeba uważać: przywrócenie całej bazy danych z wczoraj skasuje dzisiejsze zamówienia i rejestracje klientów.

Jak sprawdzić, czy AI cytuje Twoją stronę – GSC, GA4 i testy
21 października 2026

Jak sprawdzić, czy AI cytuje Twoją stronę – GSC, GA4 i testy

Omnibus w sklepie internetowym – najniższa cena z 30 dni i opinie
21 października 2026

Omnibus w sklepie internetowym – najniższa cena z 30 dni i opinie

Baner cookies i Consent Mode v2 – jak zbierać zgody i nie tracić danych
21 października 2026

Baner cookies i Consent Mode v2 – jak zbierać zgody i nie tracić danych

Dostępność cyfrowa sklepu internetowego – EAA i WCAG w praktyce
21 października 2026

Dostępność cyfrowa sklepu internetowego – EAA i WCAG w praktyce

Strona dla szkoleń kosmetologicznych – zapisy, zadatki, SEO
21 października 2026

Strona dla szkoleń kosmetologicznych – zapisy, zadatki, SEO

Strona dla producenta chemii przemysłowej – SDS, B2B, eksport
21 października 2026

Strona dla producenta chemii przemysłowej – SDS, B2B, eksport

Strona dla producenta żywności – katalog, hurt, gdzie kupić
21 października 2026

Strona dla producenta żywności – katalog, hurt, gdzie kupić

Sklep internetowy ze słodyczami – wysyłka, sezon, alergeny
21 października 2026

Sklep internetowy ze słodyczami – wysyłka, sezon, alergeny

Sklep internetowy z suplementami – przepisy, opisy, subskrypcje
21 października 2026

Sklep internetowy z suplementami – przepisy, opisy, subskrypcje

Strona internetowa dla firmy remontowej – co musi mieć w 2026
21 października 2026

Strona internetowa dla firmy remontowej – co musi mieć w 2026

Zobacz wszystkie wpisy

Potrzebujesz strony lub sklepu?

Zadzwoń lub napisz – bezpłatnie doradzę, jak rozwiązać Twój problem.

886 126 158
itper.pl@gmail.com
Odpowiedź w 24h
ITPER.pl