Секунду назад сайт работал, вы дописывали статью или настраивали WooCommerce, и вдруг пустота. Белый лист вместо админки. Или главная страница исчезла, хотя панель управления открывается. Знакомо? Добро пожаловать в клуб, вы встретились с White Screen of Death, он же WSOD, он же «белый экран смерти» WordPress.

Паника здесь, первый враг. WSOD почти никогда не означает, что сайт умер безвозвратно. Чаще всего причина банальна: конфликт плагинов после обновления, криво вставленный код в functions.php или банальная нехватка памяти под PHP-процесс. В этом руководстве, четыре проверенных способа вернуть сайт к жизни и пятый, встроенный в ядро WordPress, о котором забывают даже опытные пользователи.

💡 Быстрый обзор:

• Отключить проблемный плагин через FTP (переименовать папку) или массово, переименованием директории plugins
• Отключить конфликтную тему тем же методом: папка themes → переименовать директорию активной темы
• Поднять лимит памяти PHP строкой WP_MEMORY_LIMIT в wp-config.php до 128M или 256M
• Включить WP_DEBUG и WP_DEBUG_LOG для диагностики, узнать точную причину ошибки из файла debug.log
• Использовать Recovery Mode (WordPress 5.2+), встроенный механизм, который присылает ссылку на вход в админку даже при фатальной ошибке
• Восстановить сайт из бекапа, если остальные методы не дали результата

1. Отключение проблемного плагина

Плагины, самая частая причина WSOD. Только что обновили любимый кеширующий плагин, экран погас. Установили новый слайдер, сайт перестал открываться. Механика проста: PHP-код плагина вызывает фатальную ошибку, и WordPress останавливает загрузку страницы целиком.

Беда в том, что зайти в админку и нажать «Деактивировать» нельзя, админка точно так же уходит в белый лист. Решение: отключить плагин напрямую через файловую систему.

Как отключить один плагин через FTP:

• Подключитесь к серверу по FTP (FileZilla, WinSCP) или через файловый менеджер хостинга (cPanel → File Manager).
• Перейдите в корневой каталог WordPress.
• Откройте wp-content/plugins.
• Найдите папку проблемного плагина, имя совпадает с названием (например, akismet, woocommerce или elementor).
• Переименуйте папку: добавьте символ подчёркивания или суффикс, _akismet или akismet_disabled. WordPress воспримет переименование как отсутствие плагина и деактивирует его.

Сразу после переименования откройте сайт в браузере. Заработал, виновник найден. Теперь можно вернуть папке исходное имя и, зайдя в админку, либо обновить плагин до совместимой версии, либо удалить и подобрать альтернативу.

Массовое отключение всех плагинов разом. Если непонятно, какой именно плагин вызвал сбой, отключите всё скопом. Переименуйте саму папку wp-content/plugins в plugins_old и создайте рядом новую пустую директорию plugins. Все плагины деактивированы. Дальше возвращайте их по одному: перенесите папку плагина из plugins_old обратно в plugins, зайдите в админку, активируйте, и проверьте сайт. Повторяйте, пока не найдёте виновного.

Альтернатива для тех, у кого есть WP-CLI. Одна команда в терминале заменяет FTP-танец с бубном:

1
wp plugin deactivate --all

И затем активируйте по одному: wp plugin activate <slug>. Быстро, чисто, без файлового менеджера.

2. Отключение конфликтной темы

Второй по частоте виновник, тема. Сценарии те же: обновили тему до новой мажорной версии, установили тему с плохо написанным functions.php, или плагин вступил в конфликт с текущей темой после обновления WordPress.

Механизм исправления почти идентичен плагинному:

• Зайдите по FTP в wp-content/themes.
• Найдите папку активной темы (та, что установлена на сайте прямо сейчас).
• Переименуйте её, например, добавьте _disabled в конец имени.

WordPress, не найдя активную тему, автоматически переключится на стандартную тему Twenty Twenty-Five (или Twenty Twenty-Four, зависит от версии WP). Сайт загрузится с дефолтным дизайном, но весь ваш контент останется на месте. Важно: не удаляйте стандартную тему, иначе переключиться будет не на что, и вы получите ещё один виток WSOD.

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

Правка functions.php и другие файлы темы. Опечатка в functions.php, лишняя скобка, неправильный вызов хука, и сайт ложится. Если вы редактировали файлы темы непосредственно перед появлением WSOD, замените изменённый файл исходной версией из бекапа или дистрибутива темы. Без бекапа, скачайте тему заново из источника и залейте чистый файл.

3. Превышение лимита памяти PHP

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

WordPress официально рекомендует минимум 64 МБ памяти, но эта рекомендация родом из эпохи PHP 5.6 и пяти плагинов на сайт. В 2026 году реалистичный минимум для работающего сайта, 128 МБ, а для сборок с Elementor, WooCommerce и несколькими десятками плагинов, 256 МБ.

