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

URL: https://chugunov.pro/kriticheskaya-oshibka-wordpress/
Обновлено: 04.10.2026.
Источник: chugunov.pro.

## Коротко

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

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

| Ситуация | Вероятная причина | Первое действие |
| --- | --- | --- |
| Сообщение о критической ошибке после обновления | Плагин или тема несовместимы с ядром или PHP | Открыть ссылку из письма режима восстановления |
| Письма нет, админка не открывается | Фатальная ошибка при загрузке любых страниц | Отключить плагины через FTP или файловый менеджер |
| Ошибка только на части страниц | Сломан шаблон или шорткод конкретного блока | Включить журнал ошибок и открыть проблемную страницу |
| «Ошибка установки соединения с базой данных» | Неверные доступы, упавший MySQL, повреждённые таблицы | Проверить wp-config.php и статус базы у хостинга |

## Основная мысль

**Сообщение «На сайте возникла критическая ошибка» — это защитный экран WordPress, а не поломка сайта целиком: система знает, какой файл вызвал сбой, и ваша задача — узнать это у неё через письмо восстановления или журнал ошибок, а не переустанавливать всё подряд.**

До версии 5.2 фатальная ошибка PHP превращала сайт в белый экран без каких-либо пояснений. Теперь WordPress перехватывает сбой, показывает посетителям нейтральное сообщение и отправляет администратору письмо с технической информацией: какой плагин или тема упали и в каком файле. Это экономит главный ресурс при аварии — время на поиск причины.

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

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

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

### Как работает режим восстановления

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

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

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

- На сайте не настроена отправка почты, и письма от WordPress не доходят вообще или попадают в спам.
- Адрес администратора в настройках давно не используется.
- Ошибка возникает так рано при загрузке, что механизм перехвата не успевает сработать.
- Письмо уже отправлялось недавно: WordPress не шлёт уведомление при каждом повторе ошибки, чтобы не засыпать почту.

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

## Типичные причины критической ошибки WordPress

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

### WordPress: ошибка плагинов после обновления

Самый распространённый случай. Плагин обновился и стал вызывать функцию, которой нет в вашей версии ядра, WooCommerce или PHP. Или два плагина подключают разные версии одной и той же библиотеки и конфликтуют. Особенно рискованно обновлять все плагины одной кнопкой: если сайт упал, непонятно, какой из десяти обновлённых стал причиной.

### Тема и дочерняя тема

Правка functions.php через встроенный редактор — классический способ положить сайт одной пропущенной скобкой. Второй сценарий — обновление родительской темы, после которого шаблоны дочерней темы вызывают удалённые функции. Третий — купленная тема со встроенными плагинами-компаньонами, которые давно не обновлялись.

### Версия PHP

Хостинги регулярно выводят из эксплуатации старые версии PHP и переключают сайты на новые. Код, написанный несколько лет назад, может использовать устаревшие конструкции, которые в новой версии вызывают фатальную ошибку. Обратная ситуация тоже бывает: свежий плагин требует более новой версии PHP, чем стоит на сервере.

### Нехватка памяти и ресурсов

Если скрипт упирается в memory_limit, WordPress тоже может показать сообщение о критической ошибке. Это типично для импорта товаров, генерации миниатюр, тяжёлых конструкторов страниц и отчётов WooCommerce. В журнале в таком случае будет запись о превышении допустимого объёма памяти.

### Повреждённые файлы и взлом

