За час до старта акции открываете витрину — белая страница, ни логотипа, ни текста ошибки. Не уверены, какой это симптом? Сначала — алгоритм «сайт не работает». В практике WSOD чаще всего после массового обновления плагинов или переезда на PHP 8 без проверки темы. Ниже — что это за белый экран и как за 15–60 минут найти виновника без паники.
Что такое белый экран WordPress (WSOD)
White Screen of Death — это пустая страница без логотипа, без ошибки, без HTML-разметки. Браузер получает корректный ответ HTTP 200, но в теле ответа — пусто или почти пусто. С точки зрения PHP это означает, что выполнение скрипта оборвалось до того, как успели отдаться заголовки контента.
До WordPress 5.2 любая fatal PHP-ошибка приводила именно к белому экрану. С 5.2+ WordPress показывает сообщение «There has been a critical error on this website» (см. отдельную статью). Если сейчас видите именно пустой белый экран — значит ошибка возникла настолько рано в загрузке, что даже recovery-режим не успел сработать.
7 типовых причин
В порядке убывания частоты по опыту работы с клиентскими сайтами:
- Не хватает PHP memory_limit. Дефолтные 64 МБ часто не вытягивают связку WooCommerce + Elementor + 10–15 плагинов. Лимит закончился — скрипт упал.
- Конфликт плагина с темой или ядром. Обновили один компонент — он стал требовать новые версии хуков, которые не поддерживают остальные. Если плагинов много — перед массовым обновлением имеет смысл пройти аудит списка.
- Несовместимость с PHP 8.x. Тема или плагин использует устаревший синтаксис (фигурные скобки массивов,
each(), неявные свойства классов) — PHP 8 их не понимает. - Битый файл темы или плагина. Файл загрузился по FTP не до конца, или его повредил вирус.
- Циклический include или бесконечная рекурсия в functions.php. Скрипт упирается в
max_execution_time. - Слишком жёсткие правила .htaccess. Особенно после миграции с другого сервера или включения «защиты» от плагина безопасности.
- Заражение или шеллы в файлах. Вредоносный код пытается отработать первым и валит выполнение.
Алгоритм проверки за 15–60 минут
Шаг 1. Включите WP_DEBUG
По FTP откройте wp-config.php и над строкой /* That's all, stop editing! */ добавьте:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);После этого ошибки начнут писаться в файл wp-content/debug.log. Перезагрузите страницу — в логе появится конкретная PHP-ошибка с указанием файла и строки.
Шаг 2. Прочитайте debug.log
Самые информативные строки — те, где написано Fatal error, Uncaught Error или Allowed memory size exhausted. По названию файла обычно сразу понятно, какой плагин или тема виноваты:
wp-content/plugins/woocommerce-bookings/...— проблема в этом плагине;wp-content/themes/flatsome/...— проблема в теме;wp-includes/...— обычно тоже не само ядро, а вызов из плагина.
Шаг 3. Поднимите memory_limit
Если в логе видите Allowed memory size of 67108864 bytes exhausted — нужно больше памяти. В wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');Если ничего не изменилось — лимит, скорее всего, упирается в настройку хостинга. Откройте .htaccess и добавьте:
php_value memory_limit 256MНа VDS/VPS — то же значение в php.ini и перезапуск PHP-FPM. На shared-хостинге Beget/Timeweb без поддержки php_value — пишите в техподдержку.
Шаг 4. Откатите последнее изменение
Если белый экран появился после обновления плагина / темы — откатите. По FTP:
- переименуйте папку плагина в
wp-content/plugins/имя-плагина_OFF— этот плагин деактивируется; - обновите страницу — если сайт ожил, причина найдена;
- переименуйте папку обратно и переустановите плагин нужной версии через плагин WP Rollback или вручную из репозитория.
Шаг 5. Отключите все плагины разом
Если не понятно, какой плагин виноват, переименуйте папку wp-content/plugins в wp-content/plugins_OFF. Сайт оживёт без плагинов. Подробный разбор всех способов — в статье про отключение плагинов без админки. Дальше — переименовываете обратно и включаете плагины по одному из админки, пока не найдёте «убийцу».
Шаг 6. Переключитесь на дефолтную тему
Если плагины ни при чём, переименуйте папку текущей темы в wp-content/themes/your-theme_OFF. WordPress автоматически переключится на одну из дефолтных (Twenty Twenty-Four и т.п.). Если сайт ожил — проблема в теме.
Шаг 7. Проверьте .htaccess и заражение
Откройте .htaccess в корне — в нём не должно быть подозрительных RewriteRule, ссылок на чужие домены или php_value auto_prepend_file с непонятным путём. Также прогоните файлы темы и плагинов через антивирусный сканер (Wordfence, ClamAV) — особенно если до этого сайт ранее показывал редиректы или жалобы на спам.
Что делать, если не помогло
Если все 7 шагов прошли, а сайт лежит — значит проблема глубже: повреждение базы, конфликт на уровне PHP-расширений или вообще проблема хостинга. В этой точке полезно подключить специалиста — разбор бесплатно, по итогу назовём точную причину и время на починку.
Профилактика — чтобы не повторилось
- Перед обновлением плагина / темы / ядра — всегда бэкап (файлы + БД).
- Обновлять по одному, проверять сайт между обновлениями — не «всё разом».
- Иметь staging-копию для тестов крупных обновлений.
- Минимум 256 МБ
memory_limitв проде, особенно с WooCommerce. - Подключённый WP Mail SMTP или плагин логирования fatal-ошибок (Health Check & Troubleshooting), чтобы получать письма о сбоях.
