Почему в WordPress появляется белый экран и как аккуратно найти причину

Белый экран WordPress — это ситуация, когда сайт, админка или отдельная страница открываются пустым белым экраном без понятного сообщения об ошибке. Для владельца это выглядит максимально тревожно: вчера сайт работал, сегодня вместо него просто пустота. Без текста, без кнопок, без объяснений. Очень минималистично. Слишком минималистично.

В WordPress такой сбой часто называют White Screen of Death. Официальная документация WordPress указывает, что белый экран может быть проявлением PHP-ошибок или ошибок базы данных, а причин у него может быть несколько: конфликты плагинов, проблемы темы, нехватка памяти, повреждённые файлы и другие технические сбои.

Главная задача в такой ситуации — не усугубить проблему. Белый экран почти никогда не стоит чинить методом «давайте обновим всё, удалим пару плагинов и посмотрим». Сначала нужно понять, где именно возникает сбой, что менялось перед этим, есть ли письмо о критической ошибке, доступны ли логи и есть ли свежий бэкап.

Как выглядит проблема

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

Иногда вместо белого экрана WordPress показывает сообщение «На сайте возникла критическая ошибка». Это близкая по смыслу ситуация: выполнение сайта прерывается из-за фатальной ошибки, но WordPress смог показать более понятное сообщение. Начиная с WordPress 5.2, появился Fatal Error Recovery Mode, который даёт администраторам шанс войти и устранить фатальную ошибку даже в случаях, где раньше сайт или админка могли быть полностью недоступны.

Что могло её вызвать

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

Вторая причина — тема или кастомный код. Ошибка в functions.php, шаблоне страницы, обработчике формы, shortcodes, ACF-выводе, хуках или подключаемом файле может положить весь сайт. Одна лишняя скобка в PHP иногда работает эффективнее любого вредителя.

Третья причина — нехватка памяти или серверные ограничения. WordPress может упереться в memory limit, лимиты процессов, проблемы PHP-FPM, базу данных, диск или настройки хостинга. Внешне это может выглядеть как белый экран, хотя причина находится не в странице, а на серверном уровне.

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

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

Что проверить безопасно

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

Дальше проверьте почту администратора сайта. При фатальных ошибках WordPress может отправить письмо с информацией о проблемном плагине или теме и ссылкой на Recovery Mode. Этот режим появился в WordPress 5.2 и позволяет администратору войти в специальный режим для устранения фатальной ошибки без прямого вмешательства в кодовую базу.

Для диагностики WordPress поддерживает WP_DEBUG. Официальная документация указывает, что WP_DEBUG_LOG сохраняет ошибки в debug.log, что полезно для просмотра notices и ошибок, которые возникают вне экрана, например при AJAX-запросах или wp-cron.

На рабочем сайте лучше не показывать ошибки посетителям, а писать их в лог:

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

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

Если сайт вообще перестал открываться и белый экран — только один из симптомов, логично связать это с материалом WordPress-сайт перестал открываться.

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

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

Не стоит править functions.php через встроенный редактор темы, если сайт уже нестабилен. Если в файле уже есть ошибка, одна дополнительная правка может закрыть доступ окончательно. Без FTP/SFTP и бэкапа это превращается в техническую рулетку, только без веселья.

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

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

Когда уже нужна техподдержка

Техподдержка нужна, если белый экран затрагивает весь сайт, не открывается админка, нет доступа к Recovery Mode, ошибка повторяется после очистки кэша, в логах есть fatal error, сайт упал после обновления или для диагностики нужны доступы к хостингу, FTP/SFTP, базе данных и серверным логам.

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

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