Biały ekran śmierci w WordPress (WSoD) – diagnoza i naprawa 2026

Biały ekran śmierci (White Screen of Death, WSoD) to stan, w którym strona WordPressa zwraca czystą, białą kartę bez żadnego komunikatu, paska nawigacji ani stopki. Przeglądarka otrzymuje odpowiedź HTTP 200 albo 500, ale sam dokument HTML jest pusty lub urwany w połowie. Z perspektywy użytkownika wygląda to tak, jakby serwer w ogóle nie wiedział, co odpowiedzieć.

W praktyce WSoD oznacza, że PHP przestało wykonywać kod w trakcie ładowania strony. Najczęściej powodem jest fatalny błąd PHP, który zatrzymuje interpreter przed wysłaniem jakiejkolwiek treści do przeglądarki. Czasem PHP próbuje zaalokować więcej pamięci, niż pozwala limit hostingu, i cały proces kończy się awaryjnie. Innym razem winne są uszkodzone pliki core WordPressa albo niekompatybilna wtyczka po aktualizacji PHP do wersji 8.x.

WSoD potrafi dotknąć tylko panelu /wp-admin/, tylko frontu sklepu, albo całej witryny naraz. Rozróżnienie tych wariantów pomaga szybciej zawęzić przyczynę – jeśli panel działa, a front jest biały, problem zwykle tkwi w aktywnym motywie albo we wtyczce renderującej frontend.

Zanim zaczniesz grzebać w plikach, warto znać typowe scenariusze. Każdy z nich zostawia inny ślad, więc po objawach można domyślić się, od czego zacząć naprawę.

1. Fatalny błąd PHP we wtyczce lub motywie – biały ekran po zainstalowaniu nowego pluginu lub po aktywacji motywu. W debug.log pojawi się wpis typu `PHP Fatal error: Uncaught Error: Call to undefined function`.

2. Przekroczony memory_limit PHP – strona działa przez chwilę, a potem pada przy cięższych stronach (lista zamówień WooCommerce, edytor Gutenberg z wieloma blokami). W logu: `Allowed memory size of X bytes exhausted`.

3. Uszkodzony plik .htaccess – WSoD pojawia się po instalacji wtyczki cache, po przełączeniu permalinków albo po ingerencji w regułki przekierowań. Często 500 zamiast białego ekranu.

4. Nieudana aktualizacja core lub wtyczki – WSoD po kliknięciu Aktualizuj. W wp-content/ zostaje plik .maintenance albo niedograny archiwum ZIP.

5. Konflikt wtyczek po aktualizacji PHP do 8.x – stara wtyczka używa funkcji usuniętych w PHP 8 (np. `each()`, `create_function`). Biały ekran pojawia się dopiero po zmianie wersji PHP u hostingodawcy.

6. Uszkodzone pliki core WordPressa – nietypowy błąd parsera albo brak podstawowych funkcji. Zdarza się po nieudanym FTP, przerwanej aktualizacji albo ataku malware.

7. Włamanie i wstrzyknięty malware w index.php – WSoD z charakterystycznym długim ciągiem zakodowanym base64 na początku pliku. Antywirus hostingu często blokuje wykonanie, stąd pustka.

8. Hosting: skończone miejsce na dysku lub przepełniona baza – błędy zapisu sesji, brak możliwości zapisu cache, nagły WSoD bez żadnych zmian w plikach. Objawem bywa też komunikat `Error establishing a database connection` tuż przed pełnym WSoD.

Biały ekran sam w sobie nic nie mówi, ale WordPress ma wbudowany mechanizm logowania błędów PHP. Wystarczy włączyć kilka stałych w pliku `wp-config.php`. Zaloguj się przez FTP (FileZilla, WinSCP lub klient wbudowany w panel hostingu), pobierz plik z katalogu głównego WordPressa i edytuj go lokalnie.

Znajdź linię `/* That's all, stop editing! Happy blogging. */` i tuż nad nią wstaw:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Taka konfiguracja zapisuje wszystkie błędy do `wp-content/debug.log`, ale nie wyświetla ich w HTML. To ważne na stronie produkcyjnej – nie chcesz pokazywać stack trace'ów użytkownikom ani botom Google. Wgraj plik z powrotem, odśwież stronę i pobierz log.

W debug.log szukaj pierwszego wpisu `PHP Fatal error` – to on zatrzymał wykonywanie strony. Log zawiera pełną ścieżkę do pliku i numer linii, w której PHP się wywrócił. 90% przypadków WSoD da się od razu przypisać konkretnej wtyczce lub motywowi właśnie na podstawie tej jednej linijki. Jeśli plik debug.log nie powstaje, sprawdź uprawnienia katalogu wp-content/ (powinno być 755) i plik wp-config.php (644).

Jeśli nie masz dostępu do panelu WordPressa (bo WSoD go też dotknął), nie wyłączysz wtyczek klasycznie. Robi się to przez FTP w 10 sekund: zmień nazwę katalogu `wp-content/plugins/` na `wp-content/plugins_off/`. WordPress nie znajdzie żadnej wtyczki, automatycznie wszystkie dezaktywuje i pokaże normalną stronę – jeśli winowajcą był plugin.

