White screen of death в WordPress: 5 причин и как починить

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

Открываете сайт, а вместо страницы белый прямоугольник. Ни заголовка, ни ошибки, ни намёка на причину. Это классический WordPress white screen of death (WSOD), один из самых частых и при этом самых пугающих симптомов. Пугающих, потому что ноль информации. На самом деле в 90 процентах случаев чинится за 15-30 минут, главное знать порядок шагов.

В этой статье разберём, что вообще такое WSOD и почему он чаще всего не критичный, как включить WP_DEBUG и прочитать error log, какие пять причин дают белый экран в реальной жизни (фатальный плагин, конфликт темы, лимит памяти PHP, поломанный update, недоступная БД), как получить аварийный доступ через FTP и переименовать плагины и тему, и в каком случае белый экран это симптом взлома, а не просто баг.

Что такое WSOD и почему чаще всего он не критичный

WordPress white screen of death это ситуация, когда сайт отвечает 200 OK, но в теле ответа пусто или почти пусто. В браузере это выглядит как белый экран. Часто пустая и админка, часто — только фронт. Бывает на одной странице, бывает на всех.

Причина почти всегда одна и та же: в PHP произошла фатальная ошибка, выполнение остановилось в середине рендера, и до пользователя дошёл уже накопленный буфер вывода без html-структуры. С PHP 8 поведение немного изменилось: вместо чистого белого экрана WordPress часто показывает короткое сообщение «There has been a critical error on this website» и адрес письма, куда улетела копия трейса. Если у вас именно такая страница, считайте это улучшенным WSOD.

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

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

Включаем WP_DEBUG и смотрим в error log

Файл wp-config.php в корне сайта. Открываем по FTP, SFTP или через файловый менеджер хостинга. Ищем строку:

define( 'WP_DEBUG', false );

Меняем на:

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

Что это делает:

• WP_DEBUG true включает выдачу ошибок PHP.
• WP_DEBUG_LOG true пишет ошибки в файл wp-content/debug.log.
• WP_DEBUG_DISPLAY false и display_errors 0 запрещают показывать ошибки в HTML, чтобы посетители их не видели.

Сохраняем, обновляем сайт. Снова белый экран, но теперь в wp-content/debug.log появилась строка вроде:

