Критическая ошибка WordPress: пошаговое руководство по исправлению

1 минута
6
Wordpress

«На сайте возникла критическая ошибка. Пожалуйста, проверьте почтовый ящик администратора сайта.» — сообщение знакомо каждому, кто хоть раз обновлял плагин или тему на WordPress. Паниковать не нужно: в 90% случаев сайт восстанавливается за 10–15 минут без программиста. В этом руководстве — полный алгоритм диагностики: от включения режима отладки до поиска виновника по логам.

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

С WordPress 5.2 система включает Fatal Error Handler: когда PHP встречает фатальную ошибку (необработанное исключение, вызов несуществующей функции), WordPress перестаёт рендерить страницу и показывает заглушку вместо белого экрана. Раньше такая ситуация называлась WSOD (White Screen of Death) — белый экран смерти.

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

Шаг 1. Быстрая проверка масштаба проблемы

  • Откройте сайт в режиме инкогнито и в другом браузере. Возможно, «умер» только ваш кэш — Ctrl+F5 решает проблему в 5% случаев.
  • Проверьте, работает ли админка (/wp-admin/). Если админка жива, а фронт нет — проблема почти наверняка в теме.
  • Проверьте конкретную страницу. Ошибка на одной странице = проблема в контенте или плагине этой страницы. Ошибка на всём сайте = плагин, тема или PHP.

Шаг 2. Включите режим отладки

Через FTP или файловый менеджер хостинга откройте wp-config.php в корне сайта и добавьте до строки /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );     // ошибки пишутся в wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // не показывать ошибки посетителям
@ini_set( 'display_errors', 0 );

После этого откройте проблемную страницу — реальная ошибка появится в файле wp-content/debug.log либо прямо на экране. Запись вида Uncaught Error: Call to undefined function foo() in /home/site/wp-content/plugins/mypugin/file.php on line 42 сразу указывает на виновника.

После диагностики верните WP_DEBUG в false — включённый отладочный режим замедляет сайт и может раскрыть пути к файлам.

Шаг 3. Отключите все плагины разом

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

cd wp-content/plugins
mv plugins plugins_old
mkdir plugins

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

  1. Переименуйте plugins_old обратно в plugins.
  2. В админке включите один плагин и откройте сайт.
  3. Работает — включаете следующий. Упал — виновник найден.

Тот же приём работает с темой: переименуйте папку активной темы в wp-content/themes/имя_old — WordPress автоматически откатится на тему по умолчанию.

Шаг 4. Проверьте версию PHP

Вторая по частоте причина — несовместимость плагина или темы с версией PHP. Хостинги автоматически поднимают PHP до новых версий, и старый плагин перестаёт работать.

В панели Beget (или любого хостинга) понизьте версию PHP на одну ступень вниз (например, с 8.3 на 8.1) и проверьте сайт. Заработало — обновите плагин/тему, затем поднимите версию обратно.

Шаг 5. Разберитесь с ошибкой 500

Если вместо критической ошибки вы получаете 500 Internal Server Error от Nginx/Apache, сам WordPress даже не запустился. Причины и порядок действий:

  1. .htaccess повреждён — переименуйте файл в .htaccess_old, зайдите в Настройки → Постоянные ссылки и сохраните. WordPress пересоздаст корректный файл.
  2. Лимит памяти PHP — в wp-config.php добавьте define('WP_MEMORY_LIMIT', '256M'); или поднимите лимит в настройках хостинга.
  3. Конфликт плагинов — повторите шаг 3.

Шаг 6. Ошибка соединения с базой данных

Error establishing a database connection — это уже не критическая ошибка WordPress, а отдельный случай, но встречается не реже. Порядок:

  1. Проверьте доступность базы в панели хостинга. База «висит» — дождитесь восстановления или напишите в поддержку.
  2. Откройте wp-config.php и сверьте четыре значения: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST.
  3. Если значения верны — проверьте, не закончилась ли квота на базу данных (в Beget: раздел «MySQL»).

Шаг 7. Очистите кэш и включите сайт обратно

Когда виновник найден и исправлен:

  • Удалите содержимое wp-content/cache/ (папки кэша плагинов).
  • Если использовали WP Super Cache / LiteSpeed Cache — очистите кэш из админки.
  • Верните WP_DEBUG в false.
  • Проверьте сайт на разных страницах и в инкогнито.

Профилактика: как не получить критическую ошибку снова

  • Резервные копии — включите автоматические бэкапы до обновлений. Восстановление из копии быстрее любой диагностики.
  • Обновляйтесь на тестовом сайте — сначала staging, потом прод.
  • Удаляйте неиспользуемые плагины — чем меньше расширений, тем меньше точек отказа.
  • Следите за версией PHP — не оставляйте устаревшую, но и не гонитесь за самой свежей в день релиза.
  • Отключите автоматические обновления для критичных сайтов или включите email-уведомления об обновлениях.

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

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

Читайте также:

Читайте также:

Добавить комментарий

Разработка сайтов на Wordpress