ворд-пресс.рф
Ошибка

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

Пошаговая диагностика критической ошибки WordPress без потери данных и опасных изменений на рабочем сайте.

Опубликовано: 13.10.2026Обновлено: 13.10.2026
Коротко: что делать

Проверьте письмо администратора с Recovery Mode; сохраните резервную копию и журнал PHP. Найдите fatal error и источник сбоя. Не удаляйте плагины и не показывайте ошибки публично.

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

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

  1. Откройте почту администратора WordPress. После фатальной ошибки WordPress может отправить письмо со ссылкой на режим восстановления (Recovery Mode). Проверьте «Спам».
  2. Запишите, что именно не работает: весь сайт, только /wp-admin/, редактор, одна страница или оформление заказа. Отметьте время и последнее изменение.
  3. Через хостинг сохраните полный бэкап базы и файлов, если автоматическая копия ещё не сделана. Для магазина проверьте, как сохранить новые заказы, поступившие после последнего бэкапа.
  4. Посмотрите журнал PHP и ошибок сервера. Не публикуйте в интернете путь к журналу или конфигурацию с паролями.

1. Используйте Recovery Mode

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

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

2. Включите запись ошибок без их показа посетителям

На контролируемой тестовой копии или на короткое время для диагностики, когда это согласовано с администратором сервера, добавьте в wp-config.php перед строкой об окончании редактирования (если эти константы ещё не определены):

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

Не дублируйте определения констант. Посмотрите wp-content/debug.log или системный PHP error log. Важны timestamp, Fatal error, файл и номер строки; не делайте вывод по одному случайному предупреждению. После диагностики отключите запись и удалите/защитите журналы с чувствительной информацией: публичные файлы логов могут раскрывать внутренние пути и данные.

3. Найдите вероятную причину

Ошибка в плагине после обновления

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

Для системной проверки используйте инструкцию по конфликтам плагинов.

Несовместимость PHP или темы

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

Недостаточно памяти

Журнал может содержать Allowed memory size exhausted. Уточните фактический memory_limit PHP и причину расхода: рекурсивный код, запрос, фоновые задачи. Простое повышение лимита может временно скрыть проблему, но не устранить дефект.

4. Проверьте результат и план отката

Откройте главную страницу, проблемный экран, админку и основной пользовательский сценарий. Для WooCommerce проверьте оформление заказа, для формы — отправку и реальное получение письма. Затем сохраните причину, изменённый компонент и дату. При необходимости верните проверенную версию темы/плагина из доверенного источника или восстановите согласованную копию.

Что делать нельзя

  • Удалять базу, папку wp-content или все плагины без резервной копии.
  • Выставлять WP_DEBUG_DISPLAY=true на публичном сайте с посетителями.
  • Заменять текущие файлы произвольным ZIP из интернета.
  • Использовать «универсальный код исправления» без понимания конкретного Fatal error.

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

Источник: https://developer.wordpress.org/advanced-administration/wordpress/common-errors/

Материал был полезен?

Помогите нам сделать материалы точнее и понятнее.