Белый экран в WordPress или ошибка 500 при заходе на сайт - это всегда следствие конкретной причины на сервере, а не случайность. За практику я разбирал десятки таких обращений: от опечатки в functions.php до исчерпанной квоты памяти на хостинге. Показываю, в каком порядке проверяю сайт, чтобы найти причину за 15-30 минут, а не перебирать варианты вслепую.
Что означает белый экран и ошибка 500 в WordPress
Белый экран (в англоязычных источниках его называют White Screen of Death) появляется, когда PHP ловит фатальную ошибку, но вывод сообщений отключен в настройках сервера. Скрипт останавливается, HTML не долетает до браузера, страница остается пустой без единой строчки текста.
Ошибка 500 Internal Server Error - это ответ веб-сервера, а не PHP-скрипта напрямую. Он означает, что сервер не смог обработать запрос: упал PHP-FPM процесс, кончилась память, сломался .htaccess или веб-сервер не получил ответ от бэкенда за отведенное время. На практике оба симптома часто имеют одну корневую причину, просто хостинг по-разному оформляет вывод.
Типичные признаки, по которым сразу понятно, в какую сторону копать:
| Симптом | Что вероятнее всего случилось |
|---|---|
| Белый экран сразу после обновления плагина | Плагин или его зависимость несовместимы с текущей версией WordPress или PHP |
| Белый экран только в админке, сайт открывается | Конфликт в конкретном плагине, который подключается лишь в wp-admin |
| Ошибка 500 сразу после переноса на другой хостинг | Устаревший .htaccess, неверные права на файлы или лимиты PHP |
| Ошибка 500 время от времени, без видимой причины | Нехватка памяти или числа PHP-воркеров на тарифе хостинга под нагрузкой |
Включаю WP_DEBUG и читаю debug.log
Первым делом достаю текст ошибки, который WordPress прячет от посетителя. Открываю wp-config.php через FTP или файловый менеджер хостинга (панель админки может быть недоступна) и перед строкой /* That’s all, stop editing! */ добавляю блок:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Перед правкой сохраняю копию файла рядом (wp-config.php.bak) - откатиться при опечатке быстрее, чем потом разбирать вторую ошибку поверх первой.
После обновления страницы в корне сайта появляется файл wp-content/debug.log с точным текстом ошибки: какой файл, какая строка, какая функция вызвана. Обычно там сразу видно что-то вроде Fatal error: Uncaught Error: Call to undefined function acf_add_local_field_group() - и дальше ищу, откуда взялся вызов несуществующей функции: чаще всего плагин обновился, а его зависимость нет.
Если доступа к файлам вообще нет, лог часто дублируется в личном кабинете хостинга, в разделе с ошибками PHP - названия разделов отличаются у каждого провайдера, но суть та же.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Белый экран после обновления плагина или темы
Самая частая причина белого экрана на моей практике - обновление плагина, которое тянет за собой конфликт с темой или другим модулем. Например, на одном интернет-магазине на WooCommerce после автообновления плагина эквайринга T‑Bank перестала открываться страница оформления заказа: новая версия плагина ждала метод, которого не было в старой версии ядра WooCommerce. Похожая история случается с модулями доставки СДЭК, если плагин доставки обновился раньше самого WooCommerce.
Проверяю по шагам:
- Через FTP переименовываю папку wp-content/plugins в plugins_old - WordPress автоматически отключит все плагины, сайт должен открыться.
- Если открылся, возвращаю прежнее имя папке и переименовываю уже подкаталоги конкретных плагинов по одному, пока не найду виновника.
- Для темы делаю то же самое: временно переименовываю активную тему в wp-content/themes, WordPress откатится на стандартную вроде Twenty Twenty Four.
- Нашел виновника - обновляю его до совместимой версии или отключаю на время, пока разработчик не выпустит фикс.
Такой перебор занимает 10-15 минут даже на сайте с полусотней плагинов, потому что сразу видно, вернулась страница или нет.
Ошибка 500: где искать причину на сервере
Если debug.log пустой, а сайт все равно отдает 500‑ю, причина обычно не в PHP-коде, а в ресурсах или конфигурации сервера. Смотрю журнал ошибок веб-сервера - у большинства хостингов он лежит в панели управления, а не в файлах WordPress.
| Панель хостинга | Где искать журнал ошибок |
|---|---|
| cPanel | раздел Metrics - Errors |
| ISPmanager | журнал ошибок PHP в настройках сайта |
| Timeweb, Beget и похожие | личный кабинет, раздел «Логи» или «Ошибки» |
Частая находка в этом логе - PHP Fatal error: Allowed memory size exhausted. Хостинг по умолчанию выделяет PHP 128-256 МБ, а тяжелая тема с конструктором страниц вместе с десятком плагинов легко упирается в этот потолок. Поднимаю лимит в wp-config.php:
define('WP_MEMORY_LIMIT', '512M');Если хостинг ограничивает лимит на уровне php.ini и переопределение не срабатывает, пишу в поддержку хостинга с просьбой поднять memory_limit для аккаунта - в большинстве случаев это делают за 5 минут на своей стороне.
Проверяю .htaccess, права на файлы и версию PHP
Ошибка 500 часто вылезает после переноса сайта на новый хостинг или смены структуры ссылок. .htaccess, переехавший вместе с бэкапом, может ссылаться на модули, которых нет на новом сервере. Переименовываю файл в .htaccess_old и захожу в Настройки - Постоянные ссылки, просто сохраняю форму без изменений - WordPress перезапишет файл с нуля.
Права на файлы и папки - вторая частая причина после ручного восстановления из архива: если владелец файлов не совпадает с пользователем PHP на сервере, веб-сервер получает Permission Denied и отвечает 500‑й. Привожу к стандарту 644 для файлов и 755 для папок через FTP-клиент или консоль.
Третья причина - автоматическое обновление PHP на хостинге. Если сайт держится на старом плагине, который не пережил переход на PHP 8.2 или 8.3, сервер валится с ошибкой синтаксиса или несовместимого типа данных. В панели хостинга временно откатываю версию PHP на предыдущую, чтобы сайт снова заработал, и уже без спешки привожу код в порядок.
Когда причина не в коде: хостинг, база данных и вирусы
Часть случаев вообще не связана с плагинами и темами. Ошибка Error establishing a database connection означает, что WordPress не достучался до MySQL: неверные данные в wp-config.php после переноса, упавшая служба базы на сервере или превышен лимит одновременных подключений на тарифе хостинга. Проверяю константы DB_NAME, DB_USER, DB_PASSWORD, DB_HOST в wp-config.php, и если с ними все в порядке, обращаюсь в поддержку хостинга - там же обычно виден статус самой базы.
Если ошибка связана с поврежденными таблицами (обычно после некорректного восстановления из бэкапа), добавляю в wp-config.php define('WP_ALLOW_REPAIR', true) и захожу на /wp-admin/maint/repair.php - WordPress проверит и починит таблицы базы встроенным инструментом. После починки строку из wp-config.php убираю, чтобы этот раздел не остался открытым посторонним.
Отдельная категория - заражение файлов вредоносным кодом. Такой код в functions.php или в скрытых файлах темы часто вызывает белый экран из-за синтаксической ошибки, которую внедрил сам вирус, либо ошибку 500 из-за бесконечного цикла или обращения к несуществующему файлу. Чистка руками занимает часы, потому что зараза обычно продублирована в нескольких местах и маскируется под системные файлы. Если сайт уже заражен, обычно беру это как поддержку и сопровождение сайтов с чисткой файлов, проверкой ядра на оригинальность и заменой скомпрометированных паролей.
Частые вопросы
Белый экран и ошибка 500 в WordPress - это одно и то же?
Нет. Белый экран - это фатальная ошибка PHP, которую сервер просто не показал в браузере. Ошибка 500 - код ответа веб-сервера, который может быть вызван той же PHP-ошибкой, а может - нехваткой памяти, сломанным .htaccess или сбоем PHP-FPM. Причины пересекаются, но диагностика немного разная: для белого экрана сначала смотрю debug.log, для 500‑й - логи веб-сервера в панели хостинга.
Можно ли увидеть текст ошибки, если экран совсем пустой?
Да, через WP_DEBUG_LOG в wp-config.php или через журнал ошибок PHP в панели хостинга - вывод на экран может быть отключен, но в файл ошибка все равно пишется. Если доступа к wp-config.php нет из-за той же ошибки, подключаюсь по FTP или через файловый менеджер хостинга.
Что делать, если сайт открылся, а в админку зайти нельзя?
Обычно это отдельная проблема с сессией или правами: чищу куки браузера, проверяю доступность wp-admin напрямую и смотрю, не заблокировал ли плагин безопасности собственный IP после серии неудачных попыток входа. Если плагин безопасности сам стал причиной блокировки, временно отключаю его через переименование папки в wp-content/plugins.
Как снизить риск повторения такой ошибки?
Обновляю плагины по одному, а не пакетом, и держу тестовую копию сайта для проверки крупных обновлений WooCommerce или темы перед тем как накатывать их на боевой сайт. Если самому за этим следить некогда, беру такие сайты на техподдержку - слежу за обновлениями и логами вместо того, чтобы разбирать белый экран уже после того как он случился.