Критическая ошибка WordPress возникает, когда сайт не может корректно выполнить PHP-код и останавливает загрузку страницы. Чаще всего причина связана с конфликтом плагина, темой, обновлением WordPress, несовместимой версией PHP или нехваткой памяти на хостинге.
Если WordPress пишет «На сайте возникла критическая ошибка» или показывает белый экран, ниже вы найдете пошаговую инструкцию, как определить причину, отключить проблемный плагин или тему и восстановить работу сайта.
Белый экран WordPress (WSOD) — это тоже критическая ошибка
Иногда вместо рамки с текстом WordPress показывает просто пустую белую страницу — без ошибок, без предупреждений. Это так называемый «белый экран смерти» (WSOD).
По сути, это та же самая критическая ошибка WordPress, только в старом виде. Раньше движок просто молча «падал», не объясняя причину. В новых версиях WordPress стал умнее и чаще показывает сообщение о критической ошибке и присылает письмо администратору.
Причины у белого экрана и критической ошибки одинаковые:
— конфликт плагинов
— ошибка в теме
— нехватка памяти
— несовместимость с версией PHP
И главное — способы восстановления полностью совпадают.
Если ты видишь белый экран без текста, выполняй все шаги ниже в этой инструкции — они подходят и для WSOD, и для сообщения «На сайте возникла критическая ошибка».

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

Критическая ошибка — это лишь симптом.
На практике за ней чаще всего стоят проблемы с плагинами, темой или PHP, которые разбираются в пошаговой диагностике WordPress.
1. Самый быстрый способ: «Режим восстановления»
Начиная с версии 5.2, WordPress стал умнее, когда случается критическая ошибка, он пытается отправить тебе «спасательное письмо».
Что делаем:
- Открывай почту, которая привязана к аккаунту администратора;
- Ищи письмо с темой «Ваш сайт… Технические неполадки»;
- Внутри будет ссылка и она волшебная — позволяет войти в админку в «Режиме восстановления» (Recovery Mode).
В этом режиме WordPress сам отключит сломанный плагин только для тебя. Остальные посетители всё еще будут видеть ошибку, но ты сможешь зайти в раздел «Плагины» и удалить виновника.

Письмо от WordPress о критической ошибке со ссылкой входа в режим восстановленияЕсли письма нет
Бывает, что почта на хостинге не настроена, и письмо не пришло. Можно попробовать вызвать этот режим вручную.
Добавь к адресу своей админки хвост: ?action=enter_recovery_mode.
То есть ссылка должна выглядеть так: https://твои-сайт.ru/wp-login.php?action=enter_recovery_mode
Иногда это срабатывает и пускает в панель, даже без токена из письма.
2. Узнаем причину ошибки (Диагностика)
Если в админку не пускает, нам нужно понять, кто именно сломал сайт. По умолчанию WordPress скрывает текст ошибки, чтобы не пугать посетителей. Нам нужно его увидеть.
Что делаем:
Заходим в Файловый менеджер на хостинге (или подключаемся через FTP).
В корневой папке сайта находим файл wp-config.php, открываем его и редактируем.
Ищем строчку:
define( 'WP_DEBUG', false ); Нам нужно поменять false на true и добавить еще пару строк, чтобы ошибки писались в специальный файл, а не вываливались на экран посетителям.
Замени ту строку на этот блок:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); 
Включение режима отладки WP_DEBUG в файле wp-config.phpЧто должно получиться
Теперь зайди на свой сломанный сайт и просто обнови страницу, визуально ничего не изменится,
но в папке /wp-content/ появится новый файл debug.log.
Открой его и в последних строчках будет написано что-то вроде:
PHP Fatal error: ... in .../wp-content/plugins/bad-plugin/index.php Слово Fatal error указывает на причину. А путь покажет, какой плагин (в примере — bad-plugin) виноват.
3. Отключаем виновника через хостинг
Теперь мы знаем врага в лицо (или просто подозреваем, что это плагин). Удалять его сразу не обязательно — достаточно «выключить» его через файлы.

Если ты знаешь, какой плагин сломался
- Иди в папку
/wp-content/plugins/; - Найди папку этого плагина.
Переименуй название папки плагина виновника, например, добавь к названию _off.
Было: PluginBad → Стало: PluginBad_off.

Как только ты переименуешь папку, WordPress «потеряет» этот плагин и отключит его, сайт должен заработать.
Если ты НЕ знаешь, кто виноват
Действовать нужно массово и отключаем всё сразу, для этого поднимись выше, в папку /wp-content/ и переименуй папку plugins в plugins_old.
Попробуй открыть сайт.
Если сайт открылся — поздравляю, дело точно в одном из плагинов.
Теперь верни папке имя plugins, заходи внутрь и переименовывай папки плагинов по одной (или группами), пока не найдешь того, кто ломает сайт.
Важно: То же самое касается и тем. Если переименование плагинов не помогло, иди в /wp-content/themes/ и переименуй папку своей активной темы. WordPress автоматически попытается включить стандартную тему (если она установлена).
4. Увеличиваем лимит памяти
Часто критическая ошибка возникает банально из-за того, что тяжелому плагину (например, Elementor или WooCommerce) не хватило оперативной памяти для выполнения скрипта.
Что делаем:
- Снова открываем файл
wp-config.php. - Находим место перед надписью «That’s all, stop editing».
Вставляем строку:
define( 'WP_MEMORY_LIMIT', '512M' ); 
Увеличение лимита памяти WordPress до 512M через wp-config.php👉 Если сайт после этого всё равно не открывается и вылетает ошибка сервера, смотри отдельную инструкцию — ошибка 500 в WordPress: как исправить.
5. Если ничего не помогло: Откат (Бэкап)
Если ты перепробовал всё выше, а сайт всё равно лежит — время доставать «тяжелую артиллерию».
Что делаем:
- Заходи в панель управления хостингом;
- Ищи раздел «Резервные копии» (Backup);
- Выбери дату, когда сайт точно работал;
- Восстанови файлы сайта и базу данных одновременно.
⚠️ Важно:
Если восстановить только файлы или только базу — появятся новые ошибки. Если сомневаешься в своих навыках, то напиши в службу поддержки хостинга.
6. Завершаем ремонт и убираем за собой
Если ты дошёл до этого места — значит сайт уже должен работать.
В большинстве случаев критическая ошибка WordPress связана с проблемным плагином, темой, нехваткой памяти или несовместимостью PHP.
Если ошибка повторилась через день или два — почти всегда виноват тот же плагин или несовместимость с версией PHP на хостинге. В таком случае его лучше заменить, а не «терпеть».
Совет на будущее:
— держи включённые автоматические бэкапы на хостинге
— не обновляй плагины и темы “всё сразу”, особенно на рабочем сайте
— если видишь критическую ошибку — сначала отключай плагины, а не лезь в базу данных
Сохрани эту инструкцию. Когда сайт падает — времени гуглить нет, а здесь весь рабочий алгоритм в одном месте.
👉 Если сайт ломается не впервые, начните с пошаговой диагностики WordPress, чтобы быстро понять причину сбоя.