Jeszcze sekundę temu strona działała, kończył Pan artykuł lub konfigurował WooCommerce i nagle pustka. Biała strona zamiast panelu administracyjnego. Albo strona główna zniknęła, choć kokpit menedżerski się otwiera. Znajomy widok? Witamy w klubie, spotkał się Pan z White Screen of Death, znanym też jako WSOD, czyli „biały ekran śmierci" WordPress.

Panika jest tu pierwszym wrogiem. WSOD prawie nigdy nie oznacza, że strona umarła bezpowrotnie. Najczęściej przyczyna jest banalna: konflikt wtyczek po aktualizacji, krzywo wstawiony kod w functions.php lub zwykły brak pamięci dla procesu PHP. W tym poradniku przedstawiamy cztery sprawdzone sposoby na przywrócenie strony do życia i piąty, wbudowany w rdzeń WordPress, o którym zapominają nawet doświadczeni użytkownicy.

💡 Szybki przegląd:

• Wyłączenie problematycznej wtyczki przez FTP (zmiana nazwy folderu) lub zbiorczo, przez zmianę nazwy katalogu plugins
• Wyłączenie konfliktowego motywu tą samą metodą: folder themes → zmiana nazwy katalogu aktywnego motywu
• Podniesienie limitu pamięci PHP linią WP_MEMORY_LIMIT w wp-config.php do 128M lub 256M
• Włączenie WP_DEBUG i WP_DEBUG_LOG do diagnostyki, poznanie dokładnej przyczyny błędu z pliku debug.log
• Użycie trybu odzyskiwania (Recovery Mode, WordPress 5.2+), wbudowanego mechanizmu, który wysyła link do logowania do panelu administracyjnego nawet przy błędzie krytycznym
• Przywrócenie strony z kopii zapasowej, jeśli inne metody nie przyniosły rezultatu

1. Wyłączenie problematycznej wtyczki

Wtyczki to najczęstsza przyczyna WSOD. Właśnie zaktualizował Pan ulubioną wtyczkę do cache’owania i ekran zgasł. Zainstalował Pan nowy slider i strona przestała się otwierać. Mechanika jest prosta: kod PHP wtyczki wywołuje błąd krytyczny, a WordPress całkowicie zatrzymuje ładowanie strony.

Problem w tym, że nie można wejść do panelu administracyjnego i kliknąć „Dezaktywuj", panel również wyświetla białą stronę. Rozwiązanie: wyłączyć wtyczkę bezpośrednio przez system plików.

Jak wyłączyć jedną wtyczkę przez FTP:

• Proszę połączyć się z serwerem przez FTP (FileZilla, WinSCP) lub przez menedżer plików hostingu (cPanel → File Manager).
• Proszę przejść do katalogu głównego WordPressa.
• Proszę otworzyć wp-content/plugins.
• Proszę znaleźć folder problematycznej wtyczki, nazwa odpowiada nazwie wtyczki (na przykład akismet, woocommerce lub elementor).
• Proszę zmienić nazwę folderu: dodać znak podkreślenia lub sufiks, _akismet lub akismet_disabled. WordPress potraktuje zmianę nazwy jako brak wtyczki i ją dezaktywuje.

Natychmiast po zmianie nazwy proszę otworzyć stronę w przeglądarce. Jeśli zadziałała, winowajca został znaleziony. Teraz można przywrócić folderowi oryginalną nazwę i po zalogowaniu do panelu administracyjnego albo zaktualizować wtyczkę do zgodnej wersji, albo ją usunąć i znaleźć alternatywę.

Zbiorcze wyłączenie wszystkich wtyczek naraz. Jeśli nie wiadomo, która konkretnie wtyczka spowodowała awarię, proszę wyłączyć wszystkie hurtem. Proszę zmienić nazwę samego folderu wp-content/plugins na plugins_old i utworzyć obok nowy, pusty katalog plugins. Wszystkie wtyczki są dezaktywowane. Następnie proszę przywracać je pojedynczo: przenieść folder wtyczki z plugins_old z powrotem do plugins, zalogować się do panelu administracyjnego, aktywować i sprawdzić stronę. Proszę powtarzać, aż znajdzie Pan winowajcę.

Alternatywa dla tych, którzy mają WP-CLI. Jedno polecenie w terminalu zastępuje taniec z szablami przez FTP:

1
wp plugin deactivate --all

A potem proszę aktywować pojedynczo: wp plugin activate <slug>. Szybko, czysto, bez menedżera plików.

2. Wyłączenie konfliktowego motywu

Drugi pod względem częstości winowajca to motyw. Scenariusze są te same: zaktualizował Pan motyw do nowej wersji głównej, zainstalował Pan motyw ze źle napisanym functions.php lub wtyczka weszła w konflikt z bieżącym motywem po aktualizacji WordPressa.

Mechanizm naprawy jest prawie identyczny jak przy wtyczkach:

