Критическая ошибка WordPress: что делать — инструкция

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

В 9 случаях из 10 виноват плагин или тема — чаще всего после обновления, установки нового расширения или смены версии PHP на хостинге. План действий короткий: проверить письмо от режима восстановления, включить лог ошибок, вычислить виновника и отключить его. Разберём каждый шаг — с командами и без паники.

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

Что на самом деле означает эта ошибка

С версии 5.2 в WordPress работает обработчик фатальных ошибок. Раньше при падении PHP посетитель видел белый экран или ошибку 500, теперь — аккуратную заглушку. Смысл тот же: интерпретатор PHP не смог выполнить код до конца.

Типичные причины:

• Конфликт или баг плагина — особенно после автообновления;
• Несовместимость с версией PHP — старый код не работает на PHP 8.2+;
• Ошибка в functions.php темы — например, после правки «на живую» через редактор;
• Нехватка памяти PHP — тяжёлый плагин упёрся в лимит;
• Повреждённые файлы — оборвавшееся обновление, сбой диска, взлом.

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

Шаг 1. Проверьте почту: режим восстановления

Вместе с заглушкой WordPress отправляет письмо на адрес администратора сайта. Тема — «Ваш сайт испытывает технические трудности». Внутри два важных пункта:

1. Название сбойного плагина или темы и текст самой ошибки — часто этого достаточно, чтобы понять причину.
2. Ссылка на режим восстановления (recovery mode). По ней вы попадёте в админку, где проблемное расширение уже приостановлено, — и сможете отключить его обычным способом.

Ссылка действует ограниченное время, поэтому не откладывайте. Если письма нет — проверьте спам и адрес администратора (он может быть старым, заведённым при установке сайта). Письма нет совсем? Идём дальше — сделаем всё то же самое вручную.

Шаг 2. Включите отладку и прочитайте ошибку

Подключитесь к сайту по FTP/SFTP или через файловый менеджер хостинга. Откройте wp-config.php в корне сайта и найдите строку define( 'WP_DEBUG', false );. Замените её на блок:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Что это даёт:

• WP_DEBUG_LOG — ошибки пишутся в файл wp-content/debug.log;
• WP_DEBUG_DISPLAY: false — ошибки не выводятся на страницы, посетители ничего лишнего не увидят.

Обновите сломанную страницу и откройте wp-content/debug.log. Последняя запись PHP Fatal error — ваша цель. В ней указан файл, где упал код: путь вида wp-content/plugins/имя-плагина/... прямо называет виновника.

После починки верните WP_DEBUG в false — держать отладку включённой на боевом сайте не нужно.

Шаг 3. Отключите виновника

Если админка доступна: «Плагины» → деактивировать сбойный плагин. Всё.

Если админка тоже падает, отключайте через файлы. По FTP зайдите в wp-content/plugins/ и переименуйте папку плагина, например woo-super-addon → woo-super-addon.off. WordPress не найдёт файлы и деактивирует плагин сам. Сайт должен ожить сразу.

Не знаете, какой плагин виноват, а лог молчит? Переименуйте всю папку plugins в plugins.off — отключатся все. Сайт заработал — значит, дело точно в плагинах. Верните папке имя plugins, а затем включайте плагины в админке по одному, проверяя сайт после каждого. На каком сломается — тот и виновник.

Через WP-CLI (если есть SSH-доступ) всё быстрее:

# посмотреть список и статусы
wp plugin list

# отключить один плагин
wp plugin deactivate woo-super-addon

# отключить все разом
wp plugin deactivate --all

WP-CLI работает даже тогда, когда сайт и админка лежат, — это самый надёжный инструмент для таких ситуаций.

Шаг 4. Проверьте тему

Если плагины ни при чём, переключитесь на стандартную тему. В админке: «Внешний вид» → «Темы». Без админки — через WP-CLI:

wp theme activate twentytwentyfive

