«Белый экран смерти» в WordPress: разбираемся по-порядку

«Белый экран смерти» — это фатальная ошибка PHP, которую вы не видите. WordPress наткнулся на неустранимую ошибку прямо во время рендеринга, PHP остановился, и, поскольку на боевых серверах вывод ошибок отключён, вместо причины страница вернулась пустой. Чинить это почти никогда не приходится наугад: включите журнал отладки, откройте wp-content/debug.log и прочитайте последнюю строку с fatal-ошибкой. Она называет конкретный файл — почти всегда это плагин или тема — и вся починка сводится к этой одной строке.

Почему экран пустой

В PHP есть настройка display_errors. На машине разработчика она обычно включена, поэтому фатальная ошибка выводит на экран трассировку стека. На реальном хостинге она по умолчанию выключена, потому что утечка путей к файлам и текстов ошибок к посетителям — это дыра в безопасности. Поэтому, когда что-то выбрасывает фатальную ошибку — вызов функции, которой больше нет, класс, который не загружен, синтаксическая ошибка в обновлении плагина, — PHP умирает и не отправляет ничего. Браузер отрисовывает пустой документ. Это и есть «белый экран».

Начиная с WordPress 5.2 есть обработчик фатальных ошибок (WP_Fatal_Error_Handler), который пытается их перехватывать. Когда он срабатывает, вы получаете не пустую страницу, а сообщение «На сайте возникла критическая ошибка», плюс письмо на адрес администратора, в котором часто есть сам текст ошибки и ссылка на режим восстановления (Recovery Mode). По-настоящему пустой экран обычно означает, что ошибка сработала раньше, чем обработчик успел запуститься: ошибка парсинга/синтаксиса (ловится на этапе компиляции), сломанный must-use-плагин или фатальная ошибка в functions.php активной темы. В любом случае причина где-то записана. Нужно лишь включить эту запись.

Чиним по порядку

1. Включите журнал. Отредактируйте wp-config.php по SFTP и добавьте это выше строки /* That's all, stop editing! */:

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

WP_DEBUG_DISPLAY со значением false не пускает ошибки на публичную страницу, а WP_DEBUG_LOG пишет их в wp-content/debug.log. Перезагрузите сломанную страницу один раз, чтобы сгенерировать свежую запись.

2. Прочитайте последнюю fatal-ошибку. Откройте wp-content/debug.log и посмотрите в самый низ:

tail -n 30 wp-content/debug.log

Вы ищете строку вроде такой:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

Путь называет виновника: plugins/some-addon. Это и есть ответ. Если трассировка длинная, а сообщение непонятное (Allowed memory size exhausted, Cannot redeclare, незнакомое имя класса), вставьте её в наш декодер журнала ошибок — он убирает шум, показывает, на какой плагин или тему указывает путь, и объясняет, что означает конкретный тип ошибки.

3. Отключите названный компонент. До /wp-admin вам не добраться, поэтому делаем это по SFTP. Переименуйте папку проблемного плагина, например some-addon → some-addon.off. WordPress не может загрузить папку, которую не находит, поэтому плагин деактивируется и сайт возвращается к жизни. Если журнал указывает на тему, переключитесь на стандартную тему, переименовав папку активной темы — WordPress откатится на встроенную twentytwentysomething.

4. Если журнал не пишется, значит либо wp-content недоступен для записи, либо ошибка на уровне сервера. Тогда проверьте PHP-лог ошибок самого хостинга:

find . -name "error_log" -newermt "-1 hour"

Та же информация, только в другом файле. На связках cPanel/Apache файл error_log часто оказывается в корне сайта или в проблемном каталоге.

Чего делать не стоит

Не поднимайте просто так лимит памяти. Самый заезженный совет в интернете — увеличить WP_MEMORY_LIMIT до 256M или 512M. Это лечит WSOD только в том случае, если в журнале действительно написано Allowed memory size of N bytes exhausted. Если ошибка — Call to undefined function, то дополнительная память ничего не даст: вы наугад поменяли настройку, а экран всё так же белый. Сначала прочитайте журнал, и только потом поднимайте память, если проблема действительно в памяти.

Не чистите кеш, выдавая это за диагностику. Белый экран — это когда PHP умирает на сервере ещё до того, как появится хоть какой-то HTML. Устаревший закешированный ресурс не может привести к пустому документу. (А вот сломанный плагин кеширования может — но журнал его назовёт, в чём и весь смысл.)

Не редактируйте и не переустанавливайте ядро WordPress. Фатальная ошибка почти никогда не в wp-includes или wp-admin; она в том плагине или теме, на которые указывает журнал. Переустановка ядра — это долго, рискованно и лечит симптом, который вы даже не подтвердили.

Не отключайте все плагины, чтобы потом вслепую включать их по одному. Метод деления пополам работает, но это долгий путь. Журнал показывает точную папку за один шаг. Хватайтесь за метод «выключить всё» только тогда, когда вообще нет читаемой ошибки.

Не оставляйте display_errors включённым на боевом сайте. Как только сайт вернётся к жизни, удалите отладочные define (или верните WP_DEBUG в false). Ошибки, выведенные посетителям, раскрывают ваши пути.

Всё ещё не выходит?

Если журнал называет плагин, но его отключение не убирает экран, значит под первой ошибкой прячется вторая — снова включите журнал и прочитайте новую последнюю строку; fatal-ошибки идут стопкой. Если стеной стоит само сообщение, забросьте его в декодер журнала ошибок и дайте ему перевести тип ошибки и путь к файлу за вас. Белый экран остаётся загадкой лишь до тех пор, пока журнал выключен.