• Proszę wejść przez FTP do wp-content/themes.
• Proszę znaleźć folder aktywnego motywu (tego, który jest aktualnie ustawiony na stronie).
• Proszę zmienić jego nazwę, na przykład dodać _disabled na końcu nazwy.

WordPress, nie znajdując aktywnego motywu, automatycznie przełączy się na standardowy motyw Twenty Twenty-Five (lub Twenty Twenty-Four, w zależności od wersji WP). Strona załaduje się z domyślnym wyglądem, ale cała Pana treść pozostanie na swoim miejscu. Ważne: proszę nie usuwać standardowego motywu, w przeciwnym razie nie będzie na co się przełączyć i czeka Pana kolejna runda WSOD.

Źle zakodowane motywy a aktualizacje WordPressa. Po dużej premierze WordPressa stare motywy, używające przestarzałych funkcji lub haków, mogą się psuć. Dobrej jakości motywy od sprawdzonych deweloperów są aktualizowane w ciągu kilku dni od wydania rdzenia. Jeśli Pana motyw nie był aktualizowany od pół roku lub dłużej, to czerwona flaga: proszę zmienić go na taki, który jest aktywnie wspierany.

Edycja functions.php i innych plików motywu. Literówka w functions.php, zbędny nawias, nieprawidłowe wywołanie haka i strona pada. Jeśli edytował Pan pliki motywu bezpośrednio przed pojawieniem się WSOD, proszę zastąpić zmieniony plik oryginalną wersją z kopii zapasowej lub dystrybucji motywu. Bez kopii zapasowej proszę pobrać motyw ponownie ze źródła i wgrać czysty plik.

3. Przekroczenie limitu pamięci PHP

Strona rosła, wtyczek przybywało, ruch poszedł w górę i nagle WSOD. To klasyczny symptom tego, że procesowi PHP zaczęło brakować pamięci operacyjnej. Szczególnie dotyczy to tanich hostingów, gdzie jeden serwer obsługuje setki stron, a limit na każdego klienta jest przycięty do minimum.

WordPress oficjalnie zaleca minimum 64 MB pamięci, ale ta rekomendacja pochodzi z epoki PHP 5.6 i pięciu wtyczek na stronę. W 2026 roku realistyczne minimum dla działającej strony to 128 MB, a dla zestawów z Elementor, WooCommerce i kilkudziesięcioma wtyczkami to 256 MB.

Jak zwiększyć limit pamięci:

Proszę otworzyć plik wp-config.php (znajduje się w katalogu głównym instalacji WordPressa) i dodać linię przed komentarzem /* That's all, stop editing! */:

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

Jeśli dostawca sztywno ogranicza pamięć PHP na poziomie serwera, ta dyrektywa nie zadziała, wtedy jest jedno wyjście: zmienić taryfę lub hosting. Zarządzany hosting WordPress (SiteGround, WP Engine, Kinsta) konfiguruje limity odpowiednio od razu i problem z pamięcią praktycznie tam nie występuje.

4. Diagnostyka przez WP_DEBUG

Bywa, że ani wtyczki, ani motyw, ani pamięć nie mają tu nic do rzeczy, przyczyna WSOD wymyka się. Wtedy trzeba zmusić WordPressa, by powiedział, co dokładnie poszło nie tak.

WordPress od dekad nosi w sobie wbudowany debugger WP_DEBUG. Domyślnie jest wyłączony (biały ekran zamiast błędów to zamysł, by nie pokazywać wnętrzności strony odwiedzającym). Ale dla administratora ten tryb jest bezcenny.

Proszę dodać w wp-config.php:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Co się dzieje:

• WP_DEBUG włącza tryb debugowania;
• WP_DEBUG_LOG zapisuje błędy do pliku wp-content/debug.log, wygodnie się go czyta, nie pokazując ich odwiedzającym;
• WP_DEBUG_DISPLAY z wartością false ukrywa błędy na ekranie (widzi Pan białą stronę, ale logi są zapisywane).

Po włączeniu proszę otworzyć stronę, odtworzyć problem i zajrzeć do wp-content/debug.log. Będzie tam linia z plikiem, numerem linii i typem błędu, na przykład Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. To dokładny adres problemu.

Ważne: proszę nie zostawiać WP_DEBUG włączonego na produkcji po diagnostyce, logi rosną szybko i mogą zapchać przestrzeń dyskową.

5. Recovery Mode, wbudowany ratownik WordPress 5.2+

Od wersji 5.2 WordPress potrafi sam rozpoznawać błędy krytyczne i proponować drogę odwrotu. Recovery Mode (tryb odzyskiwania) to funkcja, której wielu administratorów wciąż nie używa, po prostu dlatego, że o niej nie wie.