Или по FTP: переименуйте папку активной темы в wp-content/themes/ — WordPress откатится на стандартную, если она установлена. Сайт ожил на стандартной теме — ошибка в вашей. Чаще всего ломают functions.php при ручных правках: одна лишняя скобка — и фатальная ошибка. Верните последнюю правку назад или восстановите файл из бэкапа.

Шаг 5. Память и версия PHP

Если в логе Allowed memory size ... exhausted — PHP упёрся в лимит памяти. Поднимите его в wp-config.php (строка должна стоять выше комментария «Happy publishing»):

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

Если хостинг режет память на своём уровне, констант мало — поднимите memory_limit в панели хостинга или через .htaccess/php.ini.

Если в логе ошибки вида Uncaught Error: Call to undefined function или упоминание устаревших функций — проверьте версию PHP в панели хостинга. Современному WordPress нужен PHP 8.2+, но старые плагины могут не уметь работать с новыми версиями. Здесь два пути: откатить PHP на шаг назад как временную меру и обновить/заменить несовместимый плагин как постоянную.

Шпаргалка: как читать debug.log

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

Строка в логе	Что это значит	Что делать
Allowed memory size of N bytes exhausted	Кончилась память PHP	Поднять WP_MEMORY_LIMIT, найти прожорливый плагин
Call to undefined function ...	Код зовёт несуществующую функцию	Выключен плагин-зависимость либо код несовместим с PHP — обновить плагин
Cannot redeclare function ...	Функция объявлена дважды	Конфликт двух плагинов или плагина и темы — отключить один
syntax error, unexpected ...	Опечатка в PHP-коде	Откатить последнюю правку файла из ошибки
Class "..." not found	Не подгрузился класс	Битое обновление плагина — переустановить его
Maximum execution time exceeded	Скрипт работал дольше лимита	Поднять max_execution_time, искать медленный код

Путь к файлу в конце строки — главная подсказка: plugins/ — виноват плагин, themes/ — тема, корень или wp-includes/ — возможно, повреждено ядро (лечится переустановкой WordPress той же версии: «Обновления» → «Переустановить», файлы контента не пострадают).

Частный случай: ошибка после переноса сайта

Если критическая ошибка появилась сразу после миграции на другой хостинг, к обычным подозреваемым добавляются три специфических. Во-первых, версия PHP на новом сервере может отличаться от старой — сверьте и выставьте ту же. Во-вторых, при переносе часто теряются файлы: сравните размер папок wp-content/plugins и wp-content/themes со старым хостингом, недокачанный плагин падает фаталом. В-третьих, кеш старого окружения: удалите содержимое wp-content/cache/ и файл advanced-cache.php из wp-content/, если он остался от плагина кеширования, которого больше нет, — осиротевшие drop-in-файлы ломают сайт именно после переездов.

Если ничего не помогло

• Посмотрите лог ошибок хостинга. Панели показывают error_log сервера — там видны ошибки, случившиеся до загрузки WordPress. Подробнее о серверных логах — в статье про ошибку 500.
• Восстановите сайт из бэкапа. Если ошибка появилась после конкретного обновления, откат — быстрый способ вернуть сайт, а разбираться можно уже на копии.
• Проверьте сайт на взлом. Изменённые файлы ядра, незнакомые плагины, свежие PHP-файлы в uploads/ — повод для полноценной проверки на вредоносный код.
• Напишите в поддержку хостинга. Иногда причина на их стороне: сбой PHP-FPM, ограничения после смены тарифа, поломка после миграции.

Как не встретить эту ошибку снова

Три привычки закрывают большинство сценариев. Первая — бэкапы до любого обновления: автоматические, с хранением вне хостинга. Вторая — тестовая копия сайта (staging): обновления плагинов, темы и PHP сначала обкатываются там. Третья — минимум плагинов: каждый установленный плагин — это чужой код на вашем сайте, и чем его меньше, тем меньше точек отказа. А заодно и сайт быстрее — про это у нас отдельный чек-лист по ускорению.

Критическая ошибка WordPress выглядит пугающе, но лечится по алгоритму: письмо → лог → плагины → тема → память и PHP. Обычно на всё уходит 10–20 минут.