Biały ekran WordPress. Strona się nie wyświetla: przyczyny i diagnoza krok po kroku

Wpisujesz adres strony i widzisz białą, pustą stronę. Bez logo, bez menu, bez komunikatu. Po angielsku nazywa się to „White Screen of Death”, w skrócie WSOD. Brzmi groźnie, ale w większości przypadków wpisy, strony i zdjęcia są na miejscu. Biały ekran mówi tylko tyle, że coś przerwało budowanie strony, zanim pojawił się pierwszy znak. Poniżej opisujemy, jak ustalić co, zaczynając od kroków, które nie wymagają dostępu do plików.

Biały ekran WordPress czy coś innego? Rozpoznaj objaw

Najczęstsze przyczyny białego ekranu

Kolejność według częstości to nasza ocena na podstawie dokumentacji WordPressa i zgłoszeń na forach wsparcia. Na konkretnej stronie może być inaczej.

1. Błąd we wtyczce lub motywie, gdy tryb odzyskiwania nie zadziałał (często). Od wersji 5.2 WordPress przechwytuje większość takich błędów i pokazuje komunikat o błędzie krytycznym. Biały ekran zostaje, gdy ktoś wyłączył tę obsługę (stała WP_DISABLE_FATAL_ERROR_HANDLER) albo błąd wystąpił, zanim WordPress ją uruchomił.
2. Cache podaje zapisaną pustą stronę (często). Wtyczka cache, hosting albo Cloudflare zapamiętały stronę w chwili awarii i podają ją dalej, choć przyczyna już zniknęła.
3. Za mało pamięci PHP (czasem). Duża wtyczka, kreator stron albo import przekracza limit pamięci. Komunikat „Allowed memory size exhausted” trafia do dziennika, a odwiedzający widzi pustą stronę.
4. Literówka w wp-config.php lub functions.php (czasem). Brakujący średnik, cudzysłów albo spacja przed <?php po ręcznej edycji. Błąd w wp-config.php wywołuje biały ekran, bo ten plik ładuje się przed obsługą błędów.
5. Zmiana wersji PHP na hostingu (rzadziej). Stara wtyczka używa funkcji usuniętej w nowszym PHP. Zobacz Zmiana wersji PHP na hostingu.
6. Uszkodzone lub niekompletne pliki (rzadko). Przerwana aktualizacja, nieudane wgrywanie przez FTP, pełny dysk na hostingu.

Zanim zaczniesz

• Zrób kopię plików i bazy danych w panelu hostingu, także jeśli strona nie działa. Jeśli coś pójdzie nie tak przy naprawie, wrócisz do punktu wyjścia, a nie do gorszego.
• Zapisz, co działo się tuż przed awarią: aktualizacja, nowa wtyczka, edycja motywu, zmiana PHP, przeprowadzka. To najczęściej wskazuje przyczynę szybciej niż jakakolwiek diagnoza.
• Przygotuj dostęp do menedżera plików w panelu hostingu albo FTP. Bez niego wykonasz tylko kroki 1 i 2.
• Edytuj pliki edytorem tekstu, nie Wordem. Menedżer plików hostingu ma wbudowany edytor. Przed każdą zmianą pobierz kopię edytowanego pliku na komputer.

Diagnoza krok po kroku

Krok 1. Sprawdź, czy to nie Twoja przeglądarka

1. Otwórz stronę w oknie prywatnym (incognito).
2. Otwórz ją na telefonie, na danych komórkowych, nie przez firmowe Wi-Fi.
3. Sprawdź kilka podstron i adres twojadomena.pl/wp-admin.

Co powinieneś zobaczyć: jeśli strona działa w oknie prywatnym albo na telefonie, problem leży w przeglądarce. Wyczyść jej pamięć podręczną i pliki cookie dla tej domeny. Jeśli biały ekran widać wszędzie, zanotuj, czy dotyczy strony, panelu czy obu, i przejdź dalej.

Krok 2. Wyczyść cache po stronie serwera

Jeśli panel działa, użyj przycisku czyszczenia cache wtyczki (zwykle w górnym pasku administratora). Potem wyczyść cache hostingu, jeśli hosting go ma, i Cloudflare: Caching → Configuration → Purge Everything. Odczekaj minutę i sprawdź stronę w oknie prywatnym.