Jak to działa. Gdy kod PHP wtyczki lub motywu wywołuje błąd krytyczny, WordPress przechwytuje go, zatrzymuje problematyczne rozszerzenie i wysyła wiadomość na email administratora. W wiadomości znajduje się link, który otwiera dostęp do panelu administracyjnego z pominięciem problematycznego kodu. Loguje się Pan, widzi wtyczkę, która upadła, z oznaczeniem „wywołała błąd", dezaktywuje ją i strona znów żyje. Żadnego FTP, żadnego zmieniania nazw folderów.

Ograniczenia Recovery Mode:

• Link działa przez ograniczony czas (około doby) i jest powiązany z adresem IP;
• Wymagane jest skonfigurowane wysyłanie poczty ze strony (wtyczka SMTP lub poczta hostingowa);
• Nie ratuje przed błędami na poziomie serwera (brak pamięci, uszkodzony .htaccess).

Mimo to, jeśli wiadomość przyszła, oszczędza Pan kilkanaście minut nerwów i działań przez FTP.

Proszę obejrzeć krótki poradnik naprawy WSOD, wszystkie opisane metody z demonstracją na żywo:

⁉️🤔 Często zadawane pytania

Dlaczego biały ekran pojawia się tylko w panelu administracyjnym, a strona otwiera się normalnie?

Błąd jest zlokalizowany w kodzie, który wykonuje się tylko w kokpicie menedżerskim: metabox wtyczki, strona ustawień motywu, niestandardowy widget panelu. Proszę wyłączać ostatnio zainstalowane wtyczki pojedynczo, winowajca znajdzie się szybko. Jeśli to nie pomogło, proszę włączyć WP_DEBUG_LOG i sprawdzić log po próbie zalogowania do panelu.

Biały ekran tylko na jednej stronie wpisu lub artykułu, co to oznacza?

Najprawdopodobniej problem tkwi w treści konkretnego wpisu: shortcode nieistniejącej wtyczki, uszkodzony HTML w tekście, konflikt z polami niestandardowymi. Proszę otworzyć wpis przez Szybką edycję w panelu i tymczasowo zmienić status na „Szkic". Strona się załadowała? Zatem proszę szukać wewnątrz treści.

Czy można w ogóle uniknąć WSOD w przyszłości?

Całkowicie wykluczyć nie, ale zminimalizować ryzyko jest realnie. Trzy zasady: (1) zawsze proszę testować aktualizacje wtyczek i motywów na kopii stagingowej strony przed wdrożeniem na produkcję; (2) proszę mieć codzienną kopię zapasową plików i bazy danych; (3) proszę nie instalować wtyczek i motywów z podejrzanych źródeł, szczególnie wersji nulled.

Recovery Mode nie wysłał wiadomości, co robić?

Poczta ze strony WordPress bez skonfigurowanej wtyczki SMTP działa niestabilnie. Proszę skonfigurować SMTP (Post SMTP, FluentSMTP lub WP Mail SMTP) jako środek zapobiegawczy. Jeśli wiadomość już nie przyszła, proszę wrócić do metody FTP z rozdziału 1, ona działa zawsze.

Po jakim czasie wygasa link Recovery Mode?

Link jest ważny 24 godziny (dokładniej, do wygaśnięcia tokena nonce). Po tym czasie trzeba odtworzyć błąd na nowo, WordPress ponownie wyśle wiadomość.

Co robić, jeśli nic nie pomogło?

Jeśli cztery powyższe metody i Recovery Mode nie przywróciły strony, problem jest głębszy. Być może uszkodzony jest plik .htaccess (proszę zmienić jego nazwę i zalogować się do panelu, WordPress utworzy nowy przez „Ustawienia → Bezpośrednie odnośniki → Zapisz"). Albo występuje niekompatybilność wersji PHP: współczesny WordPress wymaga PHP 7.4+, a na hoście wciąż może być PHP 5.6.

Kolejnym narzędziem diagnostycznym jest wtyczka Health Check & Troubleshooting od zespołu WordPress.org. Potrafi ona uruchomić sesję bezpieczeństwa: wyłącza wszystkie wtyczki i przełącza na standardowy motyw, ale tylko dla Pana przeglądarki (odwiedzający widzą normalną stronę). Dzięki niej można bezpiecznie włączać wtyczki pojedynczo i łapać winowajcę, nie dotykając produkcji.

Nie ma Pan czasu na dochodzenie, a stronę trzeba postawić natychmiast? Proszę przywrócić kopię zapasową. Jeśli nie ma Pan kopii zapasowej, to lekcja na przyszłość: codzienne automatyczne kopie zapasowe kosztują kilka dolarów miesięcznie i zwracają się już pierwszego dnia awarii. Praktycznie każdy hosting oferuje tę funkcję w panelu sterowania.

I najważniejsze, proszę nie bać się WSOD. To nieprzyjemne, ale do rozwiązania. Teraz ma Pan algorytm działania krok po kroku, a nie panikę i pusty ekran.