Gdy strona wraca do życia, wróć do panelu, zmień nazwę katalogu z powrotem na `plugins` i włączaj wtyczki pojedynczo. Po każdej aktywacji odśwież front i panel. Ta, która ponownie położy stronę, jest winowajcą. Typowi podejrzani: stare wtyczki cache (WP Super Cache w wersjach sprzed 2024), edytory wizualne (Elementor Pro, WPBakery) i wtyczki bezpieczeństwa, które konfliktują z innymi filtrami.

Jeśli masz dużo wtyczek, zastosuj metodę binarną – wyłącz połowę, sprawdź, czy działa, potem połowę z winnej połowy. W 5-6 iteracjach zidentyfikujesz winowajcę nawet przy 50 aktywnych wtyczkach. Gdy już wiesz, która wtyczka odpowiada za WSoD, masz trzy opcje: zaktualizować ją do nowszej wersji, zgłosić błąd autorowi albo znaleźć alternatywę. Nie zostawiaj wyłączonej wtyczki aktywowanej częściowo – to często zostawia śmieci w bazie i generuje kolejne problemy.

Jeśli po wyłączeniu wtyczek WSoD nie znika, winny jest prawdopodobnie motyw. Najszybszy test: wymuś przełączenie na motyw domyślny. Przez FTP zmień nazwę katalogu aktywnego motywu w `wp-content/themes/`. WordPress wykryje, że bieżący motyw zniknął, i automatycznie aktywuje pierwszy dostępny motyw domyślny (Twenty Twenty-Five, Twenty Twenty-Four albo Twenty Twenty-Three, zależnie od wersji).

Jeżeli strona ładuje się poprawnie na motywie domyślnym, problem leży w Twoim motywie. Najczęstsza przyczyna to przestarzały kod w pliku `functions.php` – np. wywołanie funkcji, która została usunięta w nowszej wersji PHP. Zajrzyj do `wp-content/themes/[nazwa-motywu]/functions.php` i poszukaj ostatnio zmienionych sekcji.

Jeśli korzystasz z motywu komercyjnego (Divi, Avada, Astra Pro), sprawdź zakładkę aktualizacji u autora. Wielu developerów publikuje hotfixy zaraz po wydaniu nowej wersji PHP. Zanim wrócisz do produkcyjnego motywu, zrób kopię pliku functions.php – jedna błędna linia może natychmiast przywrócić białą stronę. W idealnym świecie używasz motywu potomnego (child theme), żeby takie zmiany były odseparowane od oryginału i przeżywały aktualizacje.

WordPress z WooCommerce, Elementorem i kilkoma wtyczkami SEO potrafi spokojnie pożreć 256 MB pamięci RAM na jedną stronę. Jeśli hosting ma ustawiony limit 128 MB albo niżej, WSoD pojawia się losowo – raz strona działa, raz nie. Objaw w debug.log: `Fatal error: Allowed memory size of 134217728 bytes exhausted`.

Rozwiązanie: dodaj do `wp-config.php` nad linią `/* That's all, stop editing! */` wpis:

define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

To ustawia limit, który WordPress zgłosi do PHP. Problem w tym, że hosting może ignorować ten wpis i narzucać własny sufit. Jeśli po zmianie nic się nie zmieniło, spróbuj edytować `.user.ini` w katalogu głównym:

memory_limit = 512M
max_execution_time = 300

Na niektórych hostingach (Cyberfolks, LH.pl, Zenbox) limity PHP ustawiasz bezpośrednio w panelu klienta – wtedy plik .user.ini nic nie da. Jeżeli jesteś na starym wspólnym hostingu, który nie pozwala podnieść pamięci powyżej 128 MB, to sygnał, żeby zastanowić się nad przeprowadzką. Polecam CyberFolks jako hosting do WordPressa z rozsądnymi limitami i szybkim wsparciem po polsku. Jeżeli dopiero planujesz wdrożenie, zacznij od dobrego hostingu – nasze strony internetowe są zawsze konfigurowane z limitem minimum 512 MB.

Jeśli powyższe kroki nie pomogły, zostają trzy miejsca, które trzeba zweryfikować po kolei. Każde z nich potrafi wywołać WSoD bez żadnej oczywistej przyczyny.

Plik .htaccess. Zmień nazwę pliku `.htaccess` w katalogu głównym na `.htaccess.bak`. Jeśli strona wraca do życia, znaczy że reguły były uszkodzone. Zaloguj się do panelu, wejdź w Ustawienia, Bezpośrednie odnośniki i kliknij Zapisz zmiany – WordPress wygeneruje świeży, poprawny .htaccess. Wcześniejsze customowe reguły (przekierowania 301, reguły cache) musisz dograć ręcznie na podstawie backupu.

