Белый экран WordPress: как найти причину и вернуть сайт

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

Поэтому правильная стратегия — не перебирать исправления вслепую, а сначала получить технический сигнал: письмо Recovery Mode, Fatal error в журнале PHP или запись в debug.log.

Чем раньше найден конкретный файл и текст ошибки, тем меньше действий придётся делать на рабочем сайте.

Сначала определите масштаб белого экрана

Перед изменением файлов проверьте, где именно возникает сбой.

Белая страница на всём сайте и белая страница только при открытии одной записи — разные ситуации. То же самое относится к варианту, когда публичная часть работает, а /wp-admin/ перестал открываться.

Симптом	С чего начинать
Не открывается весь сайт	Recovery Mode, PHP error log, последние изменения
Фронтенд работает, админка белая	плагины админки, PHP-ошибка, память, серверный лог
Админка работает, сайт белый	активная тема, шаблоны, фронтенд-плагины, кэш
Не открывается одна страница	шаблон, shortcode, блок, запрос, данные этой страницы
Ошибка появилась после обновления	компонент, который обновлялся, совместимость PHP
Ошибка появилась после правки PHP	изменённый файл и синтаксис
Сбой появляется периодически	память, PHP-FPM, база, нагрузка, внешние сервисы

Если проблема воспроизводится только в одном браузере, сначала исключите локальный кэш и расширения браузера. Но если тот же URL не открывается с другого устройства или соединения, переходите к серверной диагностике.

Не нужно на этом этапе обновлять WordPress, менять версию PHP, удалять плагины или восстанавливать бэкап. Сначала важно сохранить исходное состояние и понять, что изменилось непосредственно перед сбоем.

Белый экран WordPress и Recovery Mode

Начиная с WordPress 5.2 ядро содержит Recovery Mode — режим восстановления для части фатальных PHP-ошибок.

Если WordPress перехватывает подходящую фатальную ошибку при обычной загрузке страницы, посетителю вместо прежнего полностью белого экрана может показываться сообщение о критической ошибке. На административный email сайта одновременно отправляется письмо со специальной ссылкой.

В Recovery Mode проблемный плагин или тема приостанавливаются только для административной сессии восстановления. Это позволяет войти в панель и посмотреть, какой компонент вызвал ошибку, не переименовывая сразу каталоги через файловый менеджер.

Если письмо пришло, сначала используйте этот путь.

Проверьте указанное расширение или тему, последние изменения и совместимость. Если проблема началась сразу после обновления конкретного плагина и Recovery Mode указывает на файл именно этого плагина, связь уже намного сильнее, чем догадка «наверное, конфликт расширений».

Но Recovery Mode срабатывает не для любого возможного сбоя. Например, документация WordPress отдельно отмечает обычную загрузку страницы, а не cron и фоновые задачи. Письмо также может не дойти из-за настроек исходящей почты сервера.

Отсутствие письма поэтому не завершает диагностику — следующим источником становится журнал ошибок.

Как безопасно получить ошибку через WP_DEBUG

WordPress имеет встроенные константы диагностики, но на рабочем сайте важно разделять запись ошибки в лог и показ ошибки посетителю.

Если серверный PHP error log недоступен, временно можно настроить WordPress так:

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

Эти строки размещаются в wp-config.php до комментария:

/* That's all, stop editing! Happy blogging. */

При WP_DEBUG_LOG ошибки обычно записываются в:

/wp-content/debug.log

После включения откройте URL, на котором появляется белый экран, чтобы снова воспроизвести ошибку. Затем сразу изучите свежие записи журнала.

Не пытайтесь исправить каждое Notice, Warning или сообщение о deprecated-функции. Для аварии прежде всего ищите запись, совпадающую по времени со сбоем и содержащую признаки остановки выполнения — например PHP Fatal error, Uncaught Error, Allowed memory size exhausted или конкретный проблемный файл.

На production-сайте отладку не стоит оставлять включённой постоянно. Официальная документация WordPress рекомендует инструменты debug прежде всего для разработки и staging. После диагностики временные настройки нужно вернуть в обычное состояние, а лог не оставлять доступным из интернета.

Как читать запись Fatal error

Предположим, журнал содержит строку примерно такого типа:

PHP Fatal error: Uncaught Error: Call to undefined function ...
in /wp-content/plugins/example-plugin/includes/file.php on line ...

Для первичной диагностики здесь важны не все технические детали сразу.

Сначала смотрите на тип ошибки. Fatal error или Uncaught Error объясняет, почему выполнение страницы остановилось.

Затем — на путь к файлу. Если он ведёт в:

/wp-content/plugins/

первым подозреваемым становится конкретный плагин.

Если путь ведёт в:

/wp-content/themes/

проверяется активная тема, дочерняя тема или связанный с ней кастомный код.

Если журнал сообщает:

Allowed memory size ... exhausted

это уже отдельный сценарий: PHP-процесс достиг разрешённого лимита памяти. В таком случае нужно выяснить, почему память закончилась, а не просто предположить конфликт темы.

Если первые строки указывают на файл ядра WordPress, это ещё не доказывает, что сломано именно ядро. Ошибка могла попасть туда через вызов плагина или темы, поэтому нужно смотреть полный stack trace и контекст.

Если виноват плагин

Если Recovery Mode или лог уже указал на конкретный плагин, начинайте с него.

При доступной админке временно деактивируйте расширение и снова откройте проблемный URL. Если сайт загрузился, источник локализован.

Это ещё не всегда означает, что сам плагин написан неправильно. Причиной может быть его несовместимость с версией PHP, другим расширением, темой или вашим кастомным кодом. Но область поиска уже существенно сужена.

Если /wp-admin/ недоступен, а доступ к файлам есть, каталог конкретного плагина можно временно переименовать через SFTP или файловый менеджер.

Когда конкретный источник неизвестен, WordPress также документирует способ деактивации всех обычных плагинов: переименовать каталог

/wp-content/plugins/

например в:

/wp-content/plugins.hold/

После восстановления доступа каталог возвращают к исходному имени, а расширения включают по одному.

На коммерческом сайте это не первый, а аварийный диагностический вариант. Одновременное отключение всех плагинов может выключить формы, магазин, оплату, интеграции, кэш и другие функции. Если лог уже показывает конкретный компонент, массовое отключение избыточно.

При наличии SSH и WP-CLI плагины также можно деактивировать командой:

wp plugin deactivate plugin-slug

или, когда действительно требуется проверить весь набор:

wp plugin deactivate --all

Если причина в теме

Проверка темы строится по тому же принципу.

Если ошибка появилась сразу после изменения functions.php, шаблона или дочерней темы, сначала откатывается именно это изменение.

Если админка доступна, временно переключитесь на совместимую стандартную тему WordPress и проверьте проблемную страницу.

Если после переключения белый экран исчез, проблема связана с активной темой или её взаимодействием с другими компонентами.

При недоступной админке WordPress допускает диагностику через файловую систему — переименование каталога активной темы. Но прежде чем делать это на рабочем сайте, убедитесь, что установлена другая работоспособная тема, на которую WordPress сможет переключиться.

Особенно внимательно проверяйте кастомные functions.php, подключаемые PHP-файлы и сниппеты. Одна синтаксическая ошибка способна остановить загрузку ещё до того, как WordPress успеет нормально сформировать страницу.

Белый экран WordPress после обновления: что проверить

Если проблема появилась сразу после обновления, это одна из самых полезных диагностических привязок.

Сначала зафиксируйте, что именно обновлялось:

• ядро WordPress;
• один конкретный плагин;
• несколько плагинов;
• тема;
• версия PHP;
• серверное окружение.

Если одновременно обновлено двадцать компонентов, определить источник намного сложнее. Поэтому на рабочих проектах обновления разумнее проводить контролируемо, имея резервную копию и возможность быстро проверить сайт.

После сбоя не нажимайте «обновить всё остальное» в надежде, что следующая версия что-нибудь исправит. Сначала откройте лог.

Типичный сценарий после смены PHP — старый плагин или тема использует код, несовместимый с новой версией. После обновления расширения возможна обратная ситуация: новая версия требует более современного PHP.

Если обновление оборвалось, дополнительно проверяются целостность файлов и состояние процесса обновления. Но сообщение WordPress о режиме технического обслуживания — отдельный симптом и не должно автоматически называться White Screen of Death.

Когда проверять память

Нехватка памяти — реальная причина, но проверять её нужно по факту, а не потому, что этот совет часто встречается в инструкциях.

В логе при таком сбое обычно есть формулировка:

Allowed memory size ... exhausted

PHP-директива memory_limit ограничивает объём памяти, который может использовать скрипт. Но простое повышение значения не отвечает на вопрос, почему приложение достигло лимита.

Причиной может быть тяжёлый импорт, генерация изображения, неоптимальный запрос, рекурсивный код, конфликт расширений или действительно слишком низкое серверное ограничение.

Если сайт годами работал с текущим лимитом, а после установки одного расширения начал регулярно исчерпывать память, логичнее сначала исследовать новое расширение, а не бесконечно увеличивать лимит.

