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

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

Ниже — порядок действий, который возвращает сайт в среднем за пятнадцать-двадцать минут даже без доступа к админке. Отдельно покажу, что в это время видит поисковый робот и почему простой в сутки бьёт по обходу сильнее, чем кажется. В SEO с 2005 года, и подобные аварии на клиентских сайтах разбираю регулярно — сценарий повторяется почти всегда один и тот же.

Что это за экран и откуда он берётся

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

Заглушка появляется в трёх ситуациях. Первая — фатальная ошибка PHP: вызов несуществующей функции, обращение к методу у пустого объекта, несовместимость кода с текущей версией интерпретатора. Вторая — исчерпание лимита памяти: скрипт запросил больше, чем разрешено директивой memory_limit, и был убит. Третья — превышение времени выполнения, когда операция не уложилась в max_execution_time.

Письмо в режиме восстановления — самый быстрый путь

Одновременно с обработчиком ошибок в ядро добавили режим восстановления. При фатальной ошибке WordPress отправляет письмо на адрес администратора, указанный в разделе настроек. Это тот самый адрес из поля «Email-адрес администратора», а не почта вашей учётной записи — путаница здесь встречается постоянно.

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

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

Журнал ошибок: включаем и читаем

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

Откройте wp-config.php в корне сайта и найдите строку с WP_DEBUG. Она есть всегда, обычно со значением false. Замените блок на такой:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Смысл комбинации: отладка включена, ошибки пишутся в файл, но на экран не выводятся. Последнее принципиально — вывод ошибок посетителям и роботам раскрывает структуру сервера и ломает вёрстку. Все строки при этом окажутся в файле wp-content/debug.log.

Дальше обновите страницу сайта, чтобы ошибка повторилась и попала в журнал, и откройте debug.log. Смотреть надо на последние строки — они соответствуют вашему обращению. Записи бывают четырёх типов, и реагировать на них надо по-разному.

Запись в журнале	Что означает	Что делать
PHP Fatal error: Uncaught Error: Call to undefined function	Код вызывает функцию, которой нет: плагин рассчитан на другую версию ядра или на расширение PHP, не установленное на сервере	Отключить названный плагин, проверить требования к версиям, при необходимости попросить хостинг включить расширение
PHP Parse error: syntax error, unexpected	Синтаксическая ошибка в файле — почти всегда результат ручной правки темы или вставки чужого сниппета	Восстановить файл из резервной копии или убрать последнюю вставку; номер строки указан в той же записи
Allowed memory size of N bytes exhausted	Скрипту не хватило памяти. Часто вылезает при импорте, генерации карты сайта, обработке изображений	Поднять лимит памяти, а затем найти операцию, которая столько потребляет
PHP Warning / Notice / Deprecated	Предупреждения. Сайт от них не падает, но они забивают журнал и мешают увидеть настоящую причину	Игнорировать при поиске аварии, разобрать потом; массовые Deprecated говорят о несовместимости с новой версией PHP

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

После восстановления сайта журнал обязательно выключите — верните WP_DEBUG в false, а сам debug.log удалите. Файл лежит в общедоступной папке и при известном имени читается из браузера кем угодно; заодно он растёт и способен занять всё место на диске.

Отключаем плагины через файловую систему

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

Порядок действий такой. Зайдите по FTP в wp-content и переименуйте папку plugins в plugins-off. Откройте сайт. Если он ожил — виновник среди плагинов, что подтверждается сразу. Верните папке исходное имя: все плагины при этом останутся деактивированными, а их настройки сохранятся в базе.

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

Стандартная тема и лимит памяти

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

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

Отдельная и очень частая причина — память. Проверяется быстро: добавьте в wp-config.php выше строки с комментарием об окончании редактирования две директивы.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Первая задаёт лимит для фронтенда, вторая — для админки и фоновых операций. Учтите: эти константы не могут прыгнуть выше того, что разрешено в конфигурации PHP на сервере. Если хостинг держит memory_limit на 128 мегабайтах, значение 256 останется пожеланием. Реальный потолок поднимается в панели хостинга либо в файле php.ini, а на некоторых тарифах — только обращением в поддержку.

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

Метод половинного деления: находим виновника

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

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

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

Что видит робот, пока сайт лежит

Пока посетитель читает про критическую ошибку, робот получает не текст, а код ответа. И вот это уже вопрос продвижения, а не только удобства.

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

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

Третье: в панели вебмастера растёт число ошибок в разделе диагностики, и там же в статистике обхода видно провал по количеству загруженных страниц. По графику легко определить и дату аварии, и длительность. Смысл кодов ответа и их влияние на индекс подробно расписаны в материале «Коды ответа сервера: руководство с примерами использования».

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

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

