Белый экран смерти в WordPress обычно означает не «поломку сайта целиком», а фатальную ошибку PHP, нехватку памяти, конфликт плагина или темы, либо проблему на уровне сервера. Снаружи это выглядит одинаково: вместо страницы — пустой белый экран, иногда только в админке, иногда только на части страниц. Задача здесь не гадать, а быстро сузить круг причин и вернуть доступ к сайту.
Ниже — рабочий порядок проверки. Он рассчитан на ситуацию, когда сайт уже не открывается нормально, поэтому сначала идут действия, которые можно сделать даже без входа в админку.
С чего начать: понять, где именно пустая страница
Сначала проверьте, где проявляется проблема:
- только на главной странице;
- только в админке;
- на всех страницах сайта;
- только после обновления плагина, темы или WordPress;
- только у части пользователей или в определённом браузере.
Если белый экран виден только на одной странице, причина часто в шаблоне, шорткоде или конкретном плагине, который подключается именно там. Если пустая страница везде, чаще всего виноваты PHP-ошибка, память, автозагрузка плагинов или тема.
Перед любыми изменениями сделайте резервную копию файлов и базы данных, если есть доступ к хостингу. Некоторые шаги ниже безопасны, но при ручном отключении плагинов и правке конфигурации можно потерять текущие настройки или временно усугубить проблему.
Включите журнал ошибок, а не догадки
Самый полезный шаг — посмотреть, что именно падает. В WordPress это делается через режим отладки. Если у вас есть доступ к файлам сайта, откройте wp-config.php и добавьте или измените такие строки перед комментарием /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );После этого обновите проблемную страницу и проверьте файл wp-content/debug.log. Если там появляется сообщение о фатальной ошибке, оно обычно сразу указывает на плагин, тему, файл или функцию, которые ломают загрузку.
Если сайт уже работает на продакшене, не оставляйте вывод ошибок на экран. Значение WP_DEBUG_DISPLAY должно оставаться false, чтобы посетители не видели технические сообщения.
Чаще всего виноват плагин
Если белый экран появился после установки, обновления или активации плагина, начните с него. Когда админка недоступна, плагины отключают вручную через файловый менеджер или FTP.
Откройте папку wp-content/plugins и временно переименуйте каталог проблемного плагина. Например, contact-form-7 можно переименовать в contact-form-7-off. WordPress перестанет его загружать, и вы сможете проверить, исчезла ли ошибка.
Если не знаете, какой именно плагин виноват, отключите все сразу: переименуйте папку plugins целиком, например в plugins-off. После этого сайт должен загрузиться без активных расширений. Затем верните имя папки обратно и включайте плагины по одному, пока не найдёте конфликт.
Такой способ особенно полезен, когда белый экран вызван несовместимостью версии плагина с текущей версией PHP или WordPress. На хостингах с агрессивным кэшированием иногда нужно подождать несколько минут или очистить серверный кэш, чтобы увидеть результат.
Проверьте тему, если плагины не помогли
Если отключение всех плагинов не изменило ситуацию, проблема может быть в теме. Это типично после обновления шаблона, установки дочерней темы или ручного редактирования файлов.
Самый простой способ проверки — временно переключиться на стандартную тему WordPress, например Twenty Twenty-Four или другую установленную дефолтную тему. Если админка недоступна, можно переименовать папку активной темы в wp-content/themes. WordPress попытается подхватить другую доступную тему.
Если после этого сайт открылся, значит, ошибка в теме или в её дочерней теме. В таком случае стоит проверить:
- файл
functions.phpна лишний PHP-код; - шаблоны, которые вы редактировали вручную;
- подключение сторонних библиотек и скриптов;
- совместимость темы с текущей версией PHP.
Частая ошибка — случайно удалить одну скобку, точку с запятой или PHP-тег при правке шаблона. Для WordPress это уже достаточно, чтобы получить белый экран.
Проверьте лимит памяти WordPress
Если в журнале ошибок есть сообщения о нехватке памяти, нужно увеличить лимит. Это особенно актуально для тяжёлых тем, больших магазинов, импортов и сайтов с множеством плагинов.
В wp-config.php можно попробовать добавить строку:
define( 'WP_MEMORY_LIMIT', '256M' );Но есть важный нюанс: WordPress может запросить больше памяти, чем разрешает сам PHP или хостинг. Если на сервере жёстко ограничен параметр memory_limit, правка в WordPress не поможет. Тогда лимит нужно менять в настройках PHP на стороне хостинга или через .user.ini, если это поддерживается.
Если после увеличения лимита сайт начал открываться, это не повод забыть о проблеме. Значит, какой-то плагин, запрос или шаблон расходует слишком много ресурсов, и стоит найти источник нагрузки.
Проверьте PHP-версию и совместимость
Белый экран нередко появляется после смены версии PHP на хостинге. Старый плагин или тема могут не поддерживать более новую версию PHP, а старый сайт — наоборот, ломаться на слишком старой версии.
Если ошибка началась сразу после обновления PHP, временно верните предыдущую версию через панель хостинга и проверьте сайт. Если сайт ожил, причина почти наверняка в несовместимом коде. Дальше нужно обновить тему и плагины до версий, которые поддерживают текущий PHP, а не держать сайт на устаревшей версии бесконечно.
Если хостинг позволяет, полезно посмотреть конкретное сообщение в журнале ошибок. Оно обычно точнее показывает, какой файл и какая функция не совместимы с текущим PHP.
Когда админка тоже недоступна: быстрый порядок действий
Если вы не можете войти ни на сайт, ни в /wp-admin, действуйте в таком порядке:
- Проверьте журнал ошибок WordPress или сервера.
- Отключите все плагины через переименование папки
plugins. - Если не помогло, временно переключите тему.
- Проверьте лимит памяти.
- Сверьте версию PHP с требованиями темы и плагинов.
Этот порядок удобен тем, что каждый шаг быстро отсекает целый класс причин. Не стоит сразу править десятки файлов или переустанавливать WordPress: в большинстве случаев проблема находится в одном плагине, теме или в нехватке ресурсов.
Если сайт открывается только после отключения плагинов
Когда сайт восстановился, не спешите включать всё обратно разом. Включайте плагины по одному и каждый раз проверяйте главную страницу, проблемный раздел и админку. Так вы найдёте конкретное расширение, которое вызывает белый экран.
После обнаружения виновника проверьте:
- есть ли у него обновление;
- не конфликтует ли он с другой похожей функцией;
- не требует ли он более свежую версию PHP;
- не ломает ли он страницу только при определённой настройке.
Если плагин критически важен, а обновления нет, лучше заменить его, чем держать нестабильную сборку на рабочем сайте.
Как убедиться, что проблема действительно исправлена
После изменений проверьте не только главную страницу, но и несколько разных URL: запись, страницу, архив, вход в админку, страницу редактирования записи. Белый экран может исчезнуть на главной, но остаться в другом месте, если ошибка сидела в конкретном шаблоне или хуке.
Также откройте wp-content/debug.log ещё раз. Если журнал перестал пополняться новыми фатальными ошибками, а сайт стабильно открывается после нескольких обновлений страницы, значит, вы нашли и устранили основную причину.
Если проблема возвращается после очистки кэша или через некоторое время, проверьте серверный кэш, CDN и автоматические задания, которые могут снова подсовывать старую версию страницы. Но в первую очередь всё равно ищите первопричину в плагине, теме или PHP-ошибке.
Когда уже нужен хостинг или разработчик
Если в журнале ошибок фигурируют системные ограничения, недоступные файлы, проблемы с правами доступа, сбои на уровне PHP-FPM или повторяющиеся фатальные ошибки в ядре, без доступа к панели хостинга или разработчика не обойтись. Это уже не типичный случай «переименовать плагин и всё заработало».
Но даже в таких ситуациях лог ошибок обычно экономит много времени: вместо долгого перебора вы сразу видите, что именно сломалось и на каком уровне — в плагине, теме, PHP или конфигурации сервера.