[26-Apr-2026 10:15:32 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product() in /var/www/example/wp-content/plugins/some-plugin/includes/class-cart.php:84

Эта строка содержит всё нужное: тип ошибки (Fatal), что именно сломалось (отсутствующая функция WooCommerce), путь к файлу и номер строки. В нашем примере виноват плагин some-plugin, который зависит от WooCommerce, а WooCommerce, видимо, отключён или удалён.

Если debug.log пустой

Бывает, что после включения WP_DEBUG файл не появляется. Возможные причины:

1. Файл не создаётся из-за прав. Создайте wp-content/debug.log вручную, поставьте 644.
2. Ошибка происходит до загрузки wp-config.php (редко, например, синтаксическая ошибка в самом конфиге). Смотрите server-уровневый лог.
3. Хостинг переопределяет display_errors через php.ini так, что лог не пишется. Свяжитесь с поддержкой, попросите дать доступ к лог-файлу PHP.

На большинстве shared-хостингов отдельный лог PHP лежит в одной из этих локаций: ~/logs/php_error.log, ~/error_log, /home/<user>/error_log. На VPS обычно /var/log/php-fpm/error.log или /var/log/apache2/error.log. Если есть SSH:

tail -n 100 ~/logs/php_error.log
tail -n 100 /home/cr43080/error_log

В большинстве случаев первая же ошибка из лога даёт ответ.

Пять самых частых причин

1. Фатальный плагин

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

В логе это выглядит как Call to undefined function, Class not found, Cannot redeclare, Uncaught Error. Путь в логе всегда указывает на конкретный файл плагина в wp-content/plugins/<plugin-name>/.

Решение — временно отключить виновного. Через админку: Плагины — найти в списке — «Деактивировать». Если админка тоже белая, идём через FTP (про это ниже).

2. Конфликт темы

Реже, но случается. Особенно после обновления PHP на хостинге, когда тема использует устаревшие функции (each(), mysql_*, create_function). В логе обычно Deprecated, Fatal error: Uncaught Error: Function ... is deprecated.

Решение — временно переключиться на стандартную тему (Twenty Twenty Five или любую, поставленную из коробки). Если админка работает: Внешний вид — Темы — «Активировать» другую. Если админка лежит, переименовываем папку текущей темы по FTP, WordPress автоматически активирует первую попавшуюся стандартную тему.

3. Лимит памяти PHP

Симптом: WSOD только на тяжёлых страницах (карточка товара со 100 фото, отчёт в админке, страница с большим количеством виджетов). В логе: Allowed memory size of X bytes exhausted.

Решение — увеличить memory_limit. Три способа.

Через wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Через .htaccess (если хостинг разрешает):

php_value memory_limit 256M

Через php.ini (если хостинг разрешает свой ini):

memory_limit = 256M

Какой именно сработает — зависит от хостинга. Я обычно прописываю в wp-config.php и .htaccess сразу, чтобы наверняка. После правки обновите страницу с ошибкой и проверьте, что в логе нет новой записи про память.

Если на shared-хостинге memory_limit зажат намертво и вы упёрлись в его потолок (обычно 128M или 256M на копеечных тарифах) — либо ищите, какой плагин жрёт память (часто это устаревшие галереи или лента социальных сетей), либо переезжайте на хостинг получше.

4. Поломанный update

Симптом: белый экран начался ровно после обновления WordPress, темы или плагина. В логе обычно Maintenance mode is on, Could not write file, или просто фатальная ошибка в свежеобновлённом коде.

Сначала проверяем, не застряло ли обновление. WordPress на время апдейта создаёт в корне файл .maintenance. Если он остался после неудачного апдейта — удалите его, сайт оживёт.

rm /var/www/example/.maintenance

Если дело в самом обновлённом плагине или теме, который теперь несовместим — откатите версию. Скачайте предыдущую с https://wordpress.org/plugins/<plugin>/advanced/ или из локального бэкапа, замените файлы плагина в wp-content/plugins/<plugin>/. После отката WordPress предложит обновиться снова — не торопитесь, сначала проверьте changelog и issues.

5. Недоступная база данных

Симптом: WSOD на всём сайте, в логе Error establishing a database connection (хотя WordPress обычно показывает это сообщение явно, не белым экраном).

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

mysql -u USER -p -h HOST DBNAME -e "SHOW TABLES;"

Если таблицы видны — база жива, дело в wp-config.php (неправильный пароль после смены, неправильный хост). Если не видны — писать в поддержку хостинга, «база MySQL не отвечает по адресу X с пользователем Y».

Повреждение таблиц лечится через phpMyAdmin: выбрать БД, отметить все таблицы, «Восстановить таблицу» в выпадающем меню. Если таблиц много, через консоль:

mysqlcheck -u USER -p --auto-repair --all-databases

Аварийный доступ через FTP

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

Подключаемся по FTP/SFTP, идём в wp-content/. Дальше один из сценариев.

Точечно отключить плагин

Если из лога знаете виновника (например, woocommerce-old-extension), переименуйте именно его папку:

wp-content/plugins/woocommerce-old-extension

в

wp-content/plugins/woocommerce-old-extension_OFF

Обновите сайт. WordPress деактивирует плагин (увидит, что его больше нет), всё остальное останется как было.

Отключить все плагины разом

Если виновника не знаете и в логе пусто, переименуйте всю папку плагинов:

wp-content/plugins

в

wp-content/plugins_OFF

Сайт оживёт. Дальше переименовываем обратно и включаем плагины по одному, после каждого открывая фронт. Так найдёте виновника за 10-15 минут.

Переключить тему

Если всё равно белый экран без плагинов, виновата тема. Переименуйте текущую тему в wp-content/themes/. WordPress активирует первую стандартную (Twenty Twenty Five или похожую). Если ни одной стандартной нет, создайте папку wp-content/themes/twentytwentyfive/ и положите туда минимальный style.css и index.php — WordPress подхватит.

Откатить wp-config.php

Если белый экран начался сразу после правок wp-config.php, скорее всего опечатка. Откатите файл из бэкапа. Если бэкапа нет — сравните с эталонным wp-config-sample.php в корне WordPress, восстановите структуру вручную. Самые частые ошибки: лишняя точка с запятой, неэкранированный апостроф в пароле БД, BOM-пробел перед открывающим <?php.

Когда WSOD это симптом взлома

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

Признаки, что WSOD связан со взломом:

1. В логе фатальные ошибки в файлах, которые вы не узнаёте: wp-content/uploads/2024/03/wpx_old.php, wp-includes/template-suff.php, wp-admin/css/admin.css.php.
2. В логе ошибки про eval, base64_decode, gzinflate. Это типичные обёртки вредоносного кода.
3. WSOD появился внезапно без обновлений и правок с вашей стороны.
4. Параллельно браузеры пишут «Опасный сайт», в Я.Вебмастере фатальное письмо про вредоносный код, или хостер прислал уведомление.
5. В корне или в wp-content/uploads/ лежат .php-файлы со странными именами вроде xleet.php, wso.php, marijuana.php, 0x.php.

Если хотя бы два пункта совпали, чините не WSOD, а инцидент целиком. Краткий план:

• Снимите бэкап грязного состояния (всех файлов и БД), не работайте напрямую с прода.
• Закройте сайт от посетителей через .htaccess или режим обслуживания.
• Проверьте все админ-аккаунты, удалите неизвестных. Смените все пароли (WordPress, БД, FTP, хостинг-панель).
• Сравните файлы ядра WordPress с эталонной версией через WP-CLI:

wp core verify-checksums

Подробно про чистку WordPress после взлома есть отдельная статья в рубрике /blog/category/security/.

Чек-лист действий при WSOD

[ ] Включён WP_DEBUG_LOG в wp-config.php
[ ] Прочитан wp-content/debug.log или серверный php_error.log
[ ] Если в логе фатал плагина - плагин отключён через FTP
[ ] Если в логе фатал темы - переключено на стандартную тему
[ ] Если в логе превышение памяти - поднят memory_limit до 256M
[ ] Удалён файл .maintenance из корня (если был)
[ ] Проверена доступность БД через mysql или phpMyAdmin
[ ] Если ничего не помогло - все плагины разом переименованы
[ ] Если и это не помогло - тема переименована
[ ] Проверены подозрительные файлы в uploads и корне на признаки взлома
[ ] После починки WP_DEBUG_LOG выключен (true → false)

После того как сайт ожил, не забудьте вернуть WP_DEBUG обратно в false. Иначе debug.log будет расти и однажды съест место на диске. На активных сайтах за месяц так может накопиться несколько гигабайт ошибок (PHP Notice и PHP Warning пишутся туда тоже).

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

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

• Версия PHP. Проверьте, какая версия PHP сейчас на хостинге (<?php phpinfo(); в тестовом файле). WordPress 6.x требует минимум PHP 7.4, рекомендует 8.1+. Если хостинг по умолчанию на PHP 7.0 — переключите в панели на 8.1, многие современные плагины откажутся работать со старым PHP.
• mod_security или firewall хостинга. Иногда сервер режет POST-запросы или конкретные параметры, выдавая 200 с пустым телом. Симптом: WSOD только при сабмите формы или сохранении в админке, а на обычных страницах всё работает. Лечение — писать в поддержку хостинга, «уберите правило N для моего домена».
• OPcache. Иногда после обновления файлов PHP-OPcache держит старые опкоды и валится. Перезагрузка PHP-FPM или сброс OPcache через хостинг-панель решает.
• Проблема не на вашей стороне. Если хостинг сейчас падает (см. их статус-страницу или Twitter), просто подождите. Не делайте ничего.

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

Другие материалы по WordPress и CMS лежат в рубрике /blog/category/cms/.

Частые вопросы

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

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

Как отключить плагины без доступа в админку

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

Какие причины бывают кроме плагинов

Нехватка памяти PHP, ошибка в файле темы, несовместимость с версией PHP и повреждённый файл ядра. Все четыре видны в логе, если включить его вывод.

Когда белый экран это признак взлома

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