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

Если WordPress показывает сообщение «На сайте возникла критическая ошибка», значит сайт остановил выполнение PHP-кода. Чаще всего причина в плагине, теме, обновлении WordPress, версии PHP, нехватке памяти или ошибке в файлах сайта.

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

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

Что означает критическая ошибка WordPress

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

Чаще всего это выглядит так:

• на сайте написано: «На сайте возникла критическая ошибка»;
• не открывается админка WordPress;
• после обновления появился белый экран;
• сайт выдаёт ошибку 500;
• часть сайта работает, а часть падает;
• пришло письмо WordPress о технической проблеме.

Обычно виноват не сам WordPress, а конкретный плагин, тема, несовместимая версия PHP или нехватка памяти на хостинге.

Быстрый порядок действий

Что произошло	Что проверить первым	Что делать
Пришло письмо о критической ошибке	Режим восстановления	Перейти по ссылке из письма и отключить проблемный плагин
Сайт упал после обновления плагина	Папку последнего обновлённого плагина	Переименовать папку плагина через FTP или файловый менеджер
Не понятно, какой плагин виноват	Все плагины	Переименовать папку wp-content/plugins
Плагины отключены, но ошибка осталась	Активную тему	Переименовать папку активной темы
Ошибка без понятной причины	debug.log и error_log	Включить WP_DEBUG_LOG и посмотреть последние строки
После обновления WordPress или PHP	Версию PHP	Сменить PHP на совместимую версию в панели хостинга
Ошибка про memory exhausted	Лимит памяти	Увеличить WP_MEMORY_LIMIT и memory_limit на хостинге
Ничего не помогает	Бэкап	Сначала восстановить файлы, базу — только при необходимости

Проверьте письмо WordPress о критической ошибке

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

Что сделать:

1. Откройте почту администратора WordPress.
2. Проверьте папки «Входящие» и «Спам».
3. Найдите письмо о технической проблеме на сайте.
4. Перейдите по ссылке восстановления.
5. Войдите в админку и отключите проблемный плагин или тему.

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

Если письмо не пришло

Письмо может не прийти, если на сайте не настроена отправка почты, письмо попало в спам или WordPress не смог определить источник ошибки.

Можно попробовать открыть режим восстановления вручную:

https://ваш-сайт.ru/wp-login.php?action=enter_recovery_mode

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

Отключите проблемный плагин через файловый менеджер

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

Что сделать:

1. Откройте файловый менеджер хостинга или подключитесь по FTP.
2. Перейдите в папку wp-content/plugins.
3. Найдите папку плагина, который обновляли или устанавливали последним.
4. Переименуйте её, добавив _off или _old.
5. Проверьте сайт.

Пример:

elementor → elementor_old
woocommerce → woocommerce_old
bad-plugin → bad-plugin_off

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

Отключите все плагины WordPress

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

Порядок действий:

1. Откройте папку wp-content.
2. Найдите папку plugins.
3. Переименуйте её в plugins_old.
4. Откройте сайт в браузере.

Если критическая ошибка пропала, виноват один из плагинов.

Не удаляйте папку plugins. Только переименовывайте. Так вы сохраните файлы плагинов и сможете быстро вернуть всё обратно.

Как найти виновный плагин

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

1. Переименуйте plugins_old обратно в plugins.
2. Зайдите в админку WordPress.
3. Откройте раздел «Плагины».
4. Включайте плагины по одному.
5. После каждого включения проверяйте сайт.
6. Плагин, после которого ошибка вернулась, и есть виновник.

Начинайте с тех плагинов, которые недавно обновлялись. Чаще всего критическая ошибка появляется именно после обновления плагина.

Подробный разбор есть здесь: как отключить все плагины WordPress без админки.

Проверьте активную тему WordPress

Если отключение плагинов не помогло, проверьте тему. Критическая ошибка может появиться после обновления темы, WordPress или версии PHP.

Что сделать:

1. Откройте папку wp-content/themes.
2. Найдите папку активной темы.
3. Переименуйте её, например добавьте _old.
4. Проверьте сайт и админку.

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

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

Включите лог ошибок WordPress

Если по плагинам и теме ничего не понятно, нужно увидеть текст ошибки. Для этого включим логирование в wp-config.php.

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

define( 'WP_DEBUG', false );

Замените её на блок:

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

Теперь откройте сайт, чтобы ошибка повторилась. После этого в папке wp-content должен появиться файл:

debug.log

Откройте его и посмотрите последние строки. Обычно там видно путь к файлу, который вызвал ошибку.

Пример ошибки плагина:

PHP Fatal error: ... /wp-content/plugins/bad-plugin/index.php

Пример ошибки темы:

PHP Fatal error: ... /wp-content/themes/theme-name/functions.php

Если в ошибке указан путь к plugins — проблема в плагине. Если указан путь к themes — проблема в теме.

Важно: после ремонта сайта верните WP_DEBUG обратно на false. Логи отладки не нужно держать включёнными постоянно.

Проверьте error_log на хостинге

Иногда WordPress не успевает записать ошибку в debug.log. Тогда смотрите логи хостинга.

В панели управления хостингом обычно есть разделы:

