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

Сообщение «На сайте возникла критическая ошибка» значит, что PHP остановился на фатальной ошибке: чаще всего в плагине, теме или вашем коде. Записи и страницы при этом обычно на месте. Что делать: найдите письмо на почте администратора и войдите по ссылке в режим восстановления. Если письма нет, отключите плагин через FTP и включите журнал ошибок. Ниже весь порядок, что написать хостингу и что передать разработчику.

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

С версии 5.2 WordPress показывает это сообщение там, где раньше был пустой белый экран. Текст зависит от версии и языка. Встречаются варианты «На этом сайте произошла критическая ошибка», «На сайте возникли технические проблемы», There has been a critical error on this website.

Смысл один: код не смог выполниться до конца. Документация WordPress называет обычные причины:

• конфликт плагинов;
• несовместимая тема;
• неподходящая версия PHP;
• нехватка памяти;
• повреждённые файлы WordPress.

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

Сначала сделайте копию

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

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

Письмо режима восстановления: что с ним делать

При фатальной ошибке WordPress отправляет письмо на адрес администратора из раздела «Настройки → Общие». В теме будет примерно «На вашем сайте возникла техническая проблема», на английском Your Site Is Experiencing a Technical Issue. В письме указан плагин или тема и секретная ссылка.

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

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

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

Письмо не пришло: почему и что дальше

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

• в настройках указан старый адрес, к которому никто не имеет доступа;
• письмо лежит в спаме;
• письмо уже отправлялось в последние сутки;
• сайт вообще не умеет отправлять почту. Это отдельная поломка, разбор в статье о письмах с сайта.

Ждать не надо, переходите к FTP. На будущее в wp-config.php можно указать отдельный адрес для таких писем константой RECOVERY_MODE_EMAIL.

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

Подойдёт FTP, SFTP или файловый менеджер в панели хостинга.

1. Откройте папку wp-content/plugins.
2. Если знаете виновника, переименуйте только его папку, например plugin-name в plugin-name_off. Подсказка: путь в тексте ошибки или плагин, который обновляли последним.
3. Если виновник неизвестен, переименуйте всю папку plugins в plugins_old. Так советует документация WordPress.
4. Откройте сайт. Если он заработал, причина в плагине.
5. Пока папка переименована, откройте в админке раздел «Плагины»: WordPress отключит всё, чего не нашёл. Затем верните папке имя plugins и включайте плагины по одному.

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

Если ошибка осталась, загляните в wp-content/mu-plugins. Эти плагины работают всегда, и переименование основной папки на них не влияет.

Как отключить тему WordPress

Если плагины ни при чём, проверьте тему. Откройте wp-content/themes и переименуйте папку активной темы. WordPress переключится на стандартную тему, если она установлена. Если стандартной темы нет, скачайте её с wordpress.org и загрузите в эту папку.

Сайт откроется в другом оформлении. Это нормально для проверки: настройки темы не удаляются при переименовании. Причину ищите в коде темы, чаще всего в functions.php.

Как включить WP_DEBUG и найти причину