Jeśli panel nie działa, a podejrzewasz cache, w menedżerze plików otwórz wp-content i zmień nazwę folderu cache na cache-stary. WordPress utworzy nowy przy następnych odwiedzinach.

Co powinieneś zobaczyć: działającą stronę albo nadal biały ekran. W drugim przypadku przejdź do kroku 3.

Krok 3. Włącz dziennik błędów i przeczytaj go

To najważniejszy krok. Zamiast zgadywać, każesz WordPressowi zapisać, co dokładnie poszło nie tak.

1. W menedżerze plików otwórz główny folder strony i plik wp-config.php.
2. Znajdź linię define( 'WP_DEBUG', false );. Jeśli jest, usuń ją. Jeśli jej nie ma, nic nie usuwaj.
3. Nad komentarzem kończącym ustawienia (w wersji angielskiej /* That's all, stop editing! Happy publishing. */, w polskiej jego tłumaczenie), czyli przed linią z require_once, wklej:

define( 'WP_DEBUG', true );          // włącz tryb diagnostyczny
define( 'WP_DEBUG_LOG', true );      // zapisuj błędy do pliku wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // nie pokazuj błędów odwiedzającym

4. Zapisz plik i odśwież stronę z białym ekranem dwa, trzy razy.
5. Otwórz folder wp-content i plik debug.log. Przewiń na sam dół.

Co powinieneś zobaczyć: linie zaczynające się od daty i PHP Fatal error. Najważniejsza jest ścieżka pliku w tej linii, np. /wp-content/plugins/nazwa-wtyczki/... albo /wp-content/themes/nazwa-motywu/.... Folder po plugins/ lub themes/ to winowajca. Jeśli widzisz Allowed memory size of ... bytes exhausted, przejdź do kroku 6.

Jeśli pliku debug.log nie ma, błąd wystąpił, zanim WordPress zaczął zapisywać dziennik. Sprawdź dziennik błędów w panelu hostingu (w DirectAdmin zwykle Statystyki witryny lub Error Log domeny, w cPanelu Errors). Przy błędzie w samym wp-config.php dziennik hostingu poda numer linii z literówką.

Po naprawie zmień WP_DEBUG z powrotem na false i usuń plik debug.log. Dokumentacja WordPressa odradza zostawianie trybu diagnostycznego na działającej stronie, a dziennik bywa dostępny z zewnątrz i zawiera ścieżki serwera.

Krok 4. Wyłącz wtyczki bez dostępu do panelu

Jeśli dziennik wskazał wtyczkę, wyłącz tylko ją. Jeśli nie wskazał niczego, wyłącz wszystkie i włączaj po kolei.

1. W menedżerze plików otwórz wp-content/plugins.
2. Zmień nazwę folderu winnej wtyczki, np. dopisz -wylaczona. WordPress nie znajdzie wtyczki i ją dezaktywuje.
3. Gdy nie wiesz, która to wtyczka: zmień nazwę całego folderu plugins na plugins-wylaczone, sprawdź stronę, przywróć nazwę plugins, a potem w panelu włączaj wtyczki po jednej i odświeżaj stronę po każdej.
4. Sprawdź też folder wp-content/mu-plugins. Wtyczki z tego folderu ładują się zawsze i nie widać ich na zwykłej liście. Często instaluje je hosting.

Co powinieneś zobaczyć: strona wraca, gdy winna wtyczka jest wyłączona. Nie zostawiaj jej tak na stałe, jeśli od niej zależy formularz, sklep albo bezpieczeństwo. Sprawdź, czy jest nowsza wersja, albo wróć do poprzedniej, jak opisujemy w poradniku WordPress po aktualizacji nie działa.

Krok 5. Sprawdź motyw

1. W wp-content/themes zmień nazwę folderu aktywnego motywu, np. astra na astra-wylaczony.
2. WordPress przełączy się na domyślny motyw (np. Twenty Twenty-Five), o ile jest zainstalowany. Jeśli w folderze themes nie ma żadnego motywu domyślnego, pobierz go z wordpress.org i wgraj.
3. Jeśli strona działa na motywie domyślnym, winny jest Twój motyw albo motyw potomny. Najczęściej plik functions.php motywu potomnego po ręcznej edycji.

Uwaga: na motywie domyślnym strona będzie wyglądać inaczej, a część ustawień (menu, widżety) trzeba będzie potem przywrócić. To krok diagnostyczny. Po ustaleniu przyczyny przywróć nazwę folderu motywu i napraw błąd w pliku, który wskazał dziennik.

Krok 6. Zwiększ limit pamięci

Jeśli dziennik pokazał „Allowed memory size exhausted”, dopisz w wp-config.php, w tym samym miejscu co w kroku 3:

define( 'WP_MEMORY_LIMIT', '256M' );     // pamięć dla strony
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // pamięć dla panelu i zadań administracyjnych

WordPress nie przekroczy jednak limitu ustawionego przez hosting. Sprawdź go w panelu hostingu, w ustawieniach PHP domeny (pole memory_limit). Jeśli hosting ustawia 128 MB, wpis w wp-config.php na 256 MB niczego nie zmieni. Wtedy podnieś limit w panelu albo poproś o to hosting.

Ważne: większy limit to rozwiązanie doraźne. Jeśli strona firmowa potrzebuje ponad 256 MB na zwykłe wyświetlenie strony, któraś wtyczka działa źle i warto ustalić która.

Krok 7. Biały ekran tylko w edytorze

Gdy panel działa, ale zamiast edytora wpisu widzisz pusty obszar, problem leży zwykle w przeglądarce, nie na serwerze.

1. Otwórz edytor w oknie prywatnym. Rozszerzenia przeglądarki (blokery reklam, tłumacze) potrafią zablokować edytor.
2. Naciśnij F12, przejdź do zakładki Console (Konsola) i odśwież stronę. Czerwone komunikaty zwykle zawierają nazwę wtyczki w ścieżce pliku.
3. Wyłącz wtyczki rozbudowujące edytor (bloki, kreatory) i sprawdź ponownie.
4. Wyczyść cache Cloudflare. Stara wersja pliku JavaScript z cache i nowa wersja edytora po aktualizacji to częsty powód.

Kiedy przestać i poprosić o pomoc

• Dziennik pokazuje błędy w plikach rdzenia (wp-includes, wp-admin), a nie wtyczki czy motywu. To może oznaczać uszkodzone pliki albo ingerencję z zewnątrz.
• W plikach widzisz nieznany kod, np. długie ciągi znaków i eval(base64_decode( na początku wp-config.php, index.php lub functions.php. Nie usuwaj tego na ślepo. Zobacz Strona zhakowana: co robić.
• Strona to sklep, a biały ekran pojawia się w koszyku lub przy płatności. Każda godzina to utracone zamówienia, a zmiany na produkcji mogą je zepsuć.
• Nie masz kopii i nie wiesz, co zmieniło się przed awarią.
• Po wszystkich krokach strona nadal jest pusta, a dziennik milczy.

Jak zapobiegać

• Nie wyłączaj trybu odzyskiwania. Jeśli w wp-config.php jest WP_DISABLE_FATAL_ERROR_HANDLER ustawione na true, a nie jesteś programistą testującym kod, usuń tę linię. Wtedy zamiast białego ekranu zobaczysz komunikat i dostaniesz e-mail z nazwą winnej wtyczki.
• Edytuj kod motywu tylko w motywie potomnym i nigdy przez edytor plików w panelu na działającej stronie. Literówka w edytorze panelu potrafi odciąć dostęp do panelu.
• Kopia przed każdą zmianą i aktualizacje po kolei. Zobacz Aktualizacje WordPressa i wtyczek.
• Monitoring dostępności, który sprawdza nie tylko, czy serwer odpowiada, ale też czy na stronie jest konkretne słowo (np. nazwa firmy). Biały ekran zwraca często kod 200 „OK”, więc prosty monitoring go nie zauważy.
• Aktualne PHP i rozsądny limit pamięci ustawione w panelu hostingu.

Źródła

• WordPress Developer Resources: Debugging in WordPress (WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY) (dostęp: 10.11.2026)
• WordPress Developer Resources: Editing wp-config.php (WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT, WP_DISABLE_FATAL_ERROR_HANDLER) (dostęp: 10.11.2026)
• WordPress.org Documentation: Common WordPress Errors (sekcja „The White Screen of Death”) (dostęp: 10.11.2026)
• Make WordPress Core: Fatal Error Recovery Mode in 5.2 (dostęp: 10.11.2026)
• PHP Manual: memory_limit (dostęp: 10.11.2026)