WordPress: белый экран смерти — причины и решение

MAATRIX

Открываете сайт — пустая белая страница без единого сообщения: WordPress белый экран смерти (WSOD). Пугает то, что нет никакой подсказки, но причина почти всегда конкретна: фатальная ошибка PHP из-за плагина или темы, нехватка памяти или повреждённый файл. Белый экран — это скрытая ошибка, и первый шаг всегда один: сделать её видимой. Разберём, как за несколько минут найти причину и вернуть сайт.

Первое действие: включите отладку и посмотрите ошибку

Белый экран означает, что PHP упал с фатальной ошибкой, но её вывод скрыт. Включите режим отладки, чтобы увидеть, что именно сломалось. В файле wp-config.php найдите строку про WP_DEBUG и включите логирование:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Теперь ошибки пишутся в файл wp-content/debug.log. Обновите страницу сайта и посмотрите последние строки лога:

tail -n 30 wp-content/debug.log

Там будет прямая причина: Fatal error с именем файла и строкой — почти всегда это конкретный плагин или тема. Это ключ ко всему: белый экран сам по себе не диагноз, а вот запись в логе указывает виновника точно. Если доступа к файлам нет, ту же ошибку можно найти в логе ошибок PHP или веб-сервера (error.log). Сделав ошибку видимой, вы превращаете загадочный белый экран в понятную задачу.

Причина 1: сбойный плагин

Самая частая причина WSOD — конфликт или ошибка в плагине, особенно после обновления или установки нового. Лог обычно прямо указывает на файл в wp-content/plugins/название/. Если админка тоже недоступна (белый экран и там), отключите плагины через файловую систему: переименуйте папку плагинов, и WordPress деактивирует их все разом:

mv wp-content/plugins wp-content/plugins_off

Если сайт ожил — виноват один из плагинов. Верните папку на место и отключайте плагины по одному (переименовывая их подпапки), пока не найдёте сбойный. Найдя виновника, обновите его, замените аналогом или удалите. Если админка работает, проще деактивировать плагины из неё. Плагин, сломавшийся после обновления, — классика WSOD: разработчик выпустил несовместимую версию или возник конфликт с другим плагином. Метод перебора надёжно вычисляет виновника за несколько минут.

Причина 2: сбойная или несовместимая тема

Если плагины ни при чём, следующий подозреваемый — активная тема, особенно после её обновления или правки functions.php. Ошибка в логе будет указывать на файл в wp-content/themes/название/. Чтобы проверить тему, переключитесь на стандартную. Если админка недоступна, это можно сделать, временно убрав папку текущей темы, — WordPress откатится на дефолтную:

mv wp-content/themes/моя-тема wp-content/themes/моя-tema_off

Если после этого сайт заработал на стандартной теме — проблема в вашей. Частый случай — неудачная правка functions.php: лишний символ или несовместимый код валит весь сайт. Восстановите файл из бэкапа или исправьте ошибку, на которую указывает лог. Никогда не редактируйте functions.php темы напрямую на боевом сайте без копии — одна опечатка кладёт всё. Используйте дочернюю тему и правьте с бэкапом. Переключение на стандартную тему быстро подтверждает или снимает подозрение с темы.

Причина 3: нехватка памяти PHP

WSOD часто вызывает исчерпание лимита памяти PHP: тяжёлый плагин или страница требуют больше, чем разрешено, и PHP падает. В логе это Allowed memory size of ... bytes exhausted. Увеличьте лимит памяти для WordPress в wp-config.php:

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

Если этого мало или не применяется, поднимите memory_limit на уровне PHP в конфиге PHP-FPM или .htaccess/.user.ini. Дефолтные 128 МБ или меньше часто не хватает современному WordPress с набором плагинов и конструктором страниц. После правки перезапустите PHP-FPM. Важно понимать: постоянная нехватка памяти — это ещё и сигнал, что либо сайт перегружен плагинами, либо сервер маловат под задачу. Поднять лимит — быстрое лечение, но если сайт упирается в память регулярно, стоит либо разгрузить его, либо добавить ресурсов серверу. Память — частая скрытая причина белого экрана.

Причина 4: повреждённый файл ядра

Реже белый экран вызывает повреждённый или неполный файл ядра WordPress — после сбойного обновления, обрыва загрузки или заражения. Лог может указывать на файл в корне или в wp-includes/wp-admin. Самый чистый способ восстановить ядро — переустановить его файлы поверх, не трогая контент и базу. Скачайте свежую копию WordPress и замените файлы ядра:

wp core download --force

Команда WP-CLI перезапишет файлы ядра актуальными, не затрагивая ваши wp-content и настройки. Без WP-CLI можно вручную заменить папки wp-admin и wp-includes из свежего архива WordPress — их замена безопасна, так как там нет вашего контента. Не трогайте при этом wp-content (темы, плагины, загрузки) и wp-config.php. Восстановление ядра лечит WSOD, вызванный битыми системными файлами, и заодно устраняет часть последствий сбойных обновлений. Если причиной было заражение — отдельно займитесь безопасностью после восстановления.

Как быстро понять источник, если лог недоступен

Если по каким-то причинам лог получить не удаётся, используйте метод исключения по приоритету частоты. Сначала отключите все плагины (переименовав папку plugins) — это снимает самую частую причину. Не помогло — переключитесь на стандартную тему. Всё ещё белый экран — поднимите лимит памяти PHP. Не помогло — восстановите файлы ядра. Этот порядок отражает, как часто встречается каждая причина, и обычно виновник находится на первом-втором шаге.

Параллельно всегда полезно заглянуть в лог ошибок веб-сервера и PHP на самом сервере — даже когда debug.log WordPress недоступен, фатальная ошибка PHP почти наверняка записана в системный error.log. Доступ по SSH к серверу здесь бесценен: он позволяет и читать логи, и переименовывать папки, и восстанавливать файлы, когда админка мертва. Именно поэтому WordPress на своём VPS с полным доступом чинится куда быстрее, чем на ограниченном хостинге, где до логов и файлов не добраться.

Профилактика: чтобы белый экран не повторялся

Большинство случаев WSOD предотвращаются дисциплиной. Не обновляйте плагины и тему пачкой на боевом сайте без бэкапа — делайте копию перед обновлением, чтобы откат занимал минуту. Держите тестовую копию сайта, где проверяете обновления перед переносом на прод. Не редактируйте functions.php напрямую — используйте дочернюю тему и правьте с бэкапом. Задайте WordPress достаточный лимит памяти сразу, чтобы не упираться в него на пике.

Настройте регулярные автоматические бэкапы файлов и базы, лежащие отдельно от сервера, — тогда любой белый экран лечится откатом за минуты, даже если причину искать некогда. Держите включённым логирование ошибок в файл (WP_DEBUG_LOG), но с выключенным выводом на экран (WP_DEBUG_DISPLAY в false), чтобы посетители не видели ошибок, а вы могли их читать. Эти простые меры превращают пугающий белый экран смерти в редкую и быстро устранимую неприятность.

Частые вопросы