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

Вместо сайта белая страница с одной строкой: «На сайте возникла критическая ошибка» (в английской версии — «There has been a critical error on this website») или «Error establishing a database connection», по-русски «Ошибка установки соединения с базой данных». Сайт недоступен целиком, заявки и заказы не приходят, в админку не зайти. Это две разные аварии с разными причинами, и лечатся они по-разному. Ниже разобрано, как за 15–30 минут понять, что сломалось, что можно сделать самостоятельно и в какой момент лучше отдать задачу разработчику. Версии и сроки поддержки указаны на сентябрь 2026 года: актуальный WordPress — 7.1.2.

Две разные ошибки WordPress: что именно написано на экране

«Критическую ошибку» показывает обработчик фатальных ошибок PHP, появившийся в WordPress 5.2: код плагина, темы или ядра упал, и вместо пустого белого экрана выводится заглушка, а «ошибка соединения» значит, что PHP работает, но не достучался до базы.

Отсюда и две формулировки в поиске: «возникла» и «произошла» — это разные строки перевода одной ошибки. В обоих случаях сервер отдаёт HTTP-код 500, поэтому поисковые роботы видят сайт как неработающий.

Первые 15 минут: что сделать до любых правок

1. Зафиксируйте, что изменилось. Обновление плагина или ядра, новая тема, правка в functions.php, смена версии PHP в панели хостинга, перенос сайта, смена пароля к базе — в большинстве случаев причина в последнем изменении.
2. Сделайте копию текущего состояния файлов и базы через панель хостинга, даже сломанного. Если ремонт пойдёт не так, будет куда вернуться, а специалисту будет что анализировать.
3. Проверьте почту администратора (адрес из «Настройки → Общие»): при критической ошибке там может лежать письмо со ссылкой в режим восстановления.
4. Откройте журнал ошибок PHP в панели хостинга (раздел «Логи», «Журналы», error_log) и найдите последние строки с PHP Fatal error или Parse error. В строке будет путь к файлу, например wp-content/plugins/имя-плагина/…, — это почти готовый ответ.
5. Проверьте сайт без кеша: в режиме инкогнито и с параметром в адресе (?nocache=1). Страничный кеш плагина, nginx или CDN иногда продолжает отдавать старые страницы, пока база уже лежит.

«There has been a critical error on this website»: основные причины

Плагин или тема после обновления

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

Версия PHP на хостинге

Хостинг переводит аккаунты на новые версии PHP, когда у старых заканчивается поддержка. На сентябрь 2026 года WordPress рекомендует PHP 8.3 и выше (и MySQL 8.0+ или MariaDB 10.11+). Формально ядро 7.1 ещё запускается на PHP 7.4, но это устаревшая ветка без исправлений безопасности. Старый код с удалёнными функциями на PHP 8.x падает с ошибками вида Call to undefined function или Uncaught TypeError. Обратная ситуация тоже бывает: свежий плагин требует PHP 8.1+, а сайт работает на 7.4.

Нехватка памяти и ошибки в коде

Сообщение Allowed memory size of … bytes exhausted в логе означает, что скрипту не хватило памяти. Если лимит PHP на хостинге ниже, WordPress поднимает его до 40 МБ (64 МБ на мультисайте), в админке — до 256 МБ; выше жёсткого лимита хостинга константа не поднимет. Поднять лимит можно константой define( 'WP_MEMORY_LIMIT', '256M' ); в wp-config.php, но если память съедает один плагин, это лишь отсрочка. Ещё одна частая причина — ручная правка functions.php через редактор в админке: одна пропущенная скобка даёт Parse error и роняет весь сайт.

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

При фатальной ошибке в плагине или теме WordPress отправляет на почту администратора письмо с темой «[Название сайта] На сайте возникли технические проблемы» (в английской версии — «Your Site is Experiencing a Technical Issue»). В письме указано, какой плагин или тема упали, строка с ошибкой и специальная ссылка входа в режим восстановления (recovery mode).

По ссылке, после входа под администратором, вы попадаете в админку, где проблемный плагин или тема приостановлены. Сайт для посетителей остаётся сломанным, пока вы не деактивируете или не замените виновника. После этого нажмите «Выйти из режима восстановления» и проверьте сайт в обычном режиме.

Почему письмо может не прийти:

• Письмо отправляется не чаще раза в сутки, ссылка действует тоже сутки. Если письмо уже уходило в последние 24 часа, следующее придёт только по их истечении.
• На хостинге отключена функция mail() или письма от сайта попадают в спам — частая ситуация без настроенного SMTP.
• Адрес администратора в настройках давно не используется: его указывал разработчик или бывший сотрудник.
• Ошибка не в плагине и не в теме, а в ядре, wp-config.php или mu-plugins — такие компоненты режим восстановления приостановить не может.

Как включить WP_DEBUG и найти виновника

Если доступа к журналу PHP на хостинге нет, включите журнал WordPress. В wp-config.php, выше строки /* That's all, stop editing! */ (в старых русских сборках — «Это всё, дальше не редактируем»), замените define( 'WP_DEBUG', false ); на:

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

Ошибки начнут записываться в файл wp-content/debug.log, а посетители их не увидят. Откройте страницу с ошибкой ещё раз и посмотрите последние строки файла: Fatal error с путём к файлу укажет на плагин, тему или конкретную строку кода.

Как отключить плагины и тему без доступа в админку

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

1. Переименуйте папку wp-content/plugins, например в plugins_off. WordPress перестанет видеть плагины и отключит их. Если сайт открылся — виновник среди плагинов.
2. Верните папке имя и переименовывайте папки плагинов по одной, начиная с недавно обновлённых, каждый раз проверяя сайт. Если после возврата имени плагины оказались деактивированы, включайте их в админке по одному.
3. Если отключение плагинов не помогло, переименуйте папку активной темы в wp-content/themes. WordPress переключится на стандартную тему из линейки Twenty (например, Twenty Twenty-Five), если она установлена.
4. Найдя виновника, не удаляйте его вслепую: сначала уточните, где хранятся его настройки и данные. Лучше откатить плагин на предыдущую версию, чем потерять, например, заказы или формы.

С SSH-доступом то же самое быстрее делается через WP-CLI: wp plugin deactivate --all отключает все плагины, wp plugin install имя --version=x.y --force ставит предыдущую версию, а флаги --skip-plugins --skip-themes позволяют выполнять команды на сломанном сайте. Если ошибка появилась после планового обновления, полезно заранее знать, когда обновлять WordPress и чем это рискует, чтобы в следующий раз не чинить сайт на ходу.

Error establishing a database connection: пошаговая диагностика

Ошибка установки соединения с базой данных означает, что WordPress не смог подключиться к MySQL/MariaDB. В админке (или с включённым WP_DEBUG_DISPLAY) WordPress подсказывает три варианта, посетители видят только заголовок: неверные логин или пароль, неверное имя хоста, не запущен сервер базы данных. На практике причины такие.

Доступы к базе в wp-config.php

Откройте wp-config.php в корне сайта и сверьте четыре константы с данными в панели хостинга: DB_NAME (имя базы), DB_USER (пользователь), DB_PASSWORD (пароль) и DB_HOST (сервер). Самый надёжный тест — войти в phpMyAdmin именно с этими логином и паролем. Если вход не проходит, задайте пользователю базы новый пароль в панели и пропишите его в wp-config.php. Типичные ситуации: после переноса на другой хостинг остался старый DB_HOST; пароль к базе сменили в панели, а в конфиге — нет; у хостинга сервер базы не localhost, а отдельный адрес или порт.

Сервер базы недоступен или упёрся в лимиты

Если доступы верны, а phpMyAdmin тоже не открывается или отвечает Too many connections, проблема на стороне сервера базы. На виртуальном хостинге это бывает при превышении квоты диска, лимита соединений или нагрузки: всплеск трафика, наплыв ботов, тяжёлые запросы плагинов. На VPS — MySQL остановился из-за нехватки памяти или места на диске. Здесь нужна техподдержка хостинга или администратор сервера; правки в WordPress не помогут.

Повреждённые таблицы

Если подключение есть, но WordPress сообщает, что таблицы недоступны, добавьте в wp-config.php строку define( 'WP_ALLOW_REPAIR', true ); и откройте адрес вашдомен.ru/wp-admin/maint/repair.php. Кнопка «Починить базу данных» проверит и восстановит таблицы. Альтернатива — «Восстановить таблицу» в phpMyAdmin или wp db repair в WP-CLI.

Отдельный случай: после переноса сайта вместо ошибки открывается мастер установки WordPress. Значит, подключение к базе есть, но $table_prefix в wp-config.php не совпадает с префиксом таблиц в базе или база пустая.

Если причина во взломе или неудачном переносе

Если ничего не меняли, а в wp-config.php, index.php или папке uploads появились незнакомые фрагменты кода или PHP-файлы, критическая ошибка может быть следствием взлома: вредоносный код конфликтует с сайтом или подменён файл конфигурации. В этом случае восстановление из бэкапа убирает симптом, но не дыру — через тот же уязвимый плагин сайт взломают снова. Нужно найти точку входа, обновить или убрать уязвимые компоненты и сменить все пароли, включая пароль к базе и ключи в wp-config.php.

Если авария случилась после переноса, сравните версии PHP и MySQL на старом и новом сервере, права на файлы и константы в wp-config.php.

Как не попасть в эту ситуацию снова

Критическая ошибка почти всегда следует за изменением, которое проверили прямо на рабочем сайте. Что снижает риск:

• обновлять плагины, тему и ядро сначала на тестовой копии и выкатывать на рабочий сайт с точкой отката;
• держать ежедневные бэкапы файлов и базы вне основного хостинга и хотя бы раз в квартал проверять восстановление;
• следить за сроками поддержки PHP и переходить на новую версию по плану, а не когда хостинг переключит принудительно;
• настроить мониторинг доступности с уведомлением в Telegram, чтобы узнавать об аварии раньше клиентов;
• подготовить свою страницу для сбоя базы — файл wp-content/db-error.php с контактами и кодом ответа 503 вместо голой системной ошибки.

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

Чек-лист: что делать при критической ошибке WordPress

• Определите, какая ошибка на экране: критическая ошибка PHP или ошибка соединения с базой.
• Вспомните последнее изменение: обновление, новый плагин, смену PHP, перенос, смену пароля.
• Сделайте копию файлов и базы в текущем состоянии.
• Проверьте почту администратора и спам: письмо о технических проблемах со ссылкой в режим восстановления.
• Найдите Fatal error в журнале PHP хостинга или включите WP_DEBUG_LOG.
• Отключите виновника через режим восстановления, файловый менеджер или WP-CLI.
• При ошибке базы сверьте DB_NAME, DB_USER, DB_PASSWORD, DB_HOST и войдите в phpMyAdmin с этими данными.
• Уберите WP_ALLOW_REPAIR и выключите отладку после ремонта.
• Если были незнакомые файлы или код — ищите точку взлома, а не только восстанавливайте бэкап.
• Настройте RECOVERY_MODE_EMAIL, бэкапы вне хостинга и мониторинг доступности.