Кроме того, реальное значение может ограничиваться конфигурацией PHP или хостингом. Изменение WordPress-константы не обязательно способно превысить серверное ограничение.

Когда проблема уже не в плагине или теме

Если плагины исключены, стандартная тема не меняет поведение, а в WordPress-логе нет понятной причины, диагностика переходит на уровень сервера.

Проверьте PHP error log хостинга. Он может содержать ошибку, которая возникла раньше, чем WordPress успел запустить собственное логирование.

Дальше проверяются версия PHP, доступная память, PHP-FPM, место на диске, права на файлы, состояние базы данных и последние серверные изменения.

При ошибке базы не нужно автоматически запускать «repair» для всех таблиц. Сначала нужен конкретный MySQL/MariaDB error или другое подтверждение проблемы.

Так же осторожно нужно относиться к правам доступа. Совет выставить 777 ради проверки — плохая диагностика и ненужный риск. Права исправляют согласно конфигурации сервера, а не максимальным числом.

Что не делать при белом экране

Самая опасная стратегия — одновременно изменить несколько вещей, получить работающий сайт и так и не узнать, что именно было причиной.

Не удаляйте папки плагинов вместо временного отключения. Не правьте несколько PHP-файлов одновременно. Не переключайте PHP, тему и набор расширений одним действием.

Не включайте публичный вывод ошибок на рабочем сайте: сообщения PHP могут раскрывать абсолютные пути файлов и устройство проекта.

Не восстанавливайте старый бэкап без оценки свежих данных. На интернет-магазине или сайте с заявками откат базы на несколько дней способен вернуть страницу, но одновременно удалить новые заказы, заявки и изменения контента.

Не считайте очистку кэша универсальным ремонтом. Кэш действительно может показывать старое состояние, но он не исправит воспроизводимый Fatal error в PHP.

И главное — не лечите строку ошибки, не разобрав её причину. Например, увеличение памяти может временно убрать один симптом, но не исправит бесконечный цикл или неудачную обработку большого массива данных.

Практический сценарий: сайт побелел после обновления плагина

Допустим, коммерческий WordPress-сайт работал нормально. После обновления одного плагина фронтенд показывает критическую ошибку или белую страницу, а админка открывается нестабильно.

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

Если пришло письмо Recovery Mode и WordPress указывает на этот же плагин, заходим в режим восстановления и временно его деактивируем.

Если письма нет, смотрим PHP error log или временно включаем запись в debug.log, повторно открываем проблемную страницу и читаем свежий Fatal error.

Путь в ошибке ведёт в каталог обновлённого плагина. После его временной деактивации сайт снова открывается.

На этом аварийная часть закончена, но диагностика ещё нет. Теперь нужно понять, почему новая версия упала: несовместима с текущим PHP, конфликтует с другим компонентом, требует миграции данных или содержит собственную ошибку.

Только после этого принимается решение: обновить PHP, заменить плагин, установить исправленную версию, откатить только этот компонент или внести точечную правку.

Такой подход сохраняет намного больше информации, чем схема «вернули вчерашний бэкап — всё заработало».

Как понять, что сайт действительно восстановлен

Исчезновение белого экрана — только первая проверка.

После исправления откройте публичную часть и /wp-admin/, затем сценарий, на котором происходил сбой. Если проблема возникала при отправке формы, оформлении заказа, сохранении записи или AJAX-запросе, повторите именно это действие.

Просмотрите свежие ошибки после исправления. В журнале не должно продолжать появляться то же фатальное сообщение.

Затем очистите используемый кэш и проверьте сайт ещё раз в обычном режиме.

Если для диагностики включался WP_DEBUG, временные настройки нужно вернуть к рабочим значениям. Не оставляйте debug.log бесконтрольно на публичном сервере и не оставляйте посетителям вывод PHP-ошибок.

Для коммерческого проекта дополнительно проверьте формы, оплату, авторизацию, поиск, основные шаблоны и фоновые функции, которые могли зависеть от отключённого компонента.

Белый экран WordPress стоит считать устранённым не тогда, когда главная страница один раз открылась, а когда найдена конкретная причина, исправлен её источник и критичные сценарии снова работают без повторения ошибки.

Если проблема обнаружилась на проекте с большим количеством кастомного кода, интеграций и зависимых плагинов, при разработке WordPress-сайта важно заранее закладывать контролируемые обновления, резервирование, staging и возможность быстро локализовать ошибку. Тогда авария после обновления не превращается в перебор всех компонентов вслепую, а разбирается по конкретному изменению и журналу ошибок.