Критическая ошибка WordPress: что делать

Критическая ошибка WordPress: что делать

Краткий ответ: если появилась критическая ошибка WordPress, не переустанавливайте сайт и не удаляйте файлы наугад. Сначала сделайте копию файлов и базы, проверьте письмо режима восстановления, включите debug.log, найдите fatal error, временно отключите проблемный плагин или тему через FTP/SFTP, проверьте версию PHP, память, кеш и серверные логи.

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

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

Причина

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

Типовые причины:

• плагин обновился и стал несовместим с текущей версией WordPress или PHP;
• тема содержит ошибку в functions.php или шаблонах;
• вставлен неправильный PHP-код в тему, сниппет или кастомный плагин;
• на сайте закончился PHP memory limit;
• сервер переключили на другую версию PHP;
• обновление WordPress, темы или плагина прошло не полностью;
• плагин конфликтует с другим плагином;
• повреждены файлы ядра WordPress;
• в базе данных есть некорректные настройки активной темы или плагина;
• security-плагин, кеш или WAF блокирует часть запросов.

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

Что сделать сразу

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

• сохраните текст ошибки и URL страницы, где она появляется;
• проверьте, открывается ли wp-admin;
• проверьте почту администратора сайта — WordPress может отправить письмо с режимом восстановления;
• сделайте копию файлов и базы данных через хостинг или FTP/SFTP;
• включите логирование ошибок в debug.log;
• проверьте error_log на хостинге;
• вспомните последнее действие: обновление, установка плагина, смена PHP, правка кода;
• не запускайте массовые обновления, пока причина не найдена.

Диагностика

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

Симптом	Вероятная причина	Что проверить
Ошибка появилась после обновления плагина	конфликт или несовместимость плагина	debug.log, папку плагина, changelog, версию PHP
Ошибка появилась после обновления темы	ошибка в шаблоне, functions.php, дочерней теме	активную тему, дочернюю тему, кастомные правки
Ошибка после смены PHP	старый код несовместим с новой версией PHP	версию PHP, устаревшие функции, debug.log
Не открывается wp-admin	fatal error в плагине, теме или security-настройках	FTP/SFTP, папку plugins, активную тему, error_log
Ошибка только на одной странице	шорткод, шаблон, виджет, блок, кастомное поле	конкретный шаблон, shortcode, page builder, ACF, PHP-сниппеты
Ошибка в WooCommerce	checkout, оплата, доставка, webhooks, сессии	WooCommerce logs, консоль браузера, wc-ajax, payment gateway
Ошибка появляется периодически	cron, кеш, лимит памяти, внешний API, нагрузка	server logs, cron events, PHP memory, slow queries

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

Решение

Безопасное восстановление зависит от того, есть ли доступ к админке. Если wp-admin открывается, можно работать через режим восстановления или админку. Если админка недоступна, нужен FTP/SFTP, файловый менеджер хостинга или WP-CLI.

1. Сделайте backup. Сохраните файлы сайта и базу данных до любых действий.
2. Включите debug.log. Так вы увидите реальную PHP-ошибку, а не только общее сообщение.
3. Найдите файл-источник ошибки. В логе обычно указан путь: plugin, theme, mu-plugin, wp-includes или wp-content.
4. Отключите проблемный плагин. Если админка не работает, переименуйте папку конкретного плагина через FTP/SFTP.
5. Проверьте тему. Если ошибка в теме, временно переключитесь на стандартную тему или переименуйте папку активной темы.
6. Проверьте PHP-версию. Если ошибка началась после смены PHP, временно верните предыдущую версию и обновите несовместимый код.
7. Проверьте memory limit. Если лог показывает exhausted memory, можно временно увеличить лимит, но нужно найти причину нагрузки.
8. Очистите кеш. После исправлений очистите кеш сайта, CDN и браузера, но не меняйте настройки кеша вслепую.
9. Проверьте сайт полностью. Главная, страницы, формы, wp-admin, мобильная версия, WooCommerce, письма, логи.

Код

Важно: код ниже влияет на диагностику сайта. Перед изменением wp-config.php сделайте копию файла через FTP/SFTP или хостинг-панель. Не включайте вывод ошибок посетителям на рабочем сайте.

