На сайте критическая ошибка WordPress: как вернуть сайт в строй

Если на сайте критическая ошибка WordPress выскочила посреди рабочего дня, паника - нормальная первая реакция, но чинится это в большинстве случаев за 15-30 минут. За практику веб-разработки я разбирал десятки таких обвалов: от конфликта плагина после автообновления до банального исчерпания памяти PHP на дешёвом тарифе хостинга. Дальше подробно разберу, что означает это сообщение, как включить диагностику и вернуть сайт в рабочее состояние своими руками, не трогая резервные копии вслепую.

Что значит «На сайте произошла критическая ошибка» в WordPress

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

Одновременно с показом ошибки WordPress отправляет письмо на почту администратора сайта со ссылкой вида wp-login.php?action=recovery - через неё можно один раз войти в «режим восстановления» и увидеть, какой именно плагин или тема вызвали сбой, без правки файлов руками. Письмо стоит проверить в первую очередь, оно нередко экономит десять минут поиска.

Причины у сообщения обычно одни и те же:

• плагин обновился и перестал совмещаться с текущей версией PHP или темы;
• хостинг сам поднял версию PHP, а старый код плагина использует устаревшие функции;
• в functions.php темы осталась синтаксическая ошибка после правки;
• исчерпан лимит памяти PHP (memory_limit) на тарифе хостинга;
• повреждены файлы ядра из-за неудачного обновления или сбоя при заливке файлов.

Пятисотая ошибка сервера (500 Internal Server Error) - это смежная, но другая история: её чаще выдаёт сам сервер из-за .htaccess или настроек PHP-FPM, а не сама WordPress. Если видите именно текст «На сайте произошла критическая ошибка», значит движок успел загрузиться и упал уже на своей логике, и это упрощает диагностику.

Первым делом: включаем диагностику через WP_DEBUG

Стандартное сообщение ничего не говорит о причине специально - это защита от утечки путей на сервере и версий ПО чужим глазам. Чтобы увидеть реальный текст фатальной ошибки с именем файла и номером строки, включаю отладку через wp-config.php.

Подключаюсь по FTP или через файловый менеджер хостинга (в cPanel, ISPmanager или Timeweb это обычно раздел «Файлы»), открываю wp-config.php в корне сайта и меняю три строки: define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true); и define('WP_DEBUG_DISPLAY', false);.

WP_DEBUG_DISPLAY специально ставлю в false, чтобы текст ошибки не всплывал прямо на экране у живых посетителей, пока сайт лежит - вместо этого весь текст падает в файл wp-content/debug.log. Открываю его и ищу последнюю запись с пометкой Fatal error: там будет точный путь к файлу и строка, на которой всё упало. Обычно это что-то вроде /wp-content/plugins/имя-плагина/файл.php on line 214, и дальше уже понятно, с каким плагином работать.

Если нет доступа даже к файловому менеджеру

При наличии SSH-доступа лог можно посмотреть прямо из консоли, не заходя в файловый менеджер:

tail -n 50 wp-content/debug.log

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

Как найти виновника: плагины, тема или ядро WordPress

Когда в логе видно имя плагина, дальше просто: отключаю его. Если админка не открывается вообще, единственный рабочий способ - зайти по FTP или SSH и переименовать папку с плагинами:

mv wp-content/plugins wp-content/plugins_off

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

Из практики: у одного интернет-магазина на WooCommerce обновление плагина эквайринга Т‑Банка совпало со сменой версии PHP на хостинге, и старая сборка плагина падала с ошибкой Call to undefined method на этапе оформления заказа - помогло обновление плагина до версии, совместимой с PHP 8.1. Похожая история была с модулем доставки СДЭК: после обновления ядра WooCommerce плагин продолжал обращаться к устаревшему хуку, которого в новой версии уже не было, и checkout падал с критической ошибкой у всех покупателей разом.

Если отключение всех плагинов не помогло, следующий подозреваемый - тема. Переключаю на стандартную (Twenty Twenty-Four или любую другую) тем же способом: переименовываю папку активной темы в wp-content/themes, и WordPress откатится на дефолтную автоматически. Если и это не спасло, дело в ядре: имеет смысл перезалить файлы wp-admin и wp-includes из чистого дистрибутива той же версии WordPress, не трогая wp-content.

Восстанавливаем сайт через файловый менеджер и базу данных

Если переименование папки с плагинами не даёт эффекта, а сайт продолжает падать, причина может быть глубже - в базе данных или настройках PHP.

