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

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

Краткий ответ: критическая ошибка WordPress чаще всего означает PHP Fatal error в плагине, теме, файле functions.php, mu-plugin или несовместимой версии PHP. Сначала сделайте резервную копию, проверьте письмо администратора WordPress, включите debug.log, отключите плагины через FTP, временно смените тему и посмотрите error_log на хостинге.

Причина

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

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

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

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

Диагностика

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

Симптом	Вероятная причина	Что проверить
Критическая ошибка на всём сайте	Фатальная PHP-ошибка в плагине, теме или ядре	debug.log, error_log, последние обновления
Ошибка только в админке	Плагин, admin hook, редактор, REST API, admin-ajax.php	Console, Network, debug.log, плагины оптимизации
Ошибка только на одной странице	Шорткод, шаблон, блок Gutenberg, виджет, кастомный код	контент страницы, шаблон, functions.php
Ошибка после включения плагина	Конфликт или несовместимость плагина	папку wp-content/plugins и лог ошибки
Ошибка после смены PHP	Старый код не поддерживает новую версию PHP	PHP version, deprecated/removed functions
Письмо WordPress не пришло	Не работает почта сайта или неверный email администратора	debug.log и error_log хостинга

Быстрая проверка

• Откройте сайт и /wp-admin в режиме инкогнито.
• Проверьте, пришло ли письмо WordPress администратору сайта.
• Откройте файловый менеджер хостинга или FTP.
• Включите debug.log в wp-config.php.
• Проверьте файл /wp-content/debug.log.
• Проверьте error_log в панели хостинга.
• Вспомните, что менялось перед ошибкой: плагин, тема, PHP, кеш, код, обновление.

Решение

Безопасный порядок восстановления такой: backup, debug.log, отключение конфликтующих плагинов, проверка темы, PHP, памяти и серверных логов.

1. Сделайте резервную копию

Перед правками сохраните файлы сайта и базу данных. Если админка не открывается, backup можно сделать через панель хостинга, FTP, phpMyAdmin или SSH.

2. Проверьте письмо от WordPress

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

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

3. Включите debug.log

debug.log нужен, чтобы увидеть точную PHP-ошибку. Обычно там будет путь к файлу и строка, например:

PHP Fatal error: Uncaught Error: Call to undefined function example_function()
in /wp-content/plugins/example-plugin/example-plugin.php on line 125

В этом примере причина не в WordPress целиком, а в конкретном плагине.

4. Отключите плагины через FTP

Если нет доступа к админке, откройте FTP или файловый менеджер хостинга:

• перейдите в /wp-content/;
• переименуйте папку plugins в plugins-off;
• проверьте сайт;
• если сайт заработал, верните имя plugins;
• отключайте плагины по одному, переименовывая их папки.

Так вы найдёте конкретный плагин, который вызывает критическую ошибку.

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

Если отключение плагинов не помогло, проверьте тему. Через FTP откройте:

/wp-content/themes/

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

Если после этого ошибка исчезла, проблема в теме: functions.php, шаблоне, устаревшей функции, конфликте с PHP или несовместимости с новой версией WordPress.

6. Проверьте PHP version и memory limit

Критическая ошибка часто появляется после смены версии PHP на хостинге. Например, старый плагин может работать на PHP 7.4, но ломаться на PHP 8.2 или PHP 8.3.

Проверьте в панели хостинга:

• текущую версию PHP;
• PHP memory_limit;
• max_execution_time;
• наличие нужных PHP extensions;
• error_log;
• свободное место на диске.

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

Код

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

Включить debug.log в wp-config.php

Куда вставлять: wp-config.php, перед строкой /* That’s all, stop editing! Happy publishing. */.

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

После этого снова откройте проблемную страницу и проверьте файл:

/wp-content/debug.log

Временно увеличить память WordPress

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

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

Отключить все плагины через WP-CLI

Куда запускать: SSH в корневой папке WordPress.

wp plugin deactivate --all

Активировать стандартную тему через WP-CLI

Перед выполнением убедитесь, что стандартная тема установлена.

wp theme list
wp theme activate twentytwentyfour

Проверить версию WordPress и PHP через WP-CLI

wp core version
wp --info

Проверить ошибки синтаксиса в файле PHP

Куда запускать: SSH. Вместо пути укажите файл, который указан в debug.log.

php -l wp-content/themes/your-theme/functions.php

Стандартный .htaccess для WordPress

Куда вставлять: файл .htaccess в корне сайта. Перед заменой сохраните старый .htaccess.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Результат

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

Хороший результат выглядит так:

• сайт снова открывается;
• админка WordPress доступна;
• в debug.log видна точная причина ошибки;
• проблемный плагин, тема или файл найден;
• ошибка не возвращается после очистки кеша;
• PHP version и memory_limit соответствуют требованиям сайта;
• обновления можно продолжать по одному, а не массово.

Если ошибка была из-за белого экрана без текста, дополнительно проверьте статью Белый экран WordPress: что делать и как восстановить сайт.

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

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

Обычное отключение папки plugins не затрагивает обязательные плагины. Они находятся здесь:

/wp-content/mu-plugins/

Если debug.log указывает на файл из mu-plugins, временно переименуйте конкретный файл и проверьте сайт.