Чеклист восстановления и когда он не поможет

Ниже — порядок, которого стоит держаться. Он выстроен по принципу «сначала дешёвое и быстрое, потом трудоёмкое». Отклоняться от него имеет смысл только тогда, когда вы точно знаете, что сломали.

Шаг	Действие	Признак, что причина найдена	Время
1	Проверить почту администратора, найти письмо режима восстановления	В письме назван плагин или тема	2 минуты
2	Вспомнить последнее действие: обновление, правку файла, смену версии PHP	Есть очевидный кандидат — откатить именно его	1 минута
3	Включить WP_DEBUG_LOG, обновить страницу, прочитать конец debug.log	В журнале есть строка Fatal error с путём к файлу	5 минут
4	Переименовать папку plugins целиком	Сайт открылся — причина среди плагинов	2 минуты
5	Переименовать папку активной темы	Сайт открылся на стандартной теме — причина в теме	2 минуты
6	Поднять WP_MEMORY_LIMIT и проверить реальный memory_limit сервера	Ошибка исчезла — упирались в память	5 минут
7	Включать плагины половинами до повторения ошибки	Найден конкретный плагин или пара конфликтующих	10 минут
8	Проверить версию PHP и требования компонентов	Массовые Deprecated в журнале, ошибка после смены версии	5 минут
9	Выключить отладку, удалить debug.log, отправить главные страницы на переобход	Сайт отдаёт 200, в вебмастере пошли успешные обходы	5 минут

Если на шаге 8 выяснилось, что дело в несовместимости с новой версией интерпретатора, откат на старую — временная мера. Устаревшие версии PHP перестают получать исправления безопасности и заметно медленнее; какую версию держать и что даёт переход, я разбирал в статье «Какой PHP нужен WordPress в 2026 году и что даёт переход на 8.3». Если после аварии сайт работает, но остались следы — битые страницы, съехавшая вёрстка, отвалившиеся формы, — это уже задача на доработку сайта, и решается она отдельно от аварийного восстановления.

Есть три ситуации, где описанный порядок применять не стоит.

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

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

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

И общее правило: не правьте файлы через встроенный редактор тем и плагинов в админке. Одна опечатка в functions.php — и вы теряете доступ к тому самому редактору, которым правили. Отключается редактор одной строкой в wp-config.php: define( 'DISALLOW_FILE_EDIT', true ); — и это одна из немногих настроек, которую стоит включить на любом сайте сразу.

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

Можно ли попасть в админку, если сайт отдаёт критическую ошибку? Иногда да: если падает только фронтенд, адрес /wp-admin/ откроется. Но чаще плагин подключается на общем этапе загрузки и роняет обе части сразу. Пробовать стоит в первую очередь — это быстрее всего.

Почему после переименования папки plugins плагины остались выключенными? Так и задумано. Ядро не нашло файлы и убрало их из списка активных в базе. Настройки при этом не удаляются — они лежат в таблице опций и подхватятся при повторном включении.

Что делать, если debug.log не создаётся? Проверьте права на папку wp-content — нужна возможность записи. Второй вариант: ошибка происходит до чтения wp-config.php, тогда журнала не будет в принципе и надо смотреть журнал ошибок PHP в панели хостинга.

Влияет ли разовая авария на позиции? Час-два не влияет заметно. Сутки и больше — влияют: падает скорость обхода, часть страниц временно выпадает из поиска. Возврат занимает от нескольких дней до месяца в зависимости от размера сайта.

Нужно ли что-то делать в панели вебмастера после восстановления? Да. Убедитесь, что главная и ключевые разделы отдают 200, отправьте их на переобход и посмотрите статистику обхода через неделю: график должен вернуться к прежним значениям.

Как понять, что виноват хостинг, а не сайт? Откройте любой статический файл — картинку из папки загрузок или robots.txt. Если он отдаётся нормально, сервер жив и дело в PHP-коде. Если не отдаётся ничего, проблема на уровне сервера.

Коротко

• Экран критической ошибки — это фатальная ошибка PHP, перехваченная ядром; причина всегда конкретна и указана в журнале.
• Первым делом проверьте почту администратора: письмо режима восстановления называет виновника и даёт ссылку входа в админку.
• Без письма включайте WP_DEBUG_LOG с выключенным выводом на экран и читайте последние строки debug.log.
• Переименование папки plugins, затем папки темы разделяет причины за четыре минуты; конфликт ищется половинным делением.
• Лимит памяти поднимается константами, но упирается в потолок сервера — это временная мера, а не решение.
• Для робота авария выглядит как код 500: сутки простоя роняют скорость обхода и выбивают часть страниц из индекса, возврат занимает недели.

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