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

Коротко

Если на экране вместо страниц появилась надпись «На сайте возникла критическая ошибка», WordPress поймал фатальную ошибку PHP и остановил выполнение кода. Чаще всего виноваты плагин, тема или несовместимость с версией PHP. Данные сайта при этом, как правило, целы: записи, заказы и настройки лежат в базе и никуда не делись.

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

Ситуация	Вероятная причина	Первое действие
Сообщение о критической ошибке после обновления	Плагин или тема несовместимы с ядром или PHP	Открыть ссылку из письма режима восстановления
Письма нет, админка не открывается	Фатальная ошибка при загрузке любых страниц	Отключить плагины через FTP или файловый менеджер
Ошибка только на части страниц	Сломан шаблон или шорткод конкретного блока	Включить журнал ошибок и открыть проблемную страницу
«Ошибка установки соединения с базой данных»	Неверные доступы, упавший MySQL, повреждённые таблицы	Проверить wp-config.php и статус базы у хостинга

Основная мысль

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

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

Хаотичные действия обычно всё усложняют. Переустановка ядра, откат всего сайта из старой копии или смена темы «наугад» могут удалить свежие заказы и заявки или добавить новую ошибку поверх старой. Правильная последовательность — диагностика, точечное отключение виновника, восстановление работы, затем исправление.

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

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

Как работает режим восстановления

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

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

Почему письмо может не прийти

• На сайте не настроена отправка почты, и письма от WordPress не доходят вообще или попадают в спам.
• Адрес администратора в настройках давно не используется.
• Ошибка возникает так рано при загрузке, что механизм перехвата не успевает сработать.
• Письмо уже отправлялось недавно: WordPress не шлёт уведомление при каждом повторе ошибки, чтобы не засыпать почту.

Адрес для таких писем можно переопределить константой RECOVERY_MODE_EMAIL в wp-config.php. Это полезно, если админский ящик принадлежит бывшему сотруднику или подрядчику.

Типичные причины критической ошибки WordPress

Ошибка почти никогда не появляется без внешнего события. Ей предшествует обновление, правка кода, смена версии PHP или перенос. Ниже — основные сценарии, от самых частых к более редким.

WordPress: ошибка плагинов после обновления

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

Тема и дочерняя тема

Правка functions.php через встроенный редактор — классический способ положить сайт одной пропущенной скобкой. Второй сценарий — обновление родительской темы, после которого шаблоны дочерней темы вызывают удалённые функции. Третий — купленная тема со встроенными плагинами-компаньонами, которые давно не обновлялись.

Версия PHP

Хостинги регулярно выводят из эксплуатации старые версии PHP и переключают сайты на новые. Код, написанный несколько лет назад, может использовать устаревшие конструкции, которые в новой версии вызывают фатальную ошибку. Обратная ситуация тоже бывает: свежий плагин требует более новой версии PHP, чем стоит на сервере.

Нехватка памяти и ресурсов

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

Повреждённые файлы и взлом

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

Как вернуть сайт: пошаговая инструкция

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

Шаг 1. Проверить почту администратора

Найдите письмо от WordPress о технической проблеме на сайте, в том числе в папке спама. Перейдите по ссылке режима восстановления, откройте раздел «Плагины» или «Внешний вид → Темы» и деактивируйте указанное расширение. Затем выйдите из режима восстановления и проверьте сайт в другом браузере или в режиме инкогнито.

Шаг 2. Отключить плагины через FTP

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

Если виновник уже известен из журнала, достаточно переименовать только его папку внутри wp-content/plugins. Это мягче: остальные плагины продолжат работать, и сайт не потеряет формы, кеширование и оплату.

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

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

Шаг 4. Включить журнал ошибок

Когда причина неочевидна, включите запись ошибок в файл. В wp-config.php, выше строки с комментарием о завершении редактирования, задайте константы:

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

Ошибки начнут записываться в wp-content/debug.log, а посетители их не увидят. Откройте сломанную страницу и посмотрите последние строки файла: там будет путь к файлу и номер строки. После диагностики верните WP_DEBUG в false и удалите debug.log, потому что он раскрывает пути и детали сервера.