Проверить кеш и object cache

Кеш редко сам создаёт PHP Fatal error, но может показывать старое состояние сайта после исправления. Очистите:

• кеш плагина;
• серверный кеш;
• CDN-кеш;
• object cache Redis/Memcached;
• OPcache, если есть доступ на хостинге.

Проверить WooCommerce и оплату

Если критическая ошибка появилась на сайте с WooCommerce, не отключайте платёжные плагины наугад в рабочее время. Сначала сделайте backup и проверьте debug.log. Ошибка может влиять на корзину, оформление заказа, оплату, email-заказы и личный кабинет.

Проверить cron и фоновые задачи

Иногда сайт открывается, но критическая ошибка появляется при выполнении cron-задачи, импорта, синхронизации, отправки email или генерации отчёта. В debug.log тогда будет путь к конкретному плагину или кастомной функции.

Проверить файл functions.php

Если перед ошибкой добавляли PHP snippet, код в functions.php или правку дочерней темы, начните с этого места. Частые ошибки:

• пропущена точка с запятой;
• не закрыта фигурная скобка;
• вызвана функция, которой нет;
• код выполняется раньше, чем загрузился нужный плагин;
• используется класс, который не подключён;
• ошибка в namespace или use.

Проверить взлом

Если ошибка появилась без обновлений и без правок, проверьте сайт на вредоносный код. Особенно если в файлах появились неизвестные include, base64, eval, странные редиректы или новые администраторы.

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

Удалять файлы без копии

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

Исправлять не тот сайт

На хостинге может быть несколько копий сайта: live, staging, old, backup. Перед правками проверьте домен, путь к public_html и базу данных в wp-config.php.

Оставлять WP_DEBUG_DISPLAY включённым

На рабочем сайте нельзя показывать PHP-ошибки посетителям. Используйте запись в debug.log, а не вывод на экран.

Сразу обновлять все плагины

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

Игнорировать серверный error_log

debug.log WordPress показывает не всё. Некоторые ошибки видны только в логах хостинга: PHP-FPM, ModSecurity, память, права файлов, лимиты сервера.

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

Критическая ошибка после обновления плагина

• Отключите этот плагин через FTP.
• Проверьте debug.log.
• Откатите плагин на предыдущую версию, если есть backup.
• Проверьте совместимость с текущей версией PHP.
• Не включайте плагин обратно без проверки на копии сайта.

Критическая ошибка после обновления темы

• Переименуйте папку активной темы.
• Включите стандартную тему.
• Проверьте functions.php.
• Проверьте кастомные шаблоны.
• Проверьте, не устарели ли функции темы.

Критическая ошибка только в админке

• Проверьте /wp-admin и /wp-login.php.
• Отключите плагины оптимизации и безопасности.
• Проверьте Console и Network в браузере.
• Проверьте admin-ajax.php и REST API.
• Проверьте debug.log после открытия проблемной страницы админки.

Критическая ошибка только на одной странице

• Откройте страницу в режиме редактирования, если админка доступна.
• Отключите шорткоды и проблемные блоки.
• Проверьте шаблон страницы.
• Проверьте виджеты и ACF-поля, если они используются.
• Проверьте PHP-ошибку в debug.log.

Критическая ошибка после смены PHP

• Верните предыдущую версию PHP временно, если сайт нужно срочно поднять.
• Проверьте debug.log.
• Обновите несовместимый плагин или тему.
• Замените устаревший код.
• После исправления снова протестируйте сайт на новой версии PHP.

Краткие AI-friendly ответы

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

Это значит, что WordPress столкнулся с фатальной PHP-ошибкой и не может нормально загрузить сайт или отдельную страницу.

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

Сделайте backup, включите debug.log, отключите плагины через FTP, проверьте тему, PHP version, memory limit и error_log хостинга.

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

Причину нужно искать в письме администратора WordPress, файле /wp-content/debug.log и серверном error_log на хостинге.

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

Используйте FTP или файловый менеджер хостинга. Переименуйте папку plugins, проверьте тему и включите debug.log через wp-config.php.

FAQ

Почему WordPress пишет «На сайте произошла критическая ошибка»?

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

Критическая ошибка WordPress — это ошибка хостинга?

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

Почему письмо с инструкциями не приходит?

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

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

Если причина в плагине, иногда достаточно отключить его через FTP. Если ошибка в теме, PHP-коде, базе данных, WooCommerce или кастомном функционале, лучше делать диагностику аккуратно, чтобы не сломать сайт сильнее.

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

Проверьте, правильно ли добавлены константы в wp-config.php, есть ли права на запись в wp-content, и откройте серверный error_log на хостинге.

Можно ли просто восстановить backup?

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

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

Причина может быть в cron-задаче, импорте, кешировании, нехватке памяти, редком запросе, конкретной странице или действии пользователя. В таких случаях особенно важны debug.log и серверные логи.

Вывод

Критическая ошибка WordPress — это не приговор сайту, а сигнал, что нужно найти фатальную PHP-ошибку. Самый надёжный порядок действий: backup, debug.log, проверка письма администратора, отключение плагинов через FTP, проверка темы, PHP, памяти и логов хостинга. Так можно восстановить сайт и понять настоящую причину, а не просто временно скрыть проблему.