Через phpMyAdmin (открывается в панели хостинга) можно отключить плагины на уровне базы, без доступа к файлам: захожу в таблицу wp_options, нахожу строку с полем option_name = active_plugins и очищаю её значение на a:0:{}. Это программно отключит все плагины сразу.

Если дело в нехватке памяти PHP, в логе будет фраза вроде Allowed memory size of 134217728 bytes exhausted. Поднимаю лимит в том же wp-config.php строкой define('WP_MEMORY_LIMIT', '256M');, а если хостинг режет лимит на уровне сервера, дополнительно прошу поддержку хостинга поднять memory_limit в php.ini или переключаю тариф.

Отдельно проверяю .htaccess: если после всех манипуляций сайт вместо критической ошибки WordPress начал отдавать 500‑ю без пояснений, скорее всего файл повреждён. Переименовываю .htaccess во что угодно другое, затем захожу в Настройки → Постоянные ссылки в админке и просто пересохраняю их без изменений - WordPress создаст файл заново со стандартными правилами.

Когда чинить самостоятельно рискованно

Ручной перебор плагинов нормально работает для блога или визитки, где простой в час-два не критичен. Для интернет-магазина или сервиса с живыми заказами каждая минута падения - это упущенные продажи, и здесь я обычно советую не экспериментировать вслепую, а параллельно поднимать сайт из бэкапа и уже на копии искать причину.

Отдельно осторожным стоит быть, если критическая ошибка вылезла сразу после переноса сайта на новый хостинг: там частая причина - несовпадение версий PHP или отсутствующие серверные расширения (imagick, curl, mbstring), и без доступа к консоли хостинга такое не продиагностируешь до конца. То же самое с сайтами, где в functions.php темы годами копился самописный код: видел случаи, когда правки без резервной копии превращали получасовой ремонт в восстановление сайта из последнего рабочего архива.

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

Профилактика: как не словить критическую ошибку снова

Полностью застраховаться от фатальных ошибок нельзя - обновления плагинов пишут живые люди, и баги всё равно проскакивают. Но частоту таких инцидентов реально снизить в разы:

• держу резервную копию перед каждым крупным обновлением - плагины вроде UpdraftPlus делают это в одно нажатие, а восстановление из архива занимает пять минут против нескольких часов ручного ремонта;
• тестирую обновления плагинов сначала на staging-копии сайта, а не сразу на боевом домене;
• фиксирую версию PHP на хостинге вручную и не даю ей меняться автоматически при плановых апдейтах серверного софта;
• отключаю автообновления для крупных плагинов вроде WooCommerce и модулей оплаты, обновляю их вручную в спокойное время, не в пиковые часы продаж;
• настраиваю внешний мониторинг доступности сайта с уведомлением в Telegram - собираю такую связку в n8n за пару часов, и о падении узнаю за минуту, а не когда об этом напишет клиент.

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

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

Почему на сайте появляется критическая ошибка WordPress после обновления плагина?

Чаще всего плагин обновился до версии, которая требует более новую (или, наоборот, несовместима со старой) версию PHP, WordPress или другого плагина, от которого зависит. Разработчики плагинов тестируют совместимость не на всех конфигурациях хостинга, поэтому на конкретном тарифе может не хватать серверного расширения или включённой функции PHP, из-за чего код падает с фатальной ошибкой.

Можно ли восстановить сайт без доступа к админке?

Да, через FTP или файловый менеджер хостинга: переименование папки с плагинами или темой в wp-content возвращает сайт к жизни, даже если в панель WordPress зайти невозможно. Для более глубоких случаев подключаюсь через phpMyAdmin и меняю нужные значения прямо в базе данных, не открывая wp-admin вообще.

Сколько стоит исправление критической ошибки на WordPress-сайте у разработчика?

Разовая диагностика и устранение обычно укладываются в стоимость консультации от 3 000 ₽, если причина стандартная - конфликт плагина или нехватка памяти PHP. Для сайтов на постоянном сопровождении такие случаи закрываются техподдержкой от 15 000 ₽/мес без отдельного счёта за каждый инцидент.

Как понять, какой именно плагин или тема вызвали ошибку?

Самый точный способ - включить WP_DEBUG_LOG в wp-config.php и посмотреть файл wp-content/debug.log: там будет указан конкретный файл и номер строки, на которой упал PHP. Если лог недоступен, помогает последовательное отключение плагинов через переименование их папок по FTP, пока сайт не восстановится.