Журнал отвечает на главный вопрос: какой файл и какая строка. Откройте wp-config.php. Если там уже есть строка define( 'WP_DEBUG', false );, удалите её: вторая такая строка не сработает. Затем выше строки с надписью о том, что дальше редактировать не нужно (That's all, stop editing!), добавьте:

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

Откройте сломанную страницу и посмотрите файл wp-content/debug.log. Последняя строка с PHP Fatal error и есть причина.

Эти настройки взяты из руководства по отладке. Там же сказано, что на рабочем сайте держать их не рекомендуется. Поэтому после разбора удалите строки и файл debug.log: он лежит в папке, доступной из браузера, если сервер не закрывает её отдельно.

Значение пишите без кавычек. 'false' в кавычках WordPress поймёт как включённую настройку.

Как прочитать текст ошибки

Текст в журнале	Что значит	Что делать
Allowed memory size ... exhausted	PHP упёрся в лимит памяти	Поднять лимит, найти прожорливый плагин
Call to undefined function	Вызвана функция, которой нет	Проверить зависимый плагин и версию PHP
Class "..." not found	Не загрузился класс	Обновление не завершилось или отключён нужный плагин
Cannot redeclare	Одна функция объявлена дважды	Дубль кода или два похожих плагина
syntax error	Опечатка в коде	Откатить последнюю правку файла
Maximum execution time	Скрипт шёл слишком долго	Смотреть лимит времени и тяжёлую операцию
No space left on device	Закончился диск	Освободить место, почистить журналы и копии

Путь в конце строки подсказывает виновника, но не всегда. Если там /wp-content/plugins/имя/, виноват этот плагин почти наверняка. Если там файл WordPress, смотрите выше по стеку.

Вот пример. На сайте клиента с тяжёлым плагином журнал показал Allowed memory size of 268435456 bytes exhausted в файле wp-includes/functions.php. Ядро было ни при чём, этот файл просто попросил память последним. 268 435 456 байт это 256 МБ. На сервере при этом было 6 ГБ, и владелец резонно удивился. Память сервера и лимит PHP живут отдельно: один процесс получает только разрешённое ему. Лимит подняли.

Лимит меняют в настройках PHP на хостинге или строкой в wp-config.php:

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

Часть хостингов не даёт поднять лимит так, тогда попросите поддержку. Если после этого плагин всё равно съедает всё, дело в его работе, и лимит только отодвигает ошибку.

Версия PHP: когда виновата она

Подозревайте PHP, если ошибка появилась сразу после смены версии в панели или хостинг сам обновил её. Типичный след: Call to undefined function или TypeError в старом плагине.

Быстрая проверка простая: верните прошлую версию PHP в панели. Сайт ожил, значит причина найдена. Оставаться на старой версии нельзя, и вот почему.

• WordPress рекомендует PHP 8.3 и выше.
• Версии 8.1 и старее обновлений от проекта PHP больше не получают.
• 21 октября 2026 PHP закрыл две критические уязвимости в версиях 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Полного обхода без обновления разработчики не дали.

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

Порядок безопасного обновления такой:

1. Копия сайта.
2. Новая версия PHP на копии.
3. Журнал ошибок и проверка форм, оплаты, обмена.
4. Правки несовместимого кода.
5. Перенос на рабочий сайт и снова проверка.

Белый экран WordPress: что делать

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

Добавьте к нему три проверки:

• Файл .htaccess. Переименуйте его в .htaccess_old. Если сайт открылся, сохраните настройки постоянных ссылок, и WordPress создаст новый файл.
• Память и диск. Посмотрите в панели хостинга.
• Кеш. Очистите кеш плагина и CDN, потому что вы можете смотреть старую сломанную версию.

Бывает и совсем странный случай. В сентябре 2025 на сайте бронирования я ловил белые экраны в админке, а правки файлов не применялись. Диск и нагрузка были в норме, у владельца всё открывалось. Я подозревал кеш PHP на сервере. Помогло другое: жёсткие пути подключения файлов. Скорее всего, сайт брал старую копию файла из другой папки. До конца я этого не доказал, поэтому и пишу «скорее всего».

Что написать хостингу

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

Здравствуйте. Сайт ваш-сайт.ru с 11:40 по Москве показывает критическую ошибку WordPress. Перед этим мы обновили [что именно] / ничего не меняли.

Посмотрите, пожалуйста:

1. Журнал ошибок PHP за это время. Пришлите строки с Fatal error.
2. Менялась ли версия PHP и настройки на вашей стороне.
3. Хватает ли места на диске и лимита памяти.
4. Есть ли резервная копия за вчера и как её восстановить.

Что передать разработчику

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

Как не попасть в это снова

В январе 2025 владелица спортивного сайта увидела в админке подсказку «надо обновить» и обновила. Весь написанный для сайта код исчез, форма регистрации перестала работать, а регистрацию на соревнования надо было открывать немедленно. Я поднял резервную копию хостинга в тот же вечер, вернул всё вплоть до файлов Excel и проверил создание платежа.

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

Правила на будущее короткие:

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

Когда звать специалиста

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

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

Пришлите текст ошибки через бесплатный разбор. Если нужно смотреть на сервере, разбор стоит 3 000 ₽ и идёт в зачёт работы. Восстановление из копии или обновление PHP на обычном сайте стоит от 3 000 ₽. Если нужно, чтобы этим занимался кто-то постоянно, в поддержке от 10 000 ₽ в месяц есть обновления и резервные копии.