Белый экран смерти WordPress: 9 причин и решения

Белый экран смерти (WSOD, white screen of death) — это когда вместо сайта открывается абсолютно пустая страница: ни текста, ни ошибки, ни вёрстки. PHP-код упал или молча завершился, а вывод ошибок на экран выключен — поэтому вы видите ничего.

Хорошая новость: белый экран почти всегда лечится без потери данных. Алгоритм тот же, что и у любой фатальной ошибки: включить лог, найти причину, отключить сбойный код. Первым делом сделайте две вещи: проверьте почту администратора (WordPress мог прислать письмо со ссылкой на режим восстановления) и включите запись ошибок в лог — об этом ниже.

В этой статье — 9 причин белого экрана, от самых частых к редким, и решение для каждой. Если вместо пустой страницы вы видите сообщение «На сайте возникла критическая ошибка» — это соседний случай, для него есть отдельная инструкция.

Сначала — включите свет: WP_DEBUG

Диагностировать белый экран вслепую бессмысленно. Откройте wp-config.php по FTP и включите лог ошибок:

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

Обновите страницу и посмотрите файл wp-content/debug.log — последняя строка PHP Fatal error назовёт файл-виновник. Если лог пуст, а экран всё ещё белый, — ошибка происходит до того, как WordPress успевает загрузиться (причины 6–9 ниже), тогда смотрите error_log самого хостинга в панели управления.

Теперь — по причинам.

Причина 1. Конфликт или баг плагина

Самая частая причина. Плагин обновился и сломался, конфликтует с другим плагином или с новой версией WordPress.

Решение. Если админка открывается — деактивируйте плагины по половинам: отключите половину, проверьте сайт, сузьте круг. Если админки нет — по FTP переименуйте папку wp-content/plugins в plugins.off. Сайт ожил — виноват один из плагинов. Верните имя папки и включайте плагины по одному. Через WP-CLI ещё быстрее:

wp plugin deactivate --all
wp plugin activate имя-плагина   # включать по одному

Причина 2. Ошибка в теме

Вторая по частоте. Обычно ломается functions.php после ручной правки: лишняя скобка, забытая точка с запятой, вставленный из интернета сниппет под старую версию PHP.

Решение. Переключитесь на стандартную тему: «Внешний вид» → «Темы», либо wp theme activate twentytwentyfive, либо переименуйте папку темы по FTP. Заработало — откатывайте последнюю правку файлов темы или восстанавливайте тему из бэкапа.

Причина 3. Исчерпан лимит памяти PHP

В логе это выглядит как Allowed memory size of N bytes exhausted. Тяжёлый плагин, большой импорт, генерация изображений — и PHP упирается в потолок.

Решение. Поднимите лимит в wp-config.php:

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

Если не помогло — лимит зажат на уровне хостинга: поднимите memory_limit в панели или напишите в поддержку. И задумайтесь, что именно ест память: постоянные упоры в лимит — симптом прожорливого плагина.

Причина 4. Несовместимость с версией PHP

Хостинг обновил PHP (или вы сами переключили версию), а старый плагин или тема используют функции, которых больше нет. В логе — Call to undefined function или Uncaught Error.

Решение. Временно откатите версию PHP в панели хостинга на предыдущую — сайт оживёт. Затем по debug.log найдите несовместимый код, обновите или замените его и снова поднимите PHP. Оставаться на старых версиях PHP надолго не стоит: это и дыра в безопасности, и потеря скорости.

Причина 5. Оборвавшееся обновление

Обновление ядра, плагина или темы прервалось — по таймауту, из-за обрыва связи, из-за переполненного диска. Файлы залились наполовину.

Решение. Проверьте, нет ли в корне сайта файла .maintenance, — если обновление зависло на середине, удалите этот файл. Затем переустановите то, что обновлялось: плагин — удалить папку и поставить заново, ядро — «Обновления» → «Переустановить» (контент не пострадает) или через WP-CLI:

wp core download --force --skip-content

Причина 6. Синтаксическая ошибка в wp-config.php

Правили конфиг, вставили строку не туда, потеряли кавычку — и PHP падает раньше, чем WordPress вообще запустится. В debug.log такая ошибка не попадёт: лог ещё не включился.

