После обновления плагина витрина стала белой, админка не открывается, заявки не приходят — и кажется, что сайт умер. На практике это тишина PHP: страница не дописалась. За 30–60 минут без паники проверьте почту Recovery Mode, настройте отключение плагинов через файловый менеджер, при необходимости смените тему и получите запись в debug.log — сайт оживёт или будет понятный текст для поддержки.
Белый экран WordPress (WSOD) — пустая страница при том, что браузер иногда показывает код 200: тело ответа пустое. С WordPress 5.2 при многих фатальных ошибках вместо молчания появляется экран «There has been a critical error» и письмо администратору со ссылкой Recovery Mode. Полный «немой» белый экран чаще остаётся, если ошибка случилась до загрузки обработчика или отладка настроена так, что на экран ничего не выводится. План: бэкап → почта → отключить плагины → тема → лог → один виновник → вернуть настройки.
Марина перед распродажей обновила кэш-плагин: скачала всю папку plugins, хотя хватило переименовать её в plugins.off. Час включала плагины по одному, не проверив письмо Recovery Mode и debug.log с именем виновника. Ниже тот же порядок, но короче.
- Поймите, почему сайт «молчит» после обновления или правки
- Зафиксируйте первые 10 минут: бэкап, обслуживание и доступ к файлам
- Откройте Recovery Mode по письму и отключите виновный плагин из админки
- Отключите все плагины переименованием папки plugins
- Смените активную тему, если плагины не виноваты
- Включите запись ошибок в лог и прочитайте debug.log снизу
- Разберите типичные строки лога: память, синтаксис, несовместимый PHP
- Когда передать сайт специалисту и что собрать в одну папку
- Частые вопросы
- Белый экран после обновления WordPress или плагина — с чего начать?
- Можно ли исправить белый экран без FTP?
- Чем WSOD отличается от ошибки 500?
- Как не потерять заявки, пока сайт лежит?
- Почему нет письма Recovery Mode?
- Нужно ли отключать WP_DISABLE_FATAL_ERROR_HANDLER?
- Сколько времени закладывать на самостоятельное восстановление?
Поймите, почему сайт «молчит» после обновления или правки
WSOD в WordPress — когда PHP встретил фатальную ошибку и перестал выводить текст: белое поле, форма молчит, админка может не открыться. Отличие от 500: сервер иногда отвечает HTTP 200, но тело страницы пустое.
С WordPress 5.2 чаще видят экран critical error и письмо Recovery Mode. Типичная ошибка — решить, что «раз белое, recovery не помог»: ошибка могла случиться до обработчика или лог ещё не включён. Лечится тем же: доступ, потом одна причина.
| Что видите | Что это обычно значит | Первый шаг |
|---|---|---|
| Пустая белая страница | PHP оборвал вывод, часто плагин или тема | Почта Recovery Mode или переименовать plugins |
| Текст «critical error» на сайте | Сработал обработчик WP 5.2+ | Открыть письмо админу и войти по ссылке |
| Ошибка 500 в браузере | Сбой на уровне сервера или .htaccess | Лог хостинга + те же шаги с плагинами |
Зафиксируйте первые 10 минут: бэкап, обслуживание и доступ к файлам
Не начинайте с удаления плагинов наугад. Запишите время сбоя и что меняли за последний час: обновление, правка в теме, смена PHP на хостинге. Сделайте копию: скачайте wp-config.php и папку wp-content/plugins проблемного плагина или убедитесь, что автобэкап WordPress на хостинге свежий — подробнее про привычку бэкапа в материале бэкап перед правками.
Если на сайт ещё заходят клиенты, включите режим обслуживания или временную страницу «техработы» — так меньше потерянных заявок, пока вы чините витрину. FTP для новичка не обязателен: в панели Beget, Timeweb, Reg.ru и аналогах есть «Файловый менеджер» — это тот же доступ к wp-content, только через браузер.
- Шаг 1. Откройте почту, на которую зарегистрирован администратор WordPress (и папку «Спам»). Ищите письмо от WordPress со словами recovery или critical error.
- Шаг 2. Войдите в панель хостинга → Файлы → корень сайта (где лежат wp-config.php, wp-admin, wp-content).
- Шаг 3. Скачайте копию wp-config.php на компьютер перед любыми правками.
- Шаг 4. Обновите главную в режиме инкогнито и зафиксируйте: белый экран, текст critical error или код 500.
- Шаг 5. Запишите в заметку, что меняли за час до сбоя и какой симптом видите сейчас — это сэкономит время, если придётся отключать плагины по одному.
Откройте Recovery Mode по письму и отключите виновный плагин из админки
Recovery Mode — вход по ссылке из письма WordPress в админку, когда снаружи белый экран. В панели отключите помеченный плагин или тему без переименования папок. Сначала проверьте почту и спам; если письма нет — переходите к папке plugins.
Отключите все плагины переименованием папки plugins
Если админка недоступна и письма нет, отключите расширения массово: в wp-content переименуйте папку plugins в plugins.off (любое имя без папки plugins). WordPress не найдёт каталог плагинов и загрузится без них. Обновите сайт в инкогнито. Если витрина ожила — виновник среди плагинов, не в ядре.
Верните имя plugins и переименовывайте подпапки плагинов по одной, обновляя сайт, пока белота не вернётся — последний включённый и есть виновник. На shared-хостинге хватает файлового менеджера, без SSH.
Схема без паники:
Белый экран → почта Recovery Mode → если нет доступа: plugins → plugins.off → сайт жив? → вернуть plugins → отключать папки плагинов по одной → найден виновник → обновить или заменить плагин
Смените активную тему, если плагины не виноваты
Если plugins.off не помог, в wp-content/themes переименуйте папку активной темы. WordPress подхватит стандартную Twenty Twenty-Four — стили другие, но витрина и форма снова проверяемы. Переименование обратимо; после диагноза обновите тему или откатите правку functions.php. Запретите правку PHP из админки через DISALLOW_FILE_EDIT, чтобы не повторить сбой.
Включите запись ошибок в лог и прочитайте debug.log снизу
Когда экран пуст, вам нужен текст ошибки для себя и поддержки. Не включайте вывод ошибок на витрину: на живом сайте нужен блок «лог да, экран нет» — WP_DEBUG true, WP_DEBUG_LOG true, WP_DEBUG_DISPLAY false. Полный разбор с копированием блока в wp-config — в статье WP_DEBUG без поломки сайта для гостей; здесь только связка с белым экраном.
После сохранения wp-config воспроизведите белый экран (откройте проблемную страницу), скачайте wp-content/debug.log и читайте снизу вверх: последние строки с PHP Fatal error, Allowed memory size exhausted или parse error указывают файл — часто путь wp-content/plugins/имя-плагина/…. Скопируйте 3–5 строк в тикет хостинга или мессенджер специалисту — так вы исправьте причину точнее, чем при отключении плагинов наугад.
Разберите типичные строки лога: память, синтаксис, несовместимый PHP
Allowed memory size exhausted — добавьте define( ‘WP_MEMORY_LIMIT’, ‘256M’ ); в wp-config и обновите тяжёлый плагин. Parse error в themes/…/functions.php — откатите файл или смените тему. Пустой debug.log при белом экране — спросите поддержку хостинга про error log PHP с указанием времени сбоя.
Когда передать сайт специалисту и что собрать в одну папку
Если recovery, plugins, тема и лог не помогли за два круга — передайте бэкап, wp-config, хвост debug.log и список последних изменений специалисту.
Результат, к которому идёте: главная или админка снова открываются; отключён один плагин или активна стандартная тема; в debug.log есть свежий Fatal error с путём; WP_DEBUG снова false, лог убран, папки переименованы обратно. Проверьте форму заявок в инкогнито — сможете принимать заявки, пока обновляете или заменяете виновный плагин.
Если некогда копаться в файлах на боевом домене перед сезоном продаж, опишите симптомы через форму контактов (мессенджер, без звонка) или посмотрите услуги по сайтам WordPress. Другие гайды по SEO и технике — в разделе статей; короткие ответы по ходу — в канале t.me/DikiiTelegram.
Материал проверен: Андрей Дикий (создаёт сайты и продвигает их статьями, SEO/GEO).
На что опирались: developer.wordpress.org (Common WordPress errors, Debugging, wp-config Fatal Error Handler); wordpress.org (Recovery Mode, FAQ Troubleshooting); ru.wordpress.org (отладка); fozzy.com KB по WSOD; linuxize.com порядок шагов; GitHub WordPress/wordpress-develop PR #9611 (preflight PHP при активации плагина). Частотность запросов: Яндекс Вордстат, прогон 2026-10-04 (MCP недоступен, точные показы не верифицированы).
Частые вопросы
Белый экран после обновления WordPress или плагина — с чего начать?
С бэкапа и почты администратора на Recovery Mode. Если письма нет — переименуйте wp-content/plugins в plugins.off через файловый менеджер хостинга и обновите сайт в инкогнито.
Можно ли исправить белый экран без FTP?
Да. FTP — лишь один способ. Файловый менеджер в панели хостинга даёт те же переименования папок и правку wp-config.php.
Чем WSOD отличается от ошибки 500?
WSOD часто отдаёт HTTP 200 с пустым телом страницы. Ошибка 500 — явный сбой сервера. Лечение пересекается: отключение плагинов, тема, лог; но при 500 первым смотрят лог веб-сервера на хостинге.
Как не потерять заявки, пока сайт лежит?
Включите режим обслуживания или временную страницу с контактом в мессенджере. Параллельно примите, что форма на сайте не работает, пока PHP не починен — дублируйте приём заявок там, где клиенты уже пишут.
Почему нет письма Recovery Mode?
Неверный email администратора, спам-фильтр, ошибка до отправки почты или хостинг блокирует mail(). Тогда используйте переименование plugins и debug.log — письмо ускоряет, но не обязательно.
Нужно ли отключать WP_DISABLE_FATAL_ERROR_HANDLER?
Новичку нет. Эта константа в wp-config отключает защитный обработчик только для глубокой отладки. Для восстановления сайта достаточно recovery, плагинов, темы и лога.
Сколько времени закладывать на самостоятельное восстановление?
Обычно 30–60 минут, если есть доступ к файлам и свежий бэкап. Если после лога видна непонятная ошибка ядра или базы — передайте копию лога специалисту, не удаляйте файлы наугад.