Wersja PHP. Zaloguj się do panelu hostingu i sprawdź, jaka wersja PHP jest aktywna. WordPress 6.x wymaga minimum PHP 7.4, ale zalecane jest PHP 8.1 lub 8.2. Jeśli hosting właśnie wymusił przejście na PHP 8.x, a jedna z Twoich starych wtyczek nie jest kompatybilna, tymczasowo wróć do 7.4 i zaktualizuj wtyczki. To samo dotyczy WooCommerce i dużych motywów – zawsze sprawdzaj w dokumentacji wymaganą wersję PHP.

Pliki core WordPressa. Pobierz świeżą paczkę WordPressa z wordpress.org, rozpakuj lokalnie i przez FTP nadpisz katalogi `wp-admin/` i `wp-includes/` na serwerze. Pliku `wp-config.php` ani katalogu `wp-content/` nie ruszaj – tam są Twoje dane. Ta operacja odbudowuje core WordPressa bez utraty treści. Jeśli podejrzewasz malware, zajrzyj też do pliku `index.php` w katalogu głównym – powinien mieć około 20 linijek. Długie ciągi zakodowane base64 to znak włamania – wtedy pilnie skontaktuj się z nami albo zleć audyt cyfrowy, bo naprawa samego index.php nic nie da, jeśli backdoor siedzi w kilku innych plikach.

Naprawa WSoD po fakcie trwa od 15 minut do kilku godzin – zależnie od tego, jak daleko sięga uszkodzenie. Profilaktyka zabiera 10 minut miesięcznie i eliminuje większość takich incydentów.

Staging przed aktualizacjami. Każda większa aktualizacja (WordPress core, PHP, WooCommerce, motyw premium) powinna trafić najpierw na kopię produkcji. Hostingi takie jak CyberFolks czy LH.pl oferują tworzenie stagingu jednym kliknięciem. Aktualizujesz na stagingu, testujesz 15 minut, dopiero wtedy pushujesz zmiany na prod.

Automatyczne backupy z retencją 7-30 dni. UpdraftPlus, BlogVault albo wbudowany system hostingu – byle backup istniał i dało się go szybko odtworzyć. Zapisuj kopie poza serwerem (Google Drive, Dropbox, S3). WSoD po nieudanej aktualizacji naprawisz wtedy w 5 minut przywracając poprzednią wersję plików i bazy.

Monitoring uptime. Darmowe narzędzia typu UptimeRobot albo Better Uptime pingują stronę co 5 minut i wysyłają alert na e-mail lub Slacka, kiedy zwraca 500, timeout albo pustkę. Dzięki temu wiesz o WSoD zanim dowiedzą się klienci.

Aktualne wtyczki i motywy. Usuń wszystko, czego nie używasz – nieaktywna wtyczka też może mieć dziurę bezpieczeństwa i pozostawać niezaktualizowana. Im mniej kodu na stronie, tym mniejsze prawdopodobieństwo konfliktu. Więcej o wolnych stronach znajdziesz w poradniku WordPress wolno się ładuje – wiele tych samych zasad dotyczy też WSoD.

Samodzielna diagnoza ma naturalne granice. Jeżeli po godzinie pracy z debug.log dalej nie wiesz, co jest grane, każda kolejna próba zwykle tylko pogłębia problem. Są trzy sytuacje, w których warto od razu zgłosić się do agencji, zamiast eksperymentować dalej.

Sklep WooCommerce leży dłużej niż godzinę. Każda minuta przestoju to stracone zamówienia, porzucone koszyki i wkurzeni klienci. Agencja zdiagnozuje problem w 30-60 minut, bo ma dostęp do narzędzi, logów i doświadczenia z setek podobnych przypadków. To po prostu tańsze niż przestój.

Podejrzenie włamania. WSoD z długimi ciągami base64 w index.php albo z nietypowymi plikami .php w katalogu wp-content/uploads to czerwona flaga. Sam usunięty malware prawie zawsze wraca, bo backdoor siedzi w innym pliku. Potrzebny jest pełen skan, usunięcie wszystkich śladów, zmiana haseł do bazy i FTP, instalacja wtyczki bezpieczeństwa i monitorowanie przez kolejne tygodnie.

Strona krytyczna dla biznesu. Jeżeli strona generuje leady warte tysiące złotych miesięcznie, 3 godziny przestoju mogą kosztować więcej niż cały roczny budżet na utrzymanie. W takim przypadku opłaca się mieć podpisaną umowę SLA z agencją, żeby interwencja zaczynała się w ciągu 30 minut, a nie następnego dnia.

Koszt jednorazowej naprawy WSoD w agencji: 300-1 200 zł w zależności od złożoności (proste naprawy wtyczki vs. usuwanie malware z setek plików). Pełny audyt bezpieczeństwa i wydajności: 2 000-6 000 zł. Jeżeli powtarzają się błędy na stronie – napisz do nas, zdiagnozujemy i naprawimy. Więcej o pokrewnych błędach znajdziesz w poradnikach Błąd 500 w WordPress oraz Problemy z LiteSpeed Cache.