Если вместо сайта или панели администратора WordPress вы видите пустую белую страницу, почти всегда речь идёт о сбое PHP, конфликте плагина или темы, нехватке памяти или проблеме на стороне хостинга. Сам WordPress в этот момент обычно не показывает подробную ошибку, поэтому задача не в том, чтобы угадать причину, а в том, чтобы быстро вернуть доступ и последовательно сузить круг поиска.
Ниже — рабочий порядок действий: сначала восстановление доступа, затем диагностика. Такой подход удобнее, чем сразу менять всё подряд, потому что белый экран часто появляется из-за одной конкретной ошибки, а не из-за «поломки всего сайта».
С чего начать, если сайт или админка не открываются
Первое, что нужно сделать, — понять, где именно возникает проблема: на всём сайте, только в админке или только после входа в конкретный раздел. Это помогает не тратить время на лишние проверки.
- Если не открывается весь сайт, начинайте с плагинов, темы и лимита памяти.
- Если не открывается только
/wp-admin, часто виноват плагин безопасности, кэш, тема или повреждённый файл. - Если белый экран появился после обновления, в первую очередь проверяйте последний изменённый плагин, тему или версию PHP.
Если у вас есть доступ к хостингу, файловому менеджеру или FTP, этого уже достаточно, чтобы начать восстановление. Доступ к админке на этом этапе не обязателен.
Включите режим отладки и посмотрите, что именно ломается
Белый экран — это не диагноз, а симптом. Самый полезный шаг — включить логирование ошибок WordPress. Это безопаснее, чем сразу менять код наугад, и обычно быстрее всего показывает источник проблемы.
Откройте файл wp-config.php и добавьте или исправьте такие строки перед комментарием /* That's all, stop editing! Happy publishing. */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );После этого обновите страницу, где появляется белый экран, и проверьте файл wp-content/debug.log. Если лог не создаётся, значит, проблема может быть на уровне PHP или прав доступа к папке wp-content.
В логе ищите не длинные цепочки сообщений, а первую явную ошибку: Fatal error, Parse error, Allowed memory size exhausted, Call to undefined function. Именно она обычно указывает на конкретный плагин, тему или файл.
Самый быстрый способ вернуть сайт: отключить плагины
Если лог недоступен или нужно срочно поднять сайт, начните с плагинов. Это самый частый источник белого экрана после обновлений, особенно если плагин конфликтует с новой версией PHP или другим расширением.
Если вы не можете войти в админку, переименуйте папку wp-content/plugins через FTP или файловый менеджер, например в plugins-off. WordPress перестанет загружать все плагины сразу. После этого проверьте сайт.
Если сайт открылся, проблема почти наверняка в одном из плагинов. Верните папке исходное имя, затем отключайте плагины по одному уже из админки, пока не найдёте виновника. Если админка всё ещё недоступна, можно временно переименовывать папку каждого плагина внутри wp-content/plugins по очереди.
Когда сайт ожил после отключения плагинов, не спешите включать всё обратно. Сначала обновите проблемный плагин, проверьте его совместимость с вашей версией WordPress и PHP, а уже потом возвращайте в работу.
Проверьте тему оформления
Если отключение плагинов не помогло, следующий подозреваемый — тема. Особенно часто белый экран появляется после обновления темы или установки дочерней темы с ошибкой в functions.php.
Чтобы проверить это без доступа к админке, временно переключите тему на стандартную. Самый простой способ — через базу данных или переименование активной темы в папке wp-content/themes. Если у вас есть доступ к админке, можно сделать это в разделе внешнего вида. Но если админка не открывается, безопаснее использовать файловый менеджер.
Если после смены темы сайт загрузился, проблема в текущей теме или в её дочерней версии. Проверьте недавно внесённые изменения в functions.php, шаблоны и подключаемые файлы. Часто достаточно убрать одну лишнюю закрывающую скобку, неверный вызов функции или код, который не поддерживается текущей версией PHP.
Проверьте лимит памяти PHP
Белый экран нередко появляется, когда WordPress упирается в лимит памяти. Это особенно заметно на тяжёлых темах, больших магазинах, сайтах с большим количеством плагинов или при импорте данных.
Если в debug.log есть сообщение вида Allowed memory size exhausted, увеличьте лимит памяти. В wp-config.php можно добавить строку:
define( 'WP_MEMORY_LIMIT', '256M' );Но здесь есть важная оговорка: WordPress может запросить больше памяти, чем реально разрешено на хостинге. Если сервер ограничивает PHP жёстче, чем вы указали в wp-config.php, изменение не сработает. В таком случае нужно менять лимит в настройках хостинга или обращаться в поддержку.
Если после увеличения памяти сайт заработал, это не значит, что причина исчезла. Часто память заканчивается из-за конкретного плагина, кривого запроса или слишком тяжёлой темы. Стоит проверить, что именно нагружает сайт.
Ищите синтаксическую ошибку в PHP-файлах
Если белый экран появился сразу после правки кода, почти наверняка дело в синтаксической ошибке. Это может быть лишняя запятая, пропущенная кавычка, неверная скобка или вставка кода не в тот файл.
Типичные места, где ломают сайт:
functions.phpактивной темы;- файлы дочерней темы;
- кастомный плагин;
- фрагменты кода, вставленные вручную через редактор файлов.
Если ошибка синтаксическая, в логе обычно будет Parse error с указанием файла и строки. Это самый удобный сценарий: откройте указанный файл, исправьте строку и снова проверьте сайт. Если правка делалась недавно, проще всего откатить её из резервной копии или из системы контроля версий, если она у вас есть.
Не редактируйте файлы «наугад» прямо на продакшене, если не уверены в причине. Одна неверная правка может полностью закрыть доступ и к сайту, и к админке.
Проверьте PHP-версию и совместимость
После обновления WordPress, темы или плагинов белый экран может появиться из-за несовместимости с текущей версией PHP. Это особенно актуально, если хостинг недавно перевёл сайт на более новую версию PHP автоматически.
Что делать:
- Посмотрите, какая версия PHP сейчас используется на сайте в панели хостинга.
- Сравните её с требованиями темы и плагинов.
- Если сбой начался сразу после смены версии PHP, временно откатите версию на поддерживаемую и проверьте сайт.
Откат PHP — это временная мера, а не окончательное решение. Если сайт ожил на старой версии, нужно обновить проблемный плагин или тему, а не оставлять устаревший стек надолго.
Когда проблема в кэше или CDN
Иногда белый экран видит только часть посетителей, а вы сами или администраторы — нет. В таком случае причина может быть в кэше страницы, серверном кэше или CDN. Это не самый частый сценарий, но его стоит проверить, если сайт «пустой» не у всех одинаково.
Очистите кэш на стороне плагина кэширования, на хостинге и в CDN, если он подключён. После этого откройте сайт в режиме инкогнито и с отключённым кэшем браузера. Если проблема исчезла, значит, на сервере отдавалась устаревшая или повреждённая версия страницы.
Как проверить, что сайт действительно восстановлен
После исправления причины не ограничивайтесь одной загрузкой главной страницы. Проверьте несколько точек, где сбой мог проявляться по-разному:
- главную страницу сайта;
- страницу записи или страницы;
/wp-admin;- страницу входа;
- страницу, на которой раньше был белый экран.
Затем откройте wp-content/debug.log ещё раз. Если ошибки продолжают появляться, даже когда сайт уже открывается, проблема может быть не устранена полностью. В таком случае лучше не игнорировать лог, а добить источник ошибки до конца.
Когда сайт стабильно открывается, отключите режим отладки, чтобы не писать ошибки в лог постоянно и не светить технические детали наружу:
define( 'WP_DEBUG', false );Если вы включали дополнительные строки для логирования, их тоже можно оставить только на время диагностики. На рабочем сайте постоянный вывод отладочной информации не нужен.
Что делать, если ничего не помогло
Если после отключения плагинов, проверки темы, памяти и PHP сайт всё равно белый, проблема может быть глубже: повреждён core WordPress, ошибка на уровне сервера, битый файл после неудачного обновления или ограничение хостинга. В этом случае полезно сделать три вещи по порядку.
- Сверить файлы WordPress с чистой версией той же релизной ветки и заменить ядро, не трогая
wp-contentиwp-config.php. - Проверить логи веб-сервера и PHP на стороне хостинга, если они доступны.
- Обратиться в поддержку хостинга с точным временем сбоя и фрагментом ошибки из лога.
Если у вас есть резервная копия, иногда быстрее восстановить сайт на момент до сбоя, а уже потом отдельно искать причину. Но это имеет смысл только если вы понимаете, что именно потеряете при откате данных.
Белый экран смерти в WordPress почти всегда можно локализовать. В большинстве случаев достаточно отключить проблемный плагин, исправить тему или поднять лимит памяти. Главное — не менять всё сразу и не работать вслепую: сначала включите лог, затем проверьте плагины, тему, память и совместимость PHP. Такой порядок обычно быстрее всего возвращает сайт в рабочее состояние.