Куда вставлять: в файл wp-config.php, выше строки /* That’s all, stop editing! */. Этот код включает запись ошибок в debug.log, но не показывает их пользователям.

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

После этого проверьте файл:

/wp-content/debug.log

Если ошибка связана с нехваткой памяти, можно временно увеличить лимит. Это не лечит причину, но может помочь восстановить доступ для диагностики. Куда вставлять: в wp-config.php, выше строки /* That’s all, stop editing! */.

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

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

Если есть доступ к WP-CLI, можно проверить активные плагины и отключить конкретный проблемный плагин. Команды выполняются в терминале на сервере:

wp plugin list
wp plugin deactivate plugin-slug
wp theme list
wp theme activate twentytwentyfour

Важно: не отключайте все плагины на рабочем сайте без понимания последствий. Для WooCommerce это может повлиять на оплату, доставку, письма, корзину, checkout, CRM и статусы заказов.

После завершения диагностики отключите debug-режим:

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

Как отключить проблемный плагин через FTP

Если админка не открывается, плагин можно отключить через FTP/SFTP или файловый менеджер хостинга.

1. Откройте папку сайта.
2. Перейдите в /wp-content/plugins/.
3. Найдите папку плагина, который указан в debug.log.
4. Переименуйте её, например: plugin-name-disabled.
5. Обновите страницу сайта.
6. Если сайт открылся, причина почти точно в этом плагине или его конфликте.

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

Как проверить тему

Если debug.log показывает ошибку в папке активной темы, проблема может быть в functions.php, шаблоне страницы, дочерней теме или кастомном коде.

• проверьте, менялся ли файл functions.php перед ошибкой;
• проверьте дочернюю тему;
• посмотрите путь к файлу в debug.log;
• временно переключитесь на стандартную тему, если есть доступ к wp-admin;
• если доступа нет, переименуйте папку активной темы через FTP/SFTP;
• после восстановления перенесите правки в дочернюю тему или отдельный плагин.

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

Как отличить критическую ошибку от ошибки базы данных

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

Ошибка	Что обычно означает	Где искать причину
На сайте произошла критическая ошибка	fatal PHP error в плагине, теме, ядре или кастомном коде	debug.log, error_log, FTP/SFTP, плагины, тема, PHP
Ошибка подключения к базе данных	WordPress не может подключиться к MySQL/MariaDB	wp-config.php, DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, сервер MySQL
Белый экран	fatal error без вывода сообщения или проблема PHP	debug.log, error_log, memory limit, плагины, тема
Ошибка 500	серверная ошибка, PHP, .htaccess, память, конфликт	логи хостинга, .htaccess, PHP, плагины, тема

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

Результат

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

• сайт снова открывается;
• wp-admin доступен;
• найден файл, плагин, тема или настройка, вызвавшая ошибку;
• проблемный компонент отключён, обновлён, исправлен или заменён;
• debug.log проверен после восстановления;
• формы заявок протестированы;
• если есть WooCommerce — проверены корзина, checkout, оплата, доставка и письма;
• кеш очищен;
• есть свежая резервная копия после восстановления;
• понятно, что сделать, чтобы ошибка не повторилась.

Дополнительные способы

Режим восстановления WordPress

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

Проверка server error_log

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

Откат из backup

Если сайт сломался после обновления и быстро найти причину не получается, безопаснее восстановить файлы и базу из резервной копии, а затем повторить обновление на staging-копии.

Проверка версии PHP

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

Проверка кастомного кода

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

Частые ошибки

• Переустанавливать WordPress сразу. Часто причина в одном плагине, теме или строке кода, а не во всём сайте.
• Удалять плагины вместо отключения. Можно потерять настройки или усложнить восстановление.
• Отключать все плагины без backup. Это может сломать WooCommerce, формы, SEO, мультиязычность и интеграции.
• Не читать debug.log. Без лога приходится угадывать причину.
• Оставлять WP_DEBUG_DISPLAY включённым. Это может показать технические ошибки посетителям.
• Чистить базу данных наугад. Можно удалить важные настройки сайта, темы, WooCommerce или плагинов.
• Игнорировать версию PHP. После смены PHP старый код может перестать работать.
• Не проверять сайт после восстановления. Главная может открыться, но формы, письма или checkout могут остаться сломанными.
• Не делать backup после исправления. После восстановления лучше сохранить рабочую копию сайта.

