Если на WordPress появилось сообщение «На сайте возникла критическая ошибка», не нужно в панике редактировать всё подряд. Чаще всего проблему вызывает последнее изменение: правка functions.php, неудачное обновление плагина, конфликт темы, неподходящая версия PHP или синтаксическая ошибка в коде. Ниже — спокойный пошаговый план, что проверить сначала, как вернуть сайт и чего лучше не делать наугад.
Почему появляется критическая ошибка WordPress
Запрос «критическая ошибка WordPress» обычно появляется не сам по себе, а после конкретного действия: поставили новый плагин, обновили тему, добавили код в functions.php, изменили wp-config.php, переключили версию PHP у хостинга или загрузили несовместимый сниппет. WordPress в такой ситуации не может завершить обычную загрузку и показывает аварийное сообщение.
На практике чаще всего ломается не «весь WordPress вообще», а один конкретный участок: плагин, тема, пользовательский PHP-код или окружение сервера. Поэтому главная задача — не метаться, а найти последнее изменение и аккуратно сузить причину.
Люди начинают одновременно менять PHP-версию, отключать случайные плагины, редактировать файлы в браузере и чистить кэш. После этого уже непонятно, что было настоящей причиной, а что стало второй поломкой. Сначала зафиксируйте последнее изменение и только потом двигайтесь по шагам.
Что проверить в первые 10 минут
Если сайт упал и вы видите формулировку «на сайте возникла критическая ошибка WordPress, что делать», начните с базовой диагностики. Эти действия дают больше пользы, чем хаотические правки.
- Вспомните последнее изменениеЧто было прямо перед поломкой: новый плагин, обновление темы, вставка PHP-кода, редактирование
functions.php, изменениеwp-config.phpили переключение версии PHP. - Проверьте, есть ли резервная копияЕсли бэкап свежий и ошибка появилась только что, это уже ваш безопасный путь назад. Но сначала всё равно полезно понять источник проблемы.
- Посмотрите письмо WordPress Recovery ModeИногда WordPress отправляет письмо администратору с указанием проблемного плагина, темы или файла.
- Проверьте лог ошибок PHPИщите точный файл и строку: именно там часто видно, почему произошёл fatal error или parse error.
- Не редактируйте живой сайт наугадЕсли приходится вносить правку, сначала сохраните копию текущего файла или работайте через бэкап/локальную копию.
Если критическая ошибка появилась после правки functions.php
Очень частый сценарий — ошибка functions.php WordPress. Кажется, что изменили всего одну строчку, но сайт после этого перестал открываться. Чаще всего причиной оказывается синтаксическая мелочь: лишняя или потерянная скобка, незакрытая кавычка, пропущенная точка с запятой, неправильный массив, устаревшая функция или код, не подходящий для текущей версии PHP.
В таком случае самый разумный ход — не писать новый код поверх старого, а вернуть последнюю рабочую версию файла или открыть именно тот участок, который меняли последним. Если в логе уже указан Parse error и путь до файла, не нужно искать проблему по всему сайту: начните с конкретной строки и 5–10 строк вокруг неё.
- Если правили
functions.phpвручную — восстановите предыдущую версию файла. - Если вставляли сниппет через плагин — временно отключите именно этот плагин или проблемный сниппет.
- Если после апдейта темы появились ошибки — попробуйте временно вернуть предыдущую тему или её рабочую копию.
- Если ошибка началась после смены PHP-версии — откатитесь на прежнюю или проверьте совместимость темы и плагинов.
Если вы не понимаете, что означает сообщение Unclosed '{' does not match ']', unexpected token или call to undefined function, лучше остановиться после резервной копии и передать задачу человеку, который сможет аккуратно прочитать лог и внести точечную правку. Вторая ошибка поверх первой часто обходится дороже.
Пошаговое восстановление сайта WordPress
Когда причина ещё не ясна, используйте спокойный порядок: сканировал ситуацию → нашёл последнее изменение → вернул рабочее состояние → перепроверил сайт. Такой подход лучше, чем «дергать всё подряд».
- Сделайте копию текущего состоянияДаже сломанный файл лучше сохранить отдельно. Это поможет сравнить изменения и при необходимости откатиться не только к бэкапу, но и к конкретной версии файла.
- Откатите самый подозрительный файл или изменениеЕсли ошибка появилась сразу после одной правки, начинайте именно с неё, а не с полной переборки сайта.
- Временно отключите проблемный плагин или темуЕсли лог показывает плагин, а доступ в админку недоступен, его можно временно деактивировать через файловый менеджер или FTP, переименовав папку.
- Проверьте PHP-версию и совместимостьИногда код сам по себе корректен, но не поддерживается текущей версией PHP или конфликтует со старым плагином.
- Включайте debug аккуратно и ненадолгоСмысл debug не в том, чтобы оставить его навсегда включённым на живом сайте, а в том, чтобы быстро получить точную причину ошибки.
- После исправления проверьте весь минимумГлавная, внутренняя страница, админка, форма, мобильная версия, кэш и только затем дальнейшие изменения.
Если вы уже восстановили сайт, не спешите сразу снова вставлять тот же код. Сначала выясните, почему именно он сломал WordPress: синтаксис, несовместимость с PHP, конфликт с плагином или просто не тот файл для вставки. Без этого ошибка легко повторится.
Нужно ли включать WP_DEBUG
WP_DEBUG — полезный инструмент, но только когда им пользуются аккуратно. Он помогает увидеть предупреждения и ошибки PHP, а вместе с логированием — найти проблемный файл и строку. Однако на живом сайте не стоит надолго включать режим, который показывает технические сообщения посетителям.
Безопасный смысл debug такой: включили на короткое время, получили причину, сохранили лог, исправили проблему, вернули боевые настройки. Если у вас нет уверенности, лучше сначала работать на копии сайта или хотя бы использовать запись в лог, а не публичный вывод ошибок на экран.
Когда стоит остановиться и не ломать дальше
Если сайт связан с заявками, SEO-трафиком, рекламой или продажами, каждая лишняя неаккуратная правка увеличивает простой. В этот момент важнее не «добить исправление самому любой ценой», а быстро вернуть рабочее состояние и уже потом разбираться в деталях.
Если нужен аккуратный разбор причины, правка файла, проверка WordPress, темы, плагинов и серверного окружения без случайных поломок, можно перейти в раздел услуг ANVARTAR или сразу описать проблему в Telegram со скриншотом ошибки.
Если сайт уже упал после изменения кода, обновления темы или плагина, полезнее сначала вернуть рабочее состояние, а затем спокойно разобрать причину. Это особенно важно, когда нельзя рисковать SEO, заявками и доступностью страниц.
Частые вопросы
Что значит «критическая ошибка WordPress»?
Это общее аварийное сообщение WordPress о том, что сайт не смог корректно завершить загрузку. Причина обычно глубже: фатальная ошибка PHP, конфликт темы, проблемный плагин или неудачная правка кода.
Что делать, если админка WordPress тоже не открывается?
Тогда проверяйте бэкап, письмо Recovery Mode, лог ошибок и последние изменения через файловый менеджер хостинга или FTP. При необходимости временно отключают конкретный проблемный плагин или возвращают рабочую версию файла.
Где искать parse error в WordPress?
Обычно точный файл и строка видны в журнале ошибок PHP. Если ошибка возникла после правки functions.php, начните именно с этого файла и последнего изменённого участка.
Нужно ли сразу восстанавливать весь сайт из бэкапа?
Если есть свежая копия и простой критичен, это нормальный путь. Но параллельно полезно понять реальную причину ошибки, иначе она может повториться при следующей правке или обновлении.
Может ли такая ошибка повлиять на SEO?
Краткая неполадка обычно не катастрофа, но длительная недоступность страниц уже вредна: пользователи уходят, а поисковик может хуже обходить или временно снижать доверие к странице. Поэтому важны скорость восстановления и повторная проверка основных URL.