Белый экран и сообщение «На сайте возникла критическая ошибка» — это обновленная версия классического белого экрана смерти (White Screen of Death). Ситуация неприятная, особенно в разгар рабочего дня. Однако паниковать не стоит. В 95% случаев база данных и контент остаются целыми. Проблема вызвана сбоем PHP-скрипта в плагине или теме. Восстановить работу сайта можно буквально за 10–15 минут.

Шаг 0. Проверяем почту администратора и Recovery Mode

Начиная с версии 5.2, WordPress умеет изолировать фатальные сбои. Система автоматически переводит сайт в защищенный режим. На почту администратора отправляется системное письмо со специальной ссылкой для входа в Режим восстановления (Recovery Mode).

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

К сожалению, системное письмо доходит не всегда. На многих хостингах по умолчанию не настроена SMTP-почта, поэтому функция wp_mail() не срабатывает. На экране остается лишь надпись: «На сайте возникла критическая ошибка. Узнайте больше про решение проблем с WordPress». Если письма во входящих и в спаме нет, переходим к ручной диагностике.

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

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

Откройте файл wp-config.php в корневой директории сайта. Найдите строчку:

define('WP_DEBUG', false);

Замените ее на следующий блок кода:

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

Параметр WP_DEBUG запускает отладку. Строка WP_DEBUG_LOG включает запись всех сбоев в отдельный журнал. Параметр WP_DEBUG_DISPLAY => false обязателен: он скрывает технические данные от посетителей, сохраняя их в закрытый лог.

После сохранения файла обновите страницу сайта с ошибкой. Затем перейдите в директорию:

/wp-content/debug.log

Откройте этот файл и изучите последние строки. Ищите метку Fatal error. В этой строке всегда содержится путь к файлу сбоя, например:

PHP Fatal error: Uncaught Error: Call to undefined function elementor_pro_load() in /wp-content/plugins/old-plugin/main.php:42

В этом примере виновник очевиден — сторонний плагин. Остается просто отключить его.

Конфликты плагинов: критическая ошибка WordPress из-за Elementor

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

Отключить сбойный плагин без админки можно за четыре шага:

1. Откройте папку /wp-content/plugins/ через менеджер файлов или FTP.
2. Найдите каталог модуля, указанного в файле debug.log.
3. Переименуйте папку плагина (например, в elementor_OFF).
4. Обновите страницу сайта. Движок не найдет папку с прежним именем и автоматически деактивирует модуль.

Если ресурс снова доступен, обновите проблемное расширение до стабильной версии либо временно замените его альтернативой.

Обновление PHP и критическая ошибка на сайте WordPress

Вторая частая причина поломки — несовместимость версий PHP. Хостинг-провайдеры регулярно обновляют системное окружение в фоновом режиме. Старый код тем и расширений часто не поддерживает новые синтаксические стандарты.

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

Быстрое решение — зайти в панель хостинга (раздел «Версия PHP» или «PHP Selector»). Переключите версию на одну ступень назад, где сайт работал стабильно. Это оперативно восстановит проект. После этого обязательно обновите все темы и компоненты под актуальные версии PHP.

Нехватка оперативной памяти (Memory Limit)

Если в журнале вместо пути к плагину зафиксирована строка Allowed memory size exhausted, процессу банально не хватает RAM. Такое часто случается на проектах с тяжелыми фильтрами и большим каталогом WooCommerce.

Для исправления увеличьте лимит памяти движка. Вставьте строку в wp-config.php прямо перед фразой «That’s all, stop editing!»:

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

Если ошибка сохраняется, значит, ограничение установлено на уровне тарифного плана хостинга. В таком случае лимит нужно поднимать через панель хостера или тикет в техподдержку.

Что делать, если виноват не плагин, а тема

Иногда журнал указывает на директорию /wp-content/themes/. Это означает сбой в активной теме, дочернем шаблоне или файле functions.php.

В таком случае переименуйте папку активной темы по FTP. WordPress автоматически включит базовую системную тему оформления (например, Twenty Twenty-Four). Сайт заработает, а вы сможете спокойно локализовать синтаксическую ошибку в коде шаблона.

Чек-лист: как восстановить сайт за 10 минут

• Проверьте почту администратора на наличие ссылки в Recovery Mode.
• Включите WP_DEBUG и проверьте лог-файл debug.log.
• Найдите строчку Fatal error и определите сбойный компонент.
• Переименуйте папку проблемного плагина или темы по FTP.
• Проверьте версию PHP на сервере хостинга.
• При нехватке памяти пропишите WP_MEMORY_LIMIT 256M.
• Обязательно верните WP_DEBUG в значение false после починки, чтобы не переполнять диск логами.

Часто задаваемые вопросы

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

Почему системное письмо не пришло на почту администратора?
Если на сайте не настроен SMTP-сервер, стандартный почтовый шлюз хостинга блокирует отправку писем. В таком случае ориентируйтесь на ручной просмотр файла debug.log.

Как обезопасить проект от критических ошибок в будущем?
Отключите автоматическое обновление для крупных плагинов вроде WooCommerce и Elementor. Все апдейты проверяйте на тестовой staging-копии и настройте ежедневное резервное копирование базы данных.