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

Это значит, что PHP получил фатальную ошибку при сборке страницы, а WordPress перехватил её до того, как появился белый экран. Формулировка намеренно расплывчатая, чтобы посетители не видели пути к файлам и код. Настоящая ошибка — с именем файла и номером строки — записана в лог на сервере.

Где находится лог критической ошибки WordPress?

Если в wp-config.php вы включили WP_DEBUG и WP_DEBUG_LOG, WordPress пишет в wp-content/debug.log. Если они выключены, ошибка всё равно попадает в PHP-лог хостинга — обычно он доступен в панели управления в разделе логов или журналов ошибок. Проверьте оба места, прежде чем решить, что ничего не записалось.

Почему не пришло письмо о режиме восстановления WordPress?

Письмо уходит на административный адрес сайта из настроек, а не на адрес, под которым вы входите, и отправляет его тот же самый PHP, который только что упал, поэтому доставка часто срывается. Виртуальные хостинги вдобавок блокируют исходящую почту без SMTP. Проверьте спам, а затем не ждите письмо и отключите плагины через SFTP.

Как починить критическую ошибку, если вход в wp-admin недоступен?

Подключитесь по SFTP или через файловый менеджер хостинга и переименуйте папку wp-content/plugins в plugins-off. Это разом отключает все плагины и почти всегда возвращает доступ в админку. Верните имя обратно и включайте плагины по одному, пока ошибка не вернётся — тогда виновник найден.

Может ли обновление версии PHP вызвать критическую ошибку в WordPress?

Да, и это одна из самых частых причин. Хостинги повышают версию PHP автоматически, а старый код плагина или темы с удалённым синтаксисом падает сразу же. В записи лога обычно указан конкретный файл внутри wp-content. Откат PHP в панели хостинга подтверждает диагноз, но это временное решение.

Значит ли критическая ошибка, что сайт взломали?

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

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

Это сообщение означает, что PHP получил фатальную ошибку при сборке страницы, а WordPress перехватил её раньше, чем она превратилась в пустой белый экран. Ошибка настоящая, конкретная и записанная — WordPress просто отказывается выводить её в браузер, потому что трассировка стека на публичной странице раскрывает пути к файлам и код любому посетителю.

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

Что происходит на самом деле

Начиная с WordPress 5.2 в ядро встроен обработчик фатальных ошибок. Когда PHP падает посреди запроса, обработчик подменяет вывод аварии вежливой общей фразой и — если ему удаётся определить виновный плагин или тему — пытается отправить администратору сайта письмо со ссылкой в режим восстановления.

Именно поэтому вместо старого «белого экрана смерти» вы видите это. Улучшение налицо, но диагностическая информация теперь по умолчанию скрыта. Существует три варианта сообщения:

Что вы видите	Где	О чём это говорит
«На сайте возникла критическая ошибка.»	Публичная часть, без авторизации	Произошла фатальная ошибка, подробностей наружу не выдано
Та же строка плюс «Узнайте больше об устранении неполадок в WordPress»	Публичная часть или wp-admin	Та же ошибка, WordPress предлагает страницу справочника
«…Проверьте почтовый ящик администратора сайта, там есть инструкции.»	Публичная часть	Обработчик считает, что письмо о восстановлении отправлено

Третий вариант — самый полезный. Он означает, что WordPress связал падение с конкретным плагином или темой и попытался дать вам вход.

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

WordPress отправляет ссылку восстановления на административный адрес сайта — тот, что указан в «Настройки → Общие», — а он часто отличается от адреса, под которым вы входите. Загляните в этот ящик и обязательно в спам.

В письме есть длинная ссылка, оканчивающаяся примерно на ?action=enter_recovery_mode. Переход по ней открывает wp-admin в режиме восстановления, где проблемный плагин или тема приостановлены и отмечены красным уведомлением сверху. Оттуда их можно отключить обычным способом.

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

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

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Шаг 2: прочитайте настоящую ошибку

Именно этот шаг превращает сломанный сайт в задачу на пять минут. Добавьте эти строки в wp-config.php выше строки о том, что дальше редактировать не нужно:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Значение false у WP_DEBUG_DISPLAY здесь принципиально: ошибка не попадает в браузер, но по-прежнему пишется на диск, так что во время отладки вы не показываете посетителям серверные пути.

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

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Путь к файлу и есть ответ. Если он ведёт в wp-content/plugins/, причина в этом плагине. Если в wp-content/themes/ — виновата тема, и очень часто это что-то, недавно вставленное в functions.php.

Если debug.log не появился, каталог может быть недоступен для записи, либо плагин безопасности перенаправил логирование в другое место. Тогда смотрите PHP-лог хостинга — почти в каждой панели управления есть раздел «Логи» или «Журнал ошибок», и та же фатальная ошибка будет там с отметкой времени.

Вставьте запись в расшифровщик логов ошибок WordPress, чтобы перевести формулировку PHP в понятное объяснение и понять, какой файл смотреть первым.

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

Шаг 3: верните себе доступ в wp-admin

Если wp-admin тоже не открывается, а письмо не пришло, отключите все плагины на уровне файловой системы. Подключитесь по SFTP (или через файловый менеджер хостинга) и переименуйте одну папку:

mv wp-content/plugins wp-content/plugins-off

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

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

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

Три причины, которые стоит знать

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

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

Нехватка памяти. В логе будет «Allowed memory size of X bytes exhausted». Поднять лимит в wp-config.php — разумный шаг:

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

Только честно оценивайте эффект: это снимает потолок, но не устраняет то, что съедало 256 МБ на отрисовке одной страницы. Если лимит приходится поднимать снова и снова, настоящая проблема в чём-то другом — обычно в импорте, конструкторе страниц или плохо написанном запросе.

Советы, которые можно спокойно игнорировать

«Просто увеличьте лимит памяти». Уместно, только если в логе действительно написано про исчерпание памяти. Иначе это ничего не меняет и лишь маскирует тот факт, что ошибку вы так и не прочитали.

«Переустановите ядро WordPress». Файлы ядра редко бывают причиной, а их замена съедает время, которого хватило бы на чтение одной строки лога.

«Отключите обработчик фатальных ошибок». Константа для этого существует, и в результате сырая ошибка будет печататься прямо на публичном сайте вместо перехваченной. Это раскрывает пути к файлам посетителям. Используйте WP_DEBUG_LOG с выключенным WP_DEBUG_DISPLAY — та же информация без утечки.

«Очистите кэш». Фатальная ошибка происходит в PHP раньше, чем кэширующий плагин успевает что-либо отдать. Если отдаётся закэшированная копия страницы с ошибкой, очистка помогает после устранения причины, но никогда вместо него.

Всё ещё не получается?

Если лог указывает на файл ядра, а не на что-то внутри wp-content, более вероятное объяснение — плагин, загруженный раньше и сломавший состояние, на которое ядро рассчитывает, а не повреждённое ядро. Отключите всё переименованием папки, убедитесь, что сайт грузится чисто, и возвращайте плагины по одному: последний включённый перед возвратом ошибки — тот, о котором нужно сообщить, приложив строку лога.