• «Журнал ошибок»;
• «Логи сайта»;
• error_log;
• «Ошибки PHP»;
• «Диагностика сайта».

Откройте последние ошибки и ищите строки с Fatal error, Parse error, Allowed memory size exhausted или путём к файлу внутри wp-content.

Лог хостинга часто сразу показывает точную причину: какой файл, какая строка и какой плагин или тема сломали сайт.

Проверьте версию PHP

Критическая ошибка WordPress часто появляется после смены версии PHP или после обновления WordPress, темы или плагина. Старый код может не работать на новой версии PHP, а свежие плагины могут не работать на слишком старой версии.

Что сделать:

1. Откройте панель управления хостингом.
2. Найдите раздел «Версия PHP» или «Настройки PHP».
3. Посмотрите, какая версия PHP сейчас включена.
4. Попробуйте переключиться на другую поддерживаемую версию.
5. Очистите кэш и проверьте сайт.

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

Не оставляйте сайт надолго на устаревшей PHP. Это временный способ вернуть доступ, а не постоянное решение.

Увеличьте лимит памяти WordPress

Если в ошибке есть фраза Allowed memory size exhausted, сайту не хватает памяти для выполнения PHP-кода. Часто такое бывает с Elementor, WooCommerce, тяжёлыми темами, конструкторами и большим количеством плагинов.

Откройте wp-config.php и перед строкой /* That's all, stop editing! */ добавьте:

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

Если сайт тяжёлый, можно попробовать:

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

Но есть нюанс: если на хостинге установлен низкий серверный memory_limit, строка в wp-config.php может не помочь. Тогда нужно менять лимит PHP в панели хостинга или писать в поддержку.

Проверьте mu-plugins

Обычные плагины лежат в папке wp-content/plugins. Но в WordPress есть ещё обязательные плагины — mu-plugins. Они подключаются автоматически и не всегда видны в обычном списке плагинов.

Проверьте папку:

wp-content/mu-plugins

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

Не удаляйте эти файлы наугад. Сначала посмотрите дату изменения и содержимое, либо временно переименуйте подозрительный файл и проверьте сайт.

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

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

Порядок действий:

1. Отключите все плагины.
2. Проверьте сайт.
3. Если не помогло — временно отключите активную тему.
4. Проверьте версию PHP.
5. Включите лог ошибок и посмотрите точный файл.
6. Если обновление прошло криво — переустановите файлы ядра WordPress.

Не обновляйте всё повторно, пока не нашли причину. Иначе можно получить ещё больше ошибок.

Переустановите файлы ядра WordPress

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

Что делать:

1. Скачайте свежий архив WordPress с официального сайта.
2. Распакуйте архив на компьютере.
3. Через FTP загрузите папки wp-admin и wp-includes с заменой.
4. Файл wp-config.php не трогайте.
5. Папку wp-content не трогайте.

В wp-content находятся темы, плагины, изображения и загрузки. Её нельзя заменять без подготовки.

Когда нужно восстанавливать сайт из бэкапа

Бэкап — это последний шаг, а не первый. Используйте его, если плагины, тема, PHP, память и логи не помогли.

Правильный порядок такой:

1. Сначала сделайте текущую копию сайта, даже если он сломан.
2. Попробуйте восстановить только файлы сайта.
3. Проверьте работу сайта.
4. Если не помогло — только тогда рассматривайте восстановление базы данных.

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

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

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

Белый экран WordPress — это тоже может быть критическая ошибка

Иногда вместо сообщения «На сайте возникла критическая ошибка» WordPress показывает просто белую страницу. Это называют белым экраном смерти WordPress.

Причины обычно те же:

• фатальная ошибка PHP;
• конфликт плагина;
• ошибка в теме;
• нехватка памяти;
• несовместимая версия PHP.

Если вы видите белый экран без текста, действуйте по той же схеме: плагины, тема, debug.log, error_log, PHP, память, бэкап.

Чего не нужно делать

• Не удаляйте папку plugins — переименовывайте.
• Не восстанавливайте базу данных первым делом.
• Не включайте все плагины сразу после восстановления.
• Не оставляйте WP_DEBUG включённым навсегда.
• Не меняйте файлы ядра WordPress вручную без копии.
• Не обновляйте всё подряд, пока не нашли причину ошибки.

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

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

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

Как быстро исправить критическую ошибку WordPress?

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

Где найти письмо о критической ошибке WordPress?

Письмо приходит на email администратора сайта. Проверьте входящие и папку «Спам». В письме должна быть ссылка на режим восстановления WordPress.

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

Откройте wp-content/plugins и переименуйте папку этого плагина. Например, plugin-name в plugin-name_old. После этого проверьте сайт.

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

Проверьте активную тему, версию PHP, файл debug.log, логи хостинга, папку mu-plugins и лимит памяти PHP.

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

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

Нужно ли включать WP_DEBUG?

Да, если причина ошибки не ясна. Лучше включать не вывод ошибок на экран, а запись в файл debug.log. После ремонта сайта отладку нужно выключить.

Итог

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

Бэкап используйте в конце, когда безопасные способы не помогли. И не откатывайте базу данных без понимания, какие свежие данные можно потерять.

Если сайт падает не первый раз, начните с общей диагностики: WordPress не работает — что делать и как провести диагностику.