Как увеличить лимит памяти:

Откройте файл wp-config.php (лежит в корне установки WordPress) и добавьте строку перед комментарием /* That's all, stop editing! */:

1
define('WP_MEMORY_LIMIT', '256M');

Если провайдер жёстко ограничивает PHP-память на уровне сервера, эта директива не сработает, тогда выход один: сменить тариф или хостинг. Управляемый WordPress-хостинг (SiteGround, WP Engine, Kinsta) настраивает лимиты адекватно из коробки, и проблема памяти там практически не встречается.

4. Диагностика через WP_DEBUG

Бывает, что ни плагины, ни тема, ни память не при чём, причина WSOD ускользает. Тогда нужно заставить WordPress рассказать, что именно пошло не так.

WordPress десятилетиями носит в себе встроенный отладчик WP_DEBUG. По умолчанию он выключен (белый экран вместо ошибок, задумка, чтобы не светить внутренности сайта посетителям). Но администратору этот режим бесценен.

Добавьте в wp-config.php:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Что происходит:

• WP_DEBUG включает режим отладки;
• WP_DEBUG_LOG пишет ошибки в файл wp-content/debug.log, удобно читать, не показывая посетителям;
• WP_DEBUG_DISPLAY со значением false прячет ошибки с экрана (вы видите белый лист, но логи пишутся).

После включения откройте сайт, воспроизведите проблему и загляните в wp-content/debug.log. Там будет строка с файлом, номером строки и типом ошибки, например, Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. Это точный адрес проблемы.

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

5. Recovery Mode, встроенный спасатель WordPress 5.2+

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

Как это работает. Когда PHP-код плагина или темы вызывает фатальную ошибку, WordPress перехватывает её, останавливает проблемное расширение и отправляет письмо на email администратора. В письме, ссылка, которая открывает доступ в админку в обход проблемного кода. Вы заходите, видите упавший плагин с пометкой «вызвал ошибку», деактивируете его, и сайт снова жив. Никакого FTP, никакого переименования папок.

Ограничения Recovery Mode:

• Ссылка действует ограниченное время (около суток) и привязана к IP-адресу;
• Требуется настроенная отправка почты с сайта (SMTP-плагин или хостинговая почта);
• Не спасает от ошибок на уровне сервера (нехватка памяти, битый .htaccess).

И всё же, если письмо пришло, вы экономите десяток минут нервов и FTP-телодвижений.

Посмотрите короткое руководство по исправлению WSOD, все описанные методы с живой демонстрацией:

⁉️🤔 Частые вопросы

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

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

Белый экран только на одной странице поста или записи, что это?

Скорее всего, проблема в содержимом конкретной записи: шорткод несуществующего плагина, битый HTML в тексте, конфликт с кастомными полями. Откройте запись через Quick Edit в админке и временно смените статус на «Черновик». Страница загрузится? Значит, копайте внутри контента.

Можно ли вообще избежать WSOD в будущем?

Полностью исключить, нет, но минимизировать риск реально. Три правила: (1) всегда тестируйте обновления плагинов и тем на staging-копии сайта перед выкаткой на продакшен; (2) держите ежедневный бекап, файлов и базы данных; (3) не устанавливайте плагины и темы из сомнительных источников, особенно nulled-версии.

Recovery Mode не отправил письмо, что делать?

Почта с WordPress-сайта без настроенного SMTP-плагина работает нестабильно. Настройте SMTP (Post SMTP, FluentSMTP или WP Mail SMTP) в качестве превентивной меры. Если письмо уже не пришло, возвращайтесь к FTP-методу из раздела 1, он работает всегда.

Через сколько проходит Recovery Mode ссылка?

Ссылка действительна 24 часа (точнее, до истечения nonce-токена). После этого нужно воспроизвести ошибку заново, WordPress снова отправит письмо.

Что делать, если ничего не помогло?

Если четыре метода выше и Recovery Mode не вернули сайт, проблема глубже. Возможно, повреждён файл .htaccess (переименуйте его и зайдите в админку, WordPress создаст новый через «Настройки → Постоянные ссылки → Сохранить»). Или несовместимость версии PHP: современный WordPress требует PHP 7.4+, а на хосте до сих пор может стоять PHP 5.6.

Ещё один инструмент диагностики, плагин Health Check & Troubleshooting от команды WordPress.org. Он умеет запускать сессию безопасности: отключает все плагины и переключает на стандартную тему, но только для вашего браузера (посетители видят обычный сайт). С ним можно безопасно включать плагины по одному и ловить виновника, не трогая продакшен.

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

И главное, не бойтесь WSOD. Это неприятно, но решаемо. Теперь у вас есть пошаговый алгоритм действий, а не паника и пустой экран.