Шаг 5. Использовать WP-CLI, если есть SSH

На VPS и хостингах с SSH-доступом удобнее работать через WP-CLI. Он позволяет отключить плагины, не открывая админку:

wp plugin list
wp plugin deactivate --all
wp plugin deactivate имя-плагина --skip-plugins

Флаг —skip-plugins не даёт загрузиться сломанным плагинам во время выполнения самой команды. Аналогично работает —skip-themes для проблемной темы.

Шаг 6. Откатить версию или PHP

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

Ошибка базы данных WordPress

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

Ошибка соединения с базой данных WordPress: причины

Причина	Как проверить	Что сделать
Неверные доступы в wp-config.php	Сравнить DB_NAME, DB_USER, DB_PASSWORD, DB_HOST с данными в панели хостинга	Исправить значения или сбросить пароль пользователя базы
Сервер MySQL недоступен	Посмотреть уведомления и статус услуг в панели хостинга	Написать в поддержку хостинга
Превышен лимит соединений или ресурсов	Ошибка появляется в часы пик и исчезает сама	Кеширование, оптимизация запросов, тариф мощнее
Повреждены таблицы	Сообщения о повреждённых таблицах в журнале	Восстановить таблицы средствами хостинга или WordPress

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

Восстановление повреждённых таблиц

В WordPress есть встроенный инструмент восстановления базы. Для его включения в wp-config.php добавляют строку:

define( 'WP_ALLOW_REPAIR', true );

После этого инструмент доступен по адресу /wp-admin/maint/repair.php даже без авторизации. Именно поэтому константу нужно удалить сразу после восстановления. Альтернатива — проверка и восстановление таблиц через phpMyAdmin в панели хостинга.

Другие частые ошибки WordPress

Критическая ошибка — не единственная, с которой сталкиваются владельцы. Ниже — короткий справочник по остальным ошибкам WordPress, которые встречаются чаще всего.

Белый экран без сообщения

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

Сайт застрял в режиме обслуживания

WordPress на время обновления создаёт в корне файл .maintenance. Если обновление прервалось, файл остаётся, и сайт показывает сообщение о техническом обслуживании. Удалите .maintenance и проверьте, до конца ли обновились плагины и ядро.

Ошибки 500, 502 и 503

Эти коды формирует сервер, и причины у них шире, чем у критической ошибки PHP: перегрузка, лимиты тарифа, неверная связка nginx и PHP-FPM. Начинают с журнала ошибок в панели хостинга и уведомлений о работах на сервере.

Сломанная вёрстка после обновления

Сайт открывается, но блоки съехали, пропали стили или перестали работать слайдеры. Это не фатальная ошибка, а конфликт скриптов, кеширования или минификации. Начинают с очистки кеша плагина оптимизации и CDN, затем отключают объединение CSS и JavaScript.

Как обновлять WordPress, чтобы ошибка не повторилась

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

Порядок безопасного обновления

1. Сделать копию. Файлы и база, с сохранением вне сервера сайта.
2. Прочитать список изменений. На странице плагина обычно указаны минимальные версии WordPress и PHP и важные изменения.
3. Обновить тестовую копию. Многие хостинги умеют создавать её из панели, иначе её разворачивают на поддомене с закрытым доступом.
4. Проверить ключевые сценарии. Главная, каталог, карточка товара, корзина, оформление заказа, формы заявок, вход в личный кабинет.
5. Обновить рабочий сайт в тихие часы. По одному расширению, с проверкой после каждого.
6. Посмотреть журнал ошибок. Даже если сайт открывается, в debug.log могут появиться предупреждения, которые позже станут фатальными.

Автообновления: включать или нет

Автоматические обновления безопасности ядра обычно оставляют включёнными: это небольшие исправления с низким риском. С плагинами сложнее. Автообновление мелких и хорошо поддерживаемых расширений снижает риск взлома, а для WooCommerce, платёжных модулей, конструкторов страниц и интеграций с 1С надёжнее ручной процесс через тестовую копию. Если сайт дорабатывался под вашу задачу, его код тоже нужно учитывать: доработки в теме могут конфликтовать с новой версией плагина.

Сценарии из практики

Ситуации ниже собирательные, но хорошо показывают логику поиска причины.

Обновили всё одной кнопкой

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

Хостинг сменил версию PHP

Корпоративный сайт упал в выходные без каких-либо действий со стороны владельца. В журнале — фатальная ошибка в файле темы, написанной много лет назад. Хостинг перевёл аккаунт на новую версию PHP. Временно вернули прежнюю версию, затем исправили устаревшие конструкции в теме и перешли на актуальный PHP.

Правка functions.php из админки

Администратор добавил в functions.php фрагмент кода из интернета через «Внешний вид → Редактор файлов темы» и пропустил точку с запятой. Сайт и админка перестали открываться. Исправили файл по FTP за пару минут, а редактор файлов отключили константой DISALLOW_FILE_EDIT, чтобы история не повторилась.

На чём опасно экономить

Длинные простои случаются не из-за сложности ошибки, а из-за отсутствия базовой гигиены. Вот что обходится дороже всего.

Типичные ошибки владельцев

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

Чек-лист профилактики

• Автоматические копии файлов и базы, хранящиеся вне сервера сайта.
• Проверка восстановления из копии хотя бы раз в квартал.
• Тестовая копия сайта для обновлений ядра, темы и плагинов.
• Обновление плагинов по одному с проверкой ключевых страниц.
• Актуальная версия PHP, которую поддерживают ядро и все расширения.
• Одна стандартная тема WordPress, установленная про запас.
• Редактор файлов в админке отключён константой DISALLOW_FILE_EDIT.
• Рабочий адрес администратора и настроенная отправка писем через SMTP.
• Мониторинг доступности и регулярный просмотр раздела диагностики в Яндекс Вебмастере.
• Записанные доступы к хостингу, FTP, базе данных и админке.

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

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

Что делать, если на сайте возникла критическая ошибка, а доступа к админке нет?

Отключите плагины переименованием папки wp-content/plugins через FTP или файловый менеджер хостинга. Если не помогло, переименуйте папку активной темы. Затем включите журнал ошибок, чтобы найти точную причину.

WordPress критическая ошибка: пропадут ли данные сайта?

Обычно нет. Записи, страницы, заказы и настройки хранятся в базе данных, а фатальная ошибка PHP её не затрагивает. Риск потери появляется при необдуманном откате из старой копии.

На сайте произошла критическая ошибка — это то же самое?

Да, это та же ошибка в другой формулировке. Текст сообщения зависит от версии WordPress и языкового пакета.

Где найти письмо режима восстановления?

Оно приходит на адрес администратора из «Настройки → Общие». Проверьте папку спама. Если адрес устарел, после восстановления сайта замените его или задайте RECOVERY_MODE_EMAIL в wp-config.php.

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

Письмо режима восстановления и файл wp-content/debug.log указывают путь к файлу. Имя папки в пути после wp-content/plugins — это и есть виновник.

WordPress: ошибка плагинов после обновления: откатывать или ждать исправления?

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

Что означает ошибка соединения с базой данных WordPress?

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

Можно ли самому исправить ошибку базы данных WordPress?

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

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

Чаще всего хостинг сменил версию PHP, закончилось место на диске, сработал плагин с автообновлением или сайт был заражён. Журнал ошибок покажет точную причину.

Сколько стоит устранение критической ошибки?

Зависит от причины. Конфликт одного плагина обычно устраняется за час-два, несовместимость темы с новым PHP или последствия взлома требуют больше времени. Поддержка сайта у меня стоит от 2 000 ₽ в час.

Итог

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

Чтобы такие эпизоды случались реже, нужны копии вне сервера, тестовая среда для обновлений, актуальный PHP, минимум лишних плагинов и рабочая почта администратора. Отдельная история — ошибка соединения с базой данных: её чаще решают доступы в wp-config.php и поддержка хостинга.

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