Диагностика проблем

Если критическая ошибка повторяется, нужно искать не только последний плагин, а всю цепочку: код, сервер, память, cron, кеш, WooCommerce и внешние интеграции.

Что видно в логе	Что это может значить	Что делать
Allowed memory size exhausted	не хватает PHP-памяти или есть тяжёлый процесс	временно увеличить memory limit, найти тяжёлый плагин или запрос
Call to undefined function	код вызывает функцию, которая не подключена или удалена	проверить плагин, тему, порядок загрузки, версию зависимости
Class not found	не найден класс плагина, темы или библиотеки	проверить обновление, автозагрузку, удалённые файлы
Parse error	синтаксическая ошибка PHP	проверить последний изменённый файл, скобки, кавычки, точку с запятой
Cannot redeclare function	функция объявлена дважды	найти дубли в теме, дочерней теме, сниппетах или плагинах
Maximum execution time exceeded	скрипт выполняется слишком долго	проверить импорт, cron, API, тяжёлые циклы, базу данных
Fatal error в папке plugins	проблема в конкретном плагине	отключить плагин, обновить, заменить или исправить конфликт
Fatal error в папке themes	проблема в теме или дочерней теме	переключить тему, проверить functions.php и шаблоны

Что проверить после восстановления

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

• главная страница открывается;
• внутренние страницы открываются;
• wp-admin работает;
• постоянные ссылки не сломаны;
• формы отправляют заявки;
• письма доходят;
• мобильная версия отображается правильно;
• меню, попапы, фильтры и поиск работают;
• нет новых ошибок в debug.log;
• нет ошибок JavaScript в консоли;
• если есть WooCommerce — работает корзина, checkout, оплата, доставка, статусы и письма;
• sitemap.xml и robots.txt открываются;
• нет массовых 404 после восстановления;
• backup обновлён после исправления.

FAQ

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

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

Что делать в первую очередь?

Сделайте копию файлов и базы, проверьте почту администратора, включите debug.log, посмотрите error_log на хостинге и найдите файл, который вызывает fatal error.

Можно ли исправить критическую ошибку без доступа к админке?

Да. Можно использовать FTP/SFTP, файловый менеджер хостинга, phpMyAdmin, server logs или WP-CLI. Чаще всего через FTP временно отключают проблемный плагин или тему.

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

Плагин мог стать несовместимым с текущей версией WordPress, PHP, темой или другим плагином. Также обновление могло пройти не полностью или изменить важную функцию.

Почему WordPress пишет “Проверьте почту администратора”?

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

Что делать, если debug.log пустой?

Проверьте, правильно ли включён WP_DEBUG_LOG, есть ли права на запись в wp-content, не блокирует ли хостинг создание файла, а также посмотрите server error_log в панели хостинга.

Можно ли просто увеличить memory limit?

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

Нужно ли отключать все плагины?

Только если нет другого способа найти причину. Лучше сначала смотреть debug.log и отключать конкретный плагин. Массовое отключение может повлиять на формы, WooCommerce, SEO, мультиязычность и интеграции.

Как понять, что проблема в теме?

В debug.log путь к ошибке будет вести в папку активной темы или дочерней темы. Также ошибка может появиться после изменения functions.php, шаблона страницы или обновления темы.

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

Не включайте его повторно на рабочем сайте. Проверьте версию плагина, совместимость с PHP, конфликт с другими плагинами и логи. Иногда лучше заменить плагин или исправить конфликт на тестовой копии.

Вывод

Критическая ошибка WordPress — это не повод сразу переустанавливать сайт. В большинстве случаев нужно найти fatal error через debug.log или server logs, определить проблемный плагин, тему, PHP-версию, память или кастомный код и восстановить сайт аккуратно.

Безопасный порядок такой: backup, диагностика, лог ошибки, отключение конкретного проблемного компонента, проверка сайта, исправление причины и повторная проверка форм, админки, WooCommerce, SEO-файлов и логов.