Решение. Откройте wp-config.php и проверьте последние правки. Ошибку покажет error_log хостинга — строка syntax error, unexpected ... с номером строки. Проверить файл можно и без сервера, если есть SSH: php -l wp-config.php.

Причина 7. Повреждённые файлы ядра

Сбой диска, кривая миграция, вредоносный код — файлы wp-includes/ и wp-admin/ повреждены или подменены.

Решение. Скачайте с wordpress.org тот же выпуск WordPress и залейте поверх папки wp-includes/, wp-admin/ и файлы в корне (кроме wp-config.php). Папку wp-content не трогайте — там темы, плагины и загрузки. Через WP-CLI: wp core download --force --skip-content. Если подозреваете взлом — после восстановления обязательно смените пароли и проверьте сайт сканером.

Причина 8. Агрессивное кеширование

Сайт давно починен, а вы всё ещё видите белый экран: страница-пустышка закешировалась — в плагине кеширования, на уровне сервера или в CDN.

Решение. Откройте сайт в приватном окне. Очистите кеш плагина (или удалите содержимое wp-content/cache/ по FTP), сбросьте серверный кеш в панели хостинга и кеш CDN, если он есть. Про то, как настроить кеширование, чтобы оно ускоряло, а не мешало, — в чек-листе по ускорению WordPress.

Причина 9. Проблемы на стороне сервера

PHP-FPM упал, кончилось место на диске, хостинг ограничил процессы — WordPress тут ни при чём. Косвенный признак: белый экран отдаётся мгновенно или сайт ведёт себя нестабильно (то работает, то нет).

Решение. Проверьте место на диске и лог ошибок сервера в панели хостинга. Если своих инструментов нет — пишите в поддержку. Серверные ошибки чаще проявляются как HTTP 500 — разбор этого случая в статье про ошибку 500.

Если белый экран только на одной странице

Отдельный случай: сайт работает, а пустой отдаётся одна конкретная страница или тип страниц — например, только записи блога или только страница корзины. Логика диагностики сужается. Виноват код, который выполняется именно там: шаблон этого типа страниц в теме, шорткод в контенте или плагин, работающий только на этой странице (платёжный модуль на checkout, слайдер на главной).

Проверьте по порядку: откройте страницу с включённым WP_DEBUG_LOG и посмотрите свежий фатал; временно переключите шаблон страницы в её настройках на «Шаблон по умолчанию»; уберите из контента последние добавленные блоки и шорткоды. Если пустой отдаётся страница пагинации или архив — пересохраните постоянные ссылки («Настройки» → «Постоянные ссылки» → «Сохранить»), сбитые правила перезаписи дают именно такую картину.

Диагностика за 5 минут: путь по дереву

Чтобы не перебирать все девять причин подряд, идите по короткому дереву решений:

Вопрос	Да	Нет
1. Есть письмо от WordPress на почте админа?	Идите по ссылке восстановления, отключите виновника	→ 2
2. В debug.log появился Fatal error?	Путь в ошибке: plugins/ → причина 1, themes/ → причина 2, memory exhausted → причина 3	→ 3
3. Ошибка есть в логе хостинга?	syntax error в wp-config → причина 6; ошибки PHP-FPM/диска → причина 9	→ 4
4. В приватном окне сайт работает?	Причина 8, чистите кеш	→ 5
5. Недавно было обновление или перенос?	Причины 5 и 7: .maintenance, переустановка файлов	Отключайте плагины и тему по очереди (причины 1–2)

Этот порядок закрывает подавляющее большинство случаев за один проход.

Профилактика

Белый экран — почти всегда следствие изменения: обновления, правки кода, смены PHP. Отсюда три правила. Делайте бэкап перед любым обновлением — и храните его не на том же хостинге. Правьте код не на живом сайте: тестовая копия или хотя бы локальная проверка php -l перед заливкой. Держите PHP и плагины актуальными, но обновляйте осознанно — не всё сразу в один клик, а по одному, с проверкой сайта после каждого шага.

И последнее: не выключайте WP_DEBUG_LOG навсегда после починки — точнее, выключите WP_DEBUG на проде, но запомните этот приём. Файл debug.log — первое место, куда стоит смотреть при любой странности WordPress.