Wprowadzenie
Biała strona w WordPressie (często nazywana White Screen of Death) to sytuacja, w której WordPress przestaje wyświetlać treść i zostawia pusty biały ekran (czasem bez żadnego komunikatu). Najczęściej oznacza to, że strona „wysypała się” w trakcie działania: przez błąd PHP, brak pamięci, konflikt wtyczki albo problem z motywem. To nie brzmi dobrze, ale w praktyce da się to zwykle zdiagnozować w kilka minut.
W tym poradniku podejdziesz do tematu jak do szybkiej diagnozy: najpierw sprawdzisz logi i włączysz debugowanie, a potem krok po kroku zawęzisz winowajcę (bez zgadywania i bez kręcenia się w kółko). Spokojnie, każde trudniejsze pojęcie tłumaczę po ludzku i podaję konkretne kroki, które możesz wykonać nawet bez bycia „programistą”.
| Gdzie występuje „biała strona w WordPressie”? | Najczęstsza przyczyna |
| Cała strona (frontend) i panel administratora (wp-admin) też | Błąd związany z PHP: fatal error, brak pamięci |
| Cała strona (frontend), ale panel administratora (wp-admin) działa poprawnie | Błąd związany z motywem, wtyczką lub działaniem cache |
| Tylko panel administratora (wp-admin) | Błąd związany z wtyczką wpływającą na panel administratora, działaniem cache lub błąd JavaScript |
| Tylko jedna podstrona lub wpis | Błąd związany z treścią: błędnie wklejony shortcode, błąd we wklejanym kodzie PHP, błąd w ręcznym edytowaniu kodu strony, niepoprawnie zapisana strona (błąd podczas zapisu np. Elementor) |
| Tylko strona w wersji mobilnej, strona w wersji na komputer działa poprawnie | Błąd w działaniu pluginu Cache lub optymalizacji strony (minifikacja), Błąd cache po stronie hostingu lub CDN |
Biała strona w WordPressie: pierwsze kroki do poprawnej diagnozy
Jeśli panel WordPressa nie działa, przyda Ci się jedno z poniższych:
- dostęp do plików strony (będzie Ci potrzebny program do obsługi połączeń FTP/SFTP lub menedżer plików w panelu zarządzania Twojego hostingu),
- dostęp do panelu zarządzania Twojego hostingu (jeśli to umożliwia to znajdziesz tam m.in.: logi błędów, wersja PHP, limity PHP).
Biała strona w WordPressie często wynika z jednej zmiany: aktualizacji wtyczki/motywu albo wklejenia kodu do functions.php. Jeśli bezpośrednio przed wystąpieniem „WSoD” dokonywano jakichkolwiek zmian na stronie (np. instalacja nowej wtyczki, motywu, wprowadzenie zmian w kodzie, wklejenie kodu śledzącego) – to jest pierwszy trop.
Włącz diagnostykę: WP_DEBUG i log błędów
Domyślnie w WordPressie wyłączone jest tzw. „logowanie błędów”. W przypadku problemów, musisz włączyć je ręcznie w plikach WordPressa. Za pomocą programu do obsługi FTP/sFTP połącz się ze swoim hostingiem i w głównym katalogu strony poszukaj pliku wp-config.php. Otwórz wskazany plik (edytuj w programie takim jak np. Notepad++) i poszukaj linijki:
/* That's all, stop editing! */Zaraz nad nią wklej poniższy kod:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Dzięki temu, WordPress zacznie zapisywać błędy do pliku debug.log, który znajdziesz w katalogu /wp-content/. W ten sposób dowiesz się dużo więcej o tym co tak naprawdę dzieje się w środku oraz jakie są potencjalne przyczyny białego ekranu w WordPressie.
10 najczęstszych przyczyn białej strony w WordPressie
Błąd PHP: Fatal error
To sytuacja, w której WordPress próbuje wykonać fragment kodu, ale PHP przerywa działanie i „ucina” stronę do zera. W praktyce często dzieje się to po aktualizacji wtyczki, motywu albo po dodaniu własnego kodu. Problem jest o tyle podstępny, że czasem nie widzisz żadnego komunikatu, tylko pusty biały ekran w WordPressie (ponieważ strona nie wyrenderowała żadnego elementu). Najlepiej od razu zerknąć do logu błędów: jeśli zobaczysz w nim nazwę pliku wtyczki lub motywu, zwykle masz winowajcę.
Co może wskazywać na ten błąd w debug.log?
PHP Fatal error: Uncaught Error: Call to undefined function some_plugin_function() in /home/user/public_html/wp-content/plugins/nazwa-wtyczki/includes/file.php:123Jak rozwiązać PHP Fatal error?
Musisz usunąć lub cofnąć dokładnie ten fragment kodu, który powoduje błąd – inaczej WordPress zawsze będzie się „wywracał” w tym samym miejscu. Najczęściej oznacza to wyłączenie wadliwej wtyczki, zmianę motywu albo cofnięcie ostatniej zmiany w kodzie (np. w functions.php). Jeśli błąd pojawił się po aktualizacji, często pomaga przywrócenie poprzedniej wersji wtyczki/motywu albo szybka aktualizacja do poprawionej wersji.
Brak pamięci (limit PHP / WP_MEMORY_LIMIT)
WordPress działa w ramach limitu pamięci ustawionego na serwerze (przez Ciebie, lub Twojego dostawcy hostingu) – jeśli go przekroczy, może się po prostu wykrzaczyć i wyświetlić białą stronę w WordPressie. Czasem strona wraca po odświeżeniu, ale problem będzie wracał, dopóki nie zwiększysz limitu pamięci lub nie usuniesz przyczyny. W logach często widać komunikat o wyczerpaniu pamięci.
Co może wskazywać na ten błąd w debug.log?
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/user/public_html/wp-includes/class-wpdb.php on line 2345Jak rozwiązać błąd WP_MEMORY_LIMIT?
Musisz dać WordPressowi więcej zasobów albo zmniejszyć „ciężar” strony, bo inaczej za każdym razem w krytycznym momencie zabraknie pamięci. Zwykle pomaga zwiększenie limitu pamięci (w hostingu i/lub w wp-config.php), a jeśli to nie wystarcza: usunięcie wtyczki, która zużywa najwięcej RAM, ograniczenie dodatków (np. kreator stron, kopia zapasowa, optymalizacja i cache, wtyczki bezpieczeństwa) działających naraz, albo zmiana hostingu na plan z wyższymi limitami.
W wp-config.php dodaj lub zmodyfikuj poniższy kod:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');Konflikt wtyczki
Dwie wtyczki mogą robić podobne rzeczy i „wchodzić sobie w drogę”, a wtedy efekt jest losowy: od błędów w panelu po kompletnie białą stronę w WordPressie. Konflikt potrafi wywołać też pojedyncza wtyczka, która jest przestarzała lub nie pasuje do Twojej wersji PHP lub WordPressa. Najczęściej problem pojawia się tuż po aktualizacji, dlatego warto zastanowić się, co było robione przed awarią. Najszybszy test to wyłączenie wszystkich wtyczek i włączanie ich po kolei.
Co może wskazywać na ten błąd w debug.log?
PHP Fatal error: Cannot redeclare my_custom_function() (previously declared in /wp-content/plugins/wtyczka-a/inc/helpers.php:45) in /wp-content/plugins/wtyczka-b/inc/helpers.php on line 45Jak rozwiązać konflikt wtyczek?
Konflikt znika tylko wtedy, gdy usuniesz źródło problemu, czyli wyłączysz wtyczkę, która powoduje błąd lub „gryzie się” z inną. W praktyce masz trzy wyjścia:
- zostawić wyłączoną wadliwą wtyczkę,
- zamienić ją na inną o podobnym zestawie funkcji,
- jeśli jest potrzebna – zaktualizować ją / zmienić ustawienia, tak by nie dublowała funkcji (np. nie trzymać dwóch pluginów do obsługi cache naraz).
Problem z motywem
Motyw to również kod, który może posiadać błędy. Jeśli modyfikowano motyw (zwłaszcza w functions.php) albo aktualizowano motyw nadrzędny, potomny (child theme) może się „rozjechać”. Zdarza się też, że motyw ładuje funkcję lub bibliotekę, której brakuje na serwerze i strona przestaje działać. Najlepszy test diagnostyczny to chwilowe przełączenie na domyślny motyw WordPressa.
Co może wskazywać na ten błąd w debug.log?
PHP Fatal error: Uncaught Error: Call to undefined function wp_body_open() in /wp-content/themes/twoj-motyw/header.php:18Jak rozwiązać problem spowodowany przez motyw?
Jeśli winny jest motyw, to dopóki jest aktywny, WordPress będzie próbował uruchomić jego kod i dalej będzie napotykał błędy. Rozwiązaniem jest przejście na inny motyw, a potem naprawa: aktualizacja motywu, poprawienie błędnego kodu w motywie potomnym albo przywrócenie kopii plików motywu sprzed zmian. Jeśli problem wyszedł po edycji functions.php, najszybsze jest cofnięcie tej konkretnej zmiany.
Problem związany z cache
Biała strona w WordPressie może być przypadkowo zapisana w pamięci podręcznej, więc nawet po naprawie dalej ją widzisz. To szczególnie częste, gdy masz cache na kilku poziomach naraz: wtyczka cache, cache hostingu i CDN. Wtedy jedna warstwa potrafi „trzymać” starą wersję strony, mimo że WordPress już działa poprawnie.
Co może wskazywać na ten błąd w debug.log?
PHP Notice: WP_CACHE is enabled but the cache directory is not writable in /wp-content/advanced-cache.php on line 32Jak rozwiązać problem cache w WordPressie?
Jeśli problemem jest cache, to nie szukaj problemu w samym WordPressie, tylko zmuś systemy cache do pobrania nowej, poprawnej wersji strony. W praktyce trzeba wyczyścić cache (purge/clear cache) w: wtyczce cache -> następnie w hostingu -> oraz CDN (jeśli jest używany, np. CloudFlare). Jeśli biała strona wciąż wraca, ogranicz cache do jednego głównego narzędzia (np. jedna wtyczka + ewentualnie CDN), bo kilka osobnych pamięci podręcznych naraz łatwo robi bałagan.
Wklejony kod / snippet w złym miejscu
To bardzo częsta przyczyna białej strony w WordPressie u osób, które testują poradniki i dodają „własny kod”. Wystarczy literówka, brak średnika albo użycie funkcji, której nie ma w danej wersji PHP i WordPress się zatrzymuje. Jeśli biała strona pojawiła się chwilę po wklejeniu kodu, to praktycznie na pewno on jest przyczyną. Cofnięcie zmiany zwykle od razu przywraca stronę.
Co może wskazywać na ten błąd w debug.log?
PHP Parse error: syntax error, unexpected 'return' (T_RETURN) in /wp-content/themes/twoj-motyw/functions.php on line 217Jak rozwiązać problem z własnym kodem (snippet)?
Tu nie ma „obejścia” – WordPress nie przejdzie dalej, dopóki błędny kod istnieje. Trzeba usunąć snippet albo przywrócić poprzednią wersję pliku. Jeśli chcesz zachować funkcję, zrób to bezpiecznie: testuj kod na witrynie deweloperskiej, dodawaj go przez motyw potomny (child theme) lub wtyczkę snippets, ale z możliwością szybkiego wyłączenia, i unikaj wklejek „w ciemno” bez sprawdzenia zgodności z Twoją wersją PHP.
Niekompatybilność wersji PHP
Czasem problem białej strony w WordPressie zaczyna się po zmianie wersji PHP w hostingu. Stare wtyczki mogą nie wspierać nowszego PHP, a nowe wtyczki mogą wymagać nowszego PHP niż masz ustawione. W logach często widać, że brakuje funkcji albo coś jest „nieobsługiwane”.
Co może wskazywać na ten błąd w debug.log?
PHP Fatal error: Uncaught Error: Call to undefined function mysql_connect() in /wp-content/plugins/stara-wtyczka/db.php:12Jak rozwiązać problem z niekompatybilną wersją PHP?
Musisz doprowadzić do sytuacji, w której PHP, WordPress i wtyczki mówią tym samym językiem. Jeśli po podniesieniu PHP strona padła, tymczasowo cofnij wersję PHP i zaktualizuj problematyczne wtyczki/motyw. Jeśli masz za stare PHP – podnieś je, ale równocześnie aktualizuj wtyczki i motyw do wersji zgodnych (czasem jedna wtyczka blokuje cały upgrade). Wybranie nowszej wersji PHP jest zwykle możliwe w panelu zarządzania Twojego hostingu.
Problem z plikami: uprawnienia / brak pliku / uszkodzone aktualizacje
Jeśli aktualizacja przerwała się w połowie, możesz zostać z niekompletnym zestawem plików. Zdarza się też, że uprawnienia są ustawione tak, że serwer nie może czegoś odczytać, co kończy się błędami. Taki problem potrafi pojawić się „sam”, bo zmiana zaszła na serwerze albo w automatycznej aktualizacji. Objawy bywają różne, ale biała strona to jeden z nich.
Co może wskazywać na ten błąd w debug.log?
PHP Warning: require_once(/wp-includes/some-file.php): failed to open stream: No such file or directory in /wp-settings.php on line 110Jak rozwiązać problem z plikami w WordPressie?
WordPress potrzebuje kompletu plików i poprawnych uprawnień, inaczej nie ma z czego się uruchomić. Najszybciej naprawisz to przez przywrócenie kopii zapasowej (gdy problem powstał nagle) albo ponowne wgranie plików WordPressa (bez ruszania /wp-content/). Jeśli winne są uprawnienia, ustaw standardowe wartości po stronie hostingu albo poproś support o korektę uprawnień plików.
Uszkodzony .htaccess lub reguły przekierowań
Plik .htaccess steruje m.in. przekierowaniami i tym, jak serwer obsługuje linki WordPressa. Jeśli wtyczka SEO/caching dodała tam błędne reguły, serwer może zwracać pustą odpowiedź lub zapętlać żądania. Po migracjach domeny i zmianach struktur URL to też częsty problem, bo stare reguły zostają.
Co może wskazywać na ten błąd w debug.log?
PHP Warning: Cannot modify header information - headers already sent by (output started at /wp-content/plugins/wtyczka-seo/redirects.php:88) in /wp-includes/pluggable.php on line 1416Jak rozwiązać problem z .htaccess?
Jeśli .htaccess jest wadliwy, musisz przywrócić poprawne reguły, inaczej serwer dalej będzie „źle prowadził” ruch na stronie. Najczęściej działa: usunąć/odtworzyć .htaccess (z domyślnymi regułami WordPressa) i dopiero potem dodać ewentualne przekierowania na czysto. Jeśli masz dużo reguł, dodawaj je etapami – wtedy łatwo złapać tę jedną, która psuje wszystko. Plik .htaccess znajdziesz w folderze głównym na serwerze, w którym zainstalowany jest WordPress.
Zbyt agresywna optymalizacja (minifikacja, łączenie plików, „opóźnianie” JS)
Tu często wygląda to jak biała strona w WordPressie, ale w praktyce strona nie renderuje się „do końca”, bo przeglądarka napotyka na błąd JavaScript. Dzieje się tak, gdy wtyczka optymalizacyjna zbyt mocno miesza w plikach: łączy je, minifikuje, opóźnia ładowanie lub usuwa coś, co było potrzebne. Na stronach z builderami (np. Elementor) to szczególnie częste, bo jest dużo zależności między skryptami.
Co może wskazywać na ten błąd w debug.log?
PHP Warning: include(/wp-content/cache/min/abcd1234.min.php): failed to open stream: Permission denied in /wp-content/plugins/optymalizator/minify.php on line 301Jak rozwiązać problem z optymalizacją?
Musisz znaleźć ustawienie, które psuje stronę i je złagodzić, zamiast „optymalizować na siłę”. Najczęściej działa: wyłączyć łączenie plików, wyłączyć opóźnianie JS i zostawić tylko bezpieczne opcje (np. cache + kompresja). Potem możesz dodać wyjątki (exclude) dla skryptów Elementora lub innych krytycznych wtyczek, żeby optymalizacja była szybka, ale nie destrukcyjna.


