Надпись «На сайте возникла критическая ошибка» значит одно: PHP-скрипт WordPress упал с фатальной ошибкой. Виноват конфликт плагина с ядром, неудачное обновление темы или смена версии PHP на хостинге. Проверьте почту администратора: с версии 5.2 движок сам присылает письмо со ссылкой на режим восстановления (wordpress.org/documentation/article/recovery-mode/, сверено 29.09.2026). Письма нет — читайте журнал ошибок и отключайте плагины вручную. Ниже — поддержка WordPress с разбором ошибок и порядок из восьми шагов, который проходят разработчики.
Короткий ответ: дерево диагностики
Не гадайте, что сломалось. Двигайтесь по порядку. Останавливайтесь на первом шаге, который вернёт сайт.
| Шаг | Действие | Как понять, что сработало |
| 1 | Письмо о режиме восстановления пришло? Перейти по ссылке | Админка открылась, виновник назван |
| 2 | Письма нет — включить WP_DEBUG_LOG в wp-config.php | В wp-content/debug.log появилась строка ошибки |
| 3 | Прочитать первую строку Fatal error в логе, найти файл и плагин | Видно, какой плагин или тема указаны в пути |
| 4 | Отключить все плагины: переименовать папку plugins через FTP | Сайт открылся — проблема в плагине |
| 5 | Не помогло — переключить тему на стандартную (Twenty Twenty-Four) | Сайт открылся — проблема в теме |
| 6 | Не помогло — проверить версию PHP в панели хостинга | Ошибка про устаревшую функцию — версия PHP ниже нужной |
| 7 | Проверить лимит памяти (memory_limit) | В логе «Allowed memory size exhausted» |
| 8 | Ничего не помогло — откат сайта из резервной копии | Сайт открылся на версии до сбоя |
Каждый шаг занимает 5–15 минут при наличии доступа к файлам сайта. Нет доступа к FTP и панели хостинга — шаги 2–7 недоступны. Тогда сразу к шагу 8 или к поддержке.
Порядок важен по одной причине: он идёт от самого частого сбоя к самому редкому. Плагины и тема вместе дают большинство случаев критической ошибки — их и проверяют первыми. Версия PHP и память ломают сайт реже, а откат из копии — крайняя мера, когда причина спряталась глубже интерфейса.
Режим восстановления: что это и как его читать
Recovery Mode — встроенный механизм WordPress с версии 5.2, апрель 2019 года. При фатальной ошибке PHP движок ловит сбой сам. Посетителю показывает нейтральный текст вместо белого экрана. Администратору отправляет письмо со ссылкой на восстановление (make.wordpress.org, «Fatal Error Recovery Mode in 5.2»). По ссылке из письма плагин или тема, вызвавшие сбой, временно приостанавливаются. Вы попадаете в админку и видите точное название виновника в уведомлении наверху экрана — не нужно перебирать расширения вслепую.
Письмо не пришло за 10–15 минут? Проверьте папку «Спам» и адрес администратора в базе — таблица wp_users, если доступ есть только через phpMyAdmin. Часто письма нет по третьей причине: хостинг блокирует исходящую почту сайта или SMTP не настроен вовсе. В этом случае Recovery Mode технически работает, но письмо никогда не дойдёт, и полагаться на него нельзя — сразу переходите к журналу.
Журнал ошибок: включаем и читаем debug.log
Без письма единственный способ понять причину — открыть журнал. В wp-config.php, перед строкой «That's all, stop editing!», добавьте три константы (developer.wordpress.org, Debugging in WordPress):
```
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
```
Ошибки начнут писаться в wp-content/debug.log. Посетители белого экрана не увидят — параметр WP_DEBUG_DISPLAY держит вывод скрытым от них, а лог виден только вам. Файла нет и после правки конфига? Проверьте права на запись у папки wp-content — без них WordPress не создаст файл, и ошибка так и останется невидимой, будто её и не было.
Открывайте лог через FTP-клиент или файловый менеджер хостинга: он текстовый, читается любым редактором. Важна первая строка PHP Fatal error — дальше обычно идёт повтор того же сбоя при каждом запросе к сайту, эти строки можно пропускать. Таблица ниже — что означают типовые фразы в логе и что с ними делать.
| Строка в debug.log (сокращённо) | Что значит | Что делать |
Fatal error: Uncaught Error: Call to undefined function в wp-content/plugins/… | Плагин зовёт функцию, которой нет в этой версии PHP или ядра | Отключить плагин, проверить у разработчика совместимость с версией PHP |
Fatal error: Allowed memory size of N bytes exhausted | Скрипту не хватило memory_limit | Поднять memory_limit, отключить тяжёлый плагин, который его исчерпал |
Fatal error: Uncaught Error: Class 'X' not found в wp-content/themes/… | Тема ждёт файл или класс, которого нет — после неполного обновления | Переключить на стандартную тему, переустановить рабочую |
Parse error: syntax error, unexpected … в functions.php | Файл темы правили вручную и оставили опечатку | Откатить файл через FTP или файловый менеджер хостинга |
Fatal error: Cannot redeclare function() | Два плагина объявляют одну и ту же функцию | Отключить один из двух конфликтующих плагинов |
WordPress database error … for query | Повреждена или заблокирована таблица базы | Восстановить таблицу через wp db repair (WP-CLI) или из бэкапа |
В проде строки выглядят длиннее: полный путь к файлу, номер строки, стек вызовов. Для диагностики хватает имени плагина или темы и типа ошибки — остальное нужно только разработчику при глубоком разборе.
Плагины и тема: как отключить без входа в админку
Критическая ошибка блокирует и фронт, и админку? Отключать нужно через файлы, а не через интерфейс — в саму панель WordPress вы всё равно не войдёте. Через FTP или файловый менеджер хостинга зайдите в wp-content/plugins/ и переименуйте папку, например в plugins-off. WordPress не найдёт активные плагины и отключит их все разом. Для данных это безопасно: настройки плагинов не теряются, только код перестаёт запускаться до следующей активации.
Сайт открылся? Включайте плагины по одному. Переименуйте папку обратно, затем в админке активируйте расширения по очереди, пока ошибка не вернётся — так находится конкретный виновник, а не просто факт «дело в плагинах». Есть доступ по SSH — быстрее через WP-CLI: wp plugin deactivate --all, затем wp plugin activate <slug> для каждого плагина по очереди (developer.wordpress.org/cli).
Тот же приём работает с темой. Переключите сайт на папку wp-content/themes/twentytwentyfour через правку записи в базе (wp option update template twentytwentyfour) или командой wp theme activate twentytwentyfour. Панели хостинга различаются интерфейсом — в cPanel это «Диспетчер файлов», в ISPmanager — «Файловый менеджер», но принцип один: переименование папки плагинов и смена активной темы доступны без входа в саму админку WordPress.
PHP и память: версия на хостинге и лимиты
Ядро WordPress рекомендует PHP 8.3 или новее для актуальных релизов (wordpress.org/about/requirements, сверено 29.09.2026). Минимально поддерживаемая версия ниже, но старые ветки PHP патчей безопасности не получают, и именно на них чаще падают устаревшие плагины после автоматического обновления хостингом. Панель хостинга обычно даёт переключить версию PHP без пересборки сайта одним пунктом меню. Ошибка появилась сразу после смены версии PHP провайдером? Откат версии на сутки часто снимает проблему, пока разработчики плагинов не подтянут совместимость с новой веткой.
Вторая частая причина — память. WordPress по умолчанию выделяет фронту 40 МБ, а админке — 256 МБ через константу WP_MAX_MEMORY_LIMIT (developer.wordpress.org/apis/wp-config-php/#wp-memory-limit). Для интернет-магазина или сайта с тяжёлыми плагинами 40 МБ часто мало. Добавьте в wp-config.php строку define('WP_MEMORY_LIMIT', '256M'); — но и это может не сработать. Проверьте лимит memory_limit в самом PHP через панель хостинга: константа WordPress не превысит то, что разрешает сервер, сколько бы мегабайт вы ни указали в коде.
Если ничего не помогло: откат из копии
Восемь шагов не вернули сайт? Такое случается, если сбой не в плагине и не в теме, а в самом ядре после ручного вмешательства в файлы. Дальше без резервной копии не обойтись. Откат к рабочей копии занимает от 15 минут — если копия свежая и проверена на восстановление до инцидента, а не только снята по расписанию.
Ошибка появилась без единого обновления с вашей стороны? Проверьте признаки взлома до отката: заражённые сайты тоже падают с фатальными ошибками, когда вредоносный код ломает структуру файлов. Разбор — в статье про признаки взлома и первые шаги. Резервная копия хранит рабочую версию файлов и базы на момент снятия — восстанавливать нужно оба слоя вместе, иначе структура таблиц базы разъедется с кодом плагинов из старого архива.
Как не допустить повтора
Критическая ошибка почти всегда — следствие обновления вслепую: плагин, тему или ядро поставили на боевой сайт без проверки. Тестовая копия сайта, staging, ловит такие конфликты до того, как их увидят посетители. Обновление сначала ставится там. На прод переносится только рабочий результат.
Второй слой защиты — регулярные обновления плагинов и ядра по графику, а не хаотично, с журналом изменений: сломалось после конкретного обновления — откатывается именно оно, а не все двадцать плагинов подряд. Третий слой — свежая резервная копия перед каждым массовым обновлением, снятая вручную, а не только автоматикой раз в сутки. Три слоя вместе складываются в регламент, а не в разовую починку после очередного падения сайта — именно так его строит поддержка WordPress с разбором ошибок: от разовой правки конфликта плагинов до полной настройки регулярного обслуживания с журналом изменений и проверенными бэкапами.
Выбираете между WordPress и другой системой для нового проекта — сравнение WordPress, Тильды и Битрикса поможет сопоставить устойчивость к таким сбоям и стоимость поддержки на каждой из систем.
Когда чинить самому, а когда звать поддержку
Разовый сбой из-за одного плагина или конфликта темы — задача на 30–60 минут для человека с доступом к FTP и минимальным знакомством с админкой. Внешняя команда такую правку оценивает от 10 000 ₽ (цена со страницы поддержки WordPress, сверено 29.09.2026). Ошибок несколько подряд — сегодня плагин, через неделю тема, ещё через две снова белый экран? Разовые правки быстро складываются в сумму дороже одного пакета: множественные проблемы такого рода обойдутся от 20 000 ₽, полная очистка сайта с настройкой регулярной поддержки — от 40 000 ₽. Дешевле один раз закрыть регламент, чем платить за каждый инцидент отдельно.
Разбирайтесь своими силами, если сайт небольшой, обновления редкие и на восстановление есть час-два без спешки. Зовите поддержку, если сайт — источник заявок или продаж, а цена простоя выше цены правки. Зовите её и в двух других случаях: доступа к FTP нет вовсе, или критическая ошибка возвращается второй-третий раз за месяц — повторение почти всегда значит, что в прошлый раз убрали симптом, а причина осталась внутри.
Частые вопросы
Сколько времени занимает разбор критической ошибки?
Если есть доступ по FTP и письмо от Recovery Mode пришло — 10–20 минут на отключение виновника. Без письма, через журнал и перебор плагинов вручную, разбор занимает от получаса до нескольких часов — зависит от числа установленных расширений.
Ошибка вернулась после отключения всех плагинов — что дальше?
Значит, дело не в плагине. Проверьте тему тем же способом — переключением на стандартную. Не помогло и это? Причина в ядре или в файле wp-config.php, который правили вручную. Здесь без разбора кода или отката из копии не обойтись.
Можно ли разобраться без доступа к SSH?
Да. FTP или файловый менеджер в панели хостинга достаточны для правки wp-config.php, чтения debug.log и переименования папки плагинов. Все шаги дерева диагностики построены именно на них, SSH только ускоряет процесс через WP-CLI.
Нужно ли держать WP_DEBUG включённым постоянно?
Нет. С параметром WP_DEBUG_DISPLAY = false ошибки не видны посетителям, но лишний расход ресурсов и риск утечки путей в логе остаются. Включайте на время диагностики, сразу после — выключайте обратно.
Письмо о режиме восстановления не приходит — почему?
Три частые причины: хостинг блокирует исходящую почту сайта, письмо ушло в спам, или адрес администратора в базе указан неверно. Проверьте их по очереди. Почта на сайте не работает в принципе — переходите сразу к журналу ошибок, не теряя время на ожидание письма.