Прерванное обновление, неудачная ручная загрузка файлов по FTP или вредоносный код тоже приводят к фатальным ошибкам. Если в журнале фигурируют файлы с бессмысленными именами или код, которого вы не ставили, это повод проверить сайт на заражение. Порядок действий описан в статье [о восстановлении взломанного WordPress](https://chugunov.pro/wordpress-vzlomali-vosstanovlenie/).

## Как вернуть сайт: пошаговая инструкция

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

### Шаг 1. Проверить почту администратора

Найдите письмо от WordPress о технической проблеме на сайте, в том числе в папке спама. Перейдите по ссылке режима восстановления, откройте раздел «Плагины» или «Внешний вид → Темы» и деактивируйте указанное расширение. Затем выйдите из режима восстановления и проверьте сайт в другом браузере или в режиме инкогнито.

### Шаг 2. Отключить плагины через FTP

Если письма нет, подключитесь к сайту по FTP или откройте файловый менеджер в панели хостинга. Переименуйте папку wp-content/plugins, например в plugins-off. WordPress не найдёт плагины и отключит их все. Если сайт открылся, верните папке исходное имя: плагины останутся выключенными, и их можно включать в админке по одному, проверяя сайт после каждого.

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

### Шаг 3. Проверить тему

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

### Шаг 4. Включить журнал ошибок

Когда причина неочевидна, включите запись ошибок в файл. В wp-config.php, выше строки с комментарием о завершении редактирования, задайте константы:

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

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

### Шаг 5. Использовать WP-CLI, если есть SSH

На VPS и хостингах с SSH-доступом удобнее работать через WP-CLI. Он позволяет отключить плагины, не открывая админку:

```
wp plugin list
wp plugin deactivate --all
wp plugin deactivate имя-плагина --skip-plugins
```

Флаг —skip-plugins не даёт загрузиться сломанным плагинам во время выполнения самой команды. Аналогично работает —skip-themes для проблемной темы.

### Шаг 6. Откатить версию или PHP

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

## Ошибка базы данных WordPress

Отдельная группа проблем — когда WordPress не может работать с базой данных. Выглядит это иначе: вместо сообщения о критической ошибке появляется текст об ошибке установки соединения с базой данных.

### Ошибка соединения с базой данных WordPress: причины

| Причина | Как проверить | Что сделать |
| --- | --- | --- |
| Неверные доступы в wp-config.php | Сравнить DB_NAME, DB_USER, DB_PASSWORD, DB_HOST с данными в панели хостинга | Исправить значения или сбросить пароль пользователя базы |
| Сервер MySQL недоступен | Посмотреть уведомления и статус услуг в панели хостинга | Написать в поддержку хостинга |
| Превышен лимит соединений или ресурсов | Ошибка появляется в часы пик и исчезает сама | Кеширование, оптимизация запросов, тариф мощнее |
| Повреждены таблицы | Сообщения о повреждённых таблицах в журнале | Восстановить таблицы средствами хостинга или WordPress |

После переноса сайта ошибка соединения почти всегда означает, что в wp-config.php остались доступы от старого сервера. Подробнее о подводных камнях переезда — в статье [о переносе сайта на другой хостинг](https://chugunov.pro/perenos-sajta-na-drugoj-hosting/).

### Восстановление повреждённых таблиц

В WordPress есть встроенный инструмент восстановления базы. Для его включения в wp-config.php добавляют строку:

```
define( 'WP_ALLOW_REPAIR', true );
```

После этого инструмент доступен по адресу /wp-admin/maint/repair.php даже без авторизации. Именно поэтому константу нужно удалить сразу после восстановления. Альтернатива — проверка и восстановление таблиц через phpMyAdmin в панели хостинга.

## Другие частые ошибки WordPress

Критическая ошибка — не единственная, с которой сталкиваются владельцы. Ниже — короткий справочник по остальным ошибкам WordPress, которые встречаются чаще всего.

### Белый экран без сообщения

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

### Сайт застрял в режиме обслуживания

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

### Ошибки 500, 502 и 503

Эти коды формирует сервер, и причины у них шире, чем у критической ошибки PHP: перегрузка, лимиты тарифа, неверная связка nginx и PHP-FPM. Начинают с журнала ошибок в панели хостинга и уведомлений о работах на сервере.

### Сломанная вёрстка после обновления

Сайт открывается, но блоки съехали, пропали стили или перестали работать слайдеры. Это не фатальная ошибка, а конфликт скриптов, кеширования или минификации. Начинают с очистки кеша плагина оптимизации и CDN, затем отключают объединение CSS и JavaScript.

## Как обновлять WordPress, чтобы ошибка не повторилась

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

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

1. **Сделать копию.** Файлы и база, с сохранением вне сервера сайта.
2. **Прочитать список изменений.** На странице плагина обычно указаны минимальные версии WordPress и PHP и важные изменения.
3. **Обновить тестовую копию.** Многие хостинги умеют создавать её из панели, иначе её разворачивают на поддомене с закрытым доступом.
4. **Проверить ключевые сценарии.** Главная, каталог, карточка товара, корзина, оформление заказа, формы заявок, вход в личный кабинет.
5. **Обновить рабочий сайт в тихие часы.** По одному расширению, с проверкой после каждого.
6. **Посмотреть журнал ошибок.** Даже если сайт открывается, в debug.log могут появиться предупреждения, которые позже станут фатальными.

### Автообновления: включать или нет

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

## Сценарии из практики

Ситуации ниже собирательные, но хорошо показывают логику поиска причины.

### Обновили всё одной кнопкой

Владелец магазина на WooCommerce обновил ядро, тему и полтора десятка плагинов разом. Сайт показал сообщение о критической ошибке, письмо ушло на старый ящик прежнего подрядчика. Через файловый менеджер отключили плагины, по журналу нашли модуль доставки, несовместимый с новой версией WooCommerce. Модуль откатили, остальное включили, обновление модуля отложили до выхода исправленной версии.

### Хостинг сменил версию PHP

Корпоративный сайт упал в выходные без каких-либо действий со стороны владельца. В журнале — фатальная ошибка в файле темы, написанной много лет назад. Хостинг перевёл аккаунт на новую версию PHP. Временно вернули прежнюю версию, затем исправили устаревшие конструкции в теме и перешли на актуальный PHP.

### Правка functions.php из админки

Администратор добавил в functions.php фрагмент кода из интернета через «Внешний вид → Редактор файлов темы» и пропустил точку с запятой. Сайт и админка перестали открываться. Исправили файл по FTP за пару минут, а редактор файлов отключили константой DISALLOW_FILE_EDIT, чтобы история не повторилась.

## На чём опасно экономить

Длинные простои случаются не из-за сложности ошибки, а из-за отсутствия базовой гигиены. Вот что обходится дороже всего.

### Типичные ошибки владельцев

- **Нет резервных копий или они хранятся на том же сервере.** При серьёзном сбое копия пропадает вместе с сайтом.
- **Обновления на рабочем сайте без проверки.** Тестовая копия позволяет поймать конфликт до того, как его увидят клиенты.
- **Десятки плагинов для мелочей.** Каждое расширение — дополнительная точка отказа и отдельный график обновлений.
- **Заброшенные и «обнулённые» темы и плагины.** Они не обновляются под новые версии PHP и часто содержат вредоносный код.
- **Неактуальный адрес администратора.** Письмо режима восстановления уходит в пустоту.
- **Не настроена отправка почты.** WordPress не может сообщить о проблеме, а заявки с форм теряются.

### Чек-лист профилактики

- Автоматические копии файлов и базы, хранящиеся вне сервера сайта.
- Проверка восстановления из копии хотя бы раз в квартал.
- Тестовая копия сайта для обновлений ядра, темы и плагинов.
- Обновление плагинов по одному с проверкой ключевых страниц.
- Актуальная версия PHP, которую поддерживают ядро и все расширения.
- Одна стандартная тема WordPress, установленная про запас.
- Редактор файлов в админке отключён константой DISALLOW_FILE_EDIT.
- Рабочий адрес администратора и настроенная отправка писем через SMTP.
- Мониторинг доступности и регулярный просмотр раздела диагностики в Яндекс Вебмастере.
- Записанные доступы к хостингу, FTP, базе данных и админке.

Если у сайта нет человека, который отвечает за обновления и копии, стоит договориться о регулярном обслуживании. Что обычно входит в такую работу, разобрано в статье [о поддержке сайта](https://chugunov.pro/podderzhka-sajta-chto-vhodit/).

## Частые вопросы

### Что делать, если на сайте возникла критическая ошибка, а доступа к админке нет?

Отключите плагины переименованием папки wp-content/plugins через FTP или файловый менеджер хостинга. Если не помогло, переименуйте папку активной темы. Затем включите журнал ошибок, чтобы найти точную причину.

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

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

### На сайте произошла критическая ошибка — это то же самое?

Да, это та же ошибка в другой формулировке. Текст сообщения зависит от версии WordPress и языкового пакета.

### Где найти письмо режима восстановления?

Оно приходит на адрес администратора из «Настройки → Общие». Проверьте папку спама. Если адрес устарел, после восстановления сайта замените его или задайте RECOVERY_MODE_EMAIL в wp-config.php.

### Как понять, какой плагин вызвал ошибку?

Письмо режима восстановления и файл wp-content/debug.log указывают путь к файлу. Имя папки в пути после wp-content/plugins — это и есть виновник.

### WordPress: ошибка плагинов после обновления: откатывать или ждать исправления?

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

### Что означает ошибка соединения с базой данных WordPress?

WordPress не может подключиться к MySQL. Проверьте доступы в wp-config.php и статус базы в панели хостинга. Если доступы верны, а ошибка держится, обращайтесь в поддержку хостинга.

### Можно ли самому исправить ошибку базы данных WordPress?

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

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

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

### Сколько стоит устранение критической ошибки?

Зависит от причины. Конфликт одного плагина обычно устраняется за час-два, несовместимость темы с новым PHP или последствия взлома требуют больше времени. Поддержка сайта у меня стоит от 2 000 ₽ в час.

## Итог

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

Чтобы такие эпизоды случались реже, нужны копии вне сервера, тестовая среда для обновлений, актуальный PHP, минимум лишних плагинов и рабочая почта администратора. Отдельная история — ошибка соединения с базой данных: её чаще решают доступы в wp-config.php и поддержка хостинга.

Если сайт уже показывает критическую ошибку или падает после каждого обновления, я как частный разработчик на WordPress и 1С-Битрикс найду причину по журналам, верну работоспособность без потери данных и настрою безопасный порядок обновлений. Работаю напрямую, без посредников — подробности на странице [восстановления сайта](https://chugunov.pro/uslugi/vosstanovlenie-sajta/).

- 04.08.2026

## Связанное на сайте

- Услуга [Доработка сайта WordPress](https://chugunov.pro/uslugi/dorabotka-sajta-wordpress/)
- Справочник API [Справочник API WordPress](https://chugunov.pro/api-wordpress/)
- Глоссарий [Глоссарий: WordPress](https://chugunov.pro/glossary/wordpress/)

Автор статьи [Чугунов Алексей](https://chugunov.pro/about/) Fullstack-разработчик: 1С-Битрикс, WordPress, PHP
[Обо мне](https://chugunov.pro/about/)

Рубрики блога

- [Продажи](https://chugunov.pro/category/sales/) 16
- [Продвижение](https://chugunov.pro/category/prodvizhenie/) 22
- [Создание сайтов](https://chugunov.pro/category/sozdanie-sajtov/) 75
- [Интересное](https://chugunov.pro/category/interesnoe/) 13

Остались вопросы?

Отправьте сообщение, и я свяжусь с вами в ближайшее время

Или звоните, сразу обсудим детали.

[+7 (915) 016-99-88](tel:79150169988)