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

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

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

За надписью стоит фатальная ошибка PHP (fatal error): сбой, после которого PHP перестаёт выполнять код страницы. Причина почти всегда конкретная: плагин вызвал функцию, которой в новой версии уже нет; тема передала в функцию данные не того типа; скрипту не хватило памяти.

С версии 5.2 WordPress перехватывает такие сбои: вместо белого экрана посетитель видит страницу с текстом ошибки, а WordPress пытается определить, какой плагин или тема её вызвали. Текст зависит от места сбоя:

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

Две другие поломки выглядят похоже, но устроены иначе. «Ошибка установки соединения с базой данных» значит, что WordPress не подключился к MySQL: в wp-config.php неверные данные доступа или не работает сервер базы данных. Плагины здесь обычно ни при чём, разбираться начинают с хостингом. Пустая белая страница или «500 Internal Server Error» без текста от WordPress значит, что страница об ошибке не успела показаться: сбой произошёл на уровне сервера (например, из-за ошибки в .htaccess) или обработчик фатальных ошибок отключён константой WP_DISABLE_FATAL_ERROR_HANDLER. Тогда причину ищут в журнале ошибок PHP в панели хостинга (о нём в шаге 2).

Письмо «На сайте возникли технические проблемы»

Когда WordPress определил виновника, он отправляет письмо с темой «[Название сайта] На сайте возникли технические проблемы» на адрес администратора из «Настройки → Общие». Другой адрес задаётся константой RECOVERY_MODE_EMAIL в wp-config.php. В письме названы плагин или тема с ошибкой, страница, где она произошла, технические подробности и ссылка для входа в режим восстановления.

Режим восстановления (recovery mode) приостанавливает сломанный плагин или тему только в браузере того, кто вошёл по ссылке. Посетители по-прежнему видят ошибку, зато вы попадаете в админку и можете отключить плагин или вернуть его прошлую версию.

Письмо приходит не всегда, на это три причины.

1. WordPress отправляет его, только если ошибка случилась в админке, на странице входа или в некоторых служебных фоновых запросах админки (AJAX). Если падает только страница оформления заказа, письма не будет, пока кто-нибудь не откроет /wp-admin/. Поэтому первым делом откройте админку: если ошибка повторится там и виноват плагин или тема, письмо уйдёт.
2. По умолчанию письмо уходит не чаще раза в сутки, и ссылка в нём действует столько же. Если за последние 24 часа письмо уже было, нового не будет. Найдите прежнее, в том числе в спаме: пока сутки не истекли, ссылка работает.
3. Письмо отправляется через обычную почту сайта. Если отправка почты не настроена, оно может не дойти или попасть в спам. Для этого случая ниже есть путь без письма.

Как устроен механизм, разработчики ядра описали в заметке о защите от фатальных ошибок в WordPress 5.2.

Почему WordPress падает после обновления

На сайте три слоя кода: ядро WordPress, тема и плагины. Все они работают на той версии PHP, которую выставил хостинг. Обновили один слой, и код другого может перестать с ним работать. Типичные случаи ниже.

Плагин не готов к новой версии ядра. 19 августа 2026 года вышел WordPress 7.1. На следующий день разработчики плагина кеширования WP Rocket подтвердили: на 7.1 плагин роняет сайты с фатальной ошибкой, админка тоже могла не открываться. Исправленную версию 3.23.2.2 выпустили примерно через два с половиной часа после того, как нашли причину. Тем, кто остался без админки, документация WP Rocket советовала переименовать папку плагина через FTP. Сам плагин в тот день не обновлялся: сайты сломало обновление ядра.

Плагин обновился с ошибкой. 29 июля 2026 года владелец сайта написал на форуме wordpress.org: после обновления YOP Poll с 7.0.7 до 7.0.8 админка перестала открываться из-за критической ошибки. Помог откат на 7.0.7. Владелец выключил автообновления плагина, и поддержка плагина решение одобрила.

Тема или код в functions.php. Чаще других ломаются темы, купленные много лет назад и с тех пор не обновлявшиеся, и правки прямо в файлах темы без дочерней темы (темы-надстройки, правки в которой переживают обновление основной).

Смена версии PHP. Хостинг перевёл сайт на PHP 8.2 или 8.3, а старый плагин использует функции, которых в новой версии нет. Сроки поддержки PHP и порядок перехода разобраны в статье о том, что делать владельцу сайта, когда PHP 8.1 и 8.2 остаются без поддержки.

Не хватило памяти. В журнале это запись «Allowed memory size of … bytes exhausted». После обновления плагин может получить тяжёлую функцию и упереться в лимит памяти PHP. По умолчанию WordPress пытается выделить себе 40 МБ на обычном сайте и 64 МБ на мультисайте (сети сайтов на одной установке WordPress). Лимит поднимают константой WP_MEMORY_LIMIT, верхнюю границу задаёт хостинг. Поднятый лимит убирает симптом; если плагину перестало хватать памяти, которой до обновления хватало с запасом, разбираться нужно с плагином.

Обновление прервалось. Хостинг оборвал процесс по тайм-ауту, закончилось место на диске, закрылась вкладка браузера. Часть файлов осталась старой, часть стала новой. Признак такого сбоя — надпись «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту». На время обновления WordPress создаёт в корне сайта файл .maintenance и через 10 минут перестаёт его учитывать. Если надпись держится дольше, вы, скорее всего, видите сохранённую копию страницы: сбросьте кеш плагина, сервера и CDN (сети серверов, которая раздаёт копии страниц, например Cloudflare). Сам файл .maintenance после неудачного обновления можно удалить вручную.

Конфликт двух плагинов. По отдельности каждый работает, вместе падают. Частые пары: плагин кеширования и конструктор страниц; два плагина в оформлении заказа WooCommerce.

Сайт лежит: порядок действий

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

Шаг 1. Войдите по ссылке из письма

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

Письма нет? Откройте адрес-сайта/wp-admin/ (почему это помогает, сказано выше), подождите несколько минут и проверьте папку «Спам». Если письмо так и не пришло, переходите к шагу 2.

Шаг 2. Найдите ошибку в журнале

Сначала откройте панель хостинга. У большинства хостингов там есть журнал ошибок PHP (error_log), и фатальная ошибка обычно уже записана в нём с именем файла и номером строки, без настроек в WordPress. Если журнала нет или он пуст, включите журнал самого WordPress, файл debug.log. Нужен доступ к файлам сайта: файловый менеджер в панели хостинга, FTP или SFTP. В wp-config.php перед строкой /* That's all, stop editing! Happy publishing. */ добавьте (или исправьте, если такие строки уже есть):

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

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

WP_DEBUG_DISPLAY со значением false обязателен: иначе текст ошибки с путями к файлам увидят посетители. Вторая оговорка: папка wp-content открыта в интернет, и на многих серверах debug.log можно скачать по прямому адресу. Когда причина найдена, верните WP_DEBUG в false и удалите файл. Если журнал нужен надолго, укажите в WP_DEBUG_LOG путь к файлу вне публичной папки (так можно с версии 5.1). Все параметры описаны в официальном руководстве по отладке WordPress.

Шаг 3. Отключите плагин без админки

Откройте wp-content/plugins/ и переименуйте папку плагина из журнала, например wp-rocket в wp-rocket-off. WordPress не найдёт плагин и деактивирует его. Сайт, скорее всего, откроется.

Если у хостинга есть доступ по SSH и WP-CLI (консольная утилита для управления WordPress), подойдёт команда wp plugin deactivate wp-rocket --skip-plugins. Ключ --skip-plugins не даёт сломанному плагину загрузиться и уронить саму команду.

Если журнал ничего не показал, переименуйте всю папку plugins в plugins_old: отключатся все плагины сразу. Потом верните имя и включайте плагины в админке по одному, пока ошибка не вернётся. На работающем магазине так делать не стоит: вместе с плагинами отключатся оплата, доставка и формы. Этот способ для поиска причины на копии сайта.

«Обязательные» плагины из папки wp-content/mu-plugins так не отключаются. Они загружаются всегда, кнопки выключения у них нет, в обычном списке плагинов их не видно. Их часто ставит хостинг или прошлый разработчик, и при поиске причины о них забывают.

Если виновата тема, переименуйте её папку в wp-content/themes/. WordPress переключится на стандартную тему, если она установлена. Оформление изменится, зато админка заработает.

Шаг 4. Если накануне меняли версию PHP

Верните прежнюю версию PHP в панели хостинга, если хостинг её ещё предлагает. Сайт поднимется, а несовместимый плагин или тему вы спокойно обновите или замените на тестовой копии. Задерживаться на старой версии PHP надолго не стоит: сроки поддержки разобраны в статье PHP 8.1 и 8.2 без поддержки.

Шаг 5. Откатите версию или восстановите бэкап

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

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

Чего не делать

• Не удаляйте плагин кнопкой «Удалить». Некоторые плагины при удалении стирают свои настройки и таблицы. Для отключения достаточно переименовать папку.
• Не переустанавливайте WordPress поверх сайта вслепую. При ручной замене ядра сохраняют wp-config.php и папку wp-content, иначе вместе с ошибкой исчезнут загруженные файлы и темы.
• Не поднимайте лимит памяти до максимума «на всякий случай» и не оставляйте журнал ошибок включённым.
• Не правьте код плагина на рабочем сайте. Исправление исчезнет при следующем обновлении.

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

Какой откат уже встроен в WordPress

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

• С версии 6.3 при ручном обновлении плагина или темы старая версия временно переносится в wp-content/upgrade-temp-backup/. Если установка сорвалась (не скачался архив, не скопировались файлы), WordPress вернёт старую версию. Если новая версия установилась и уже потом уронила сайт, механизм не сработает.
• С версии 6.6 после автообновления активного плагина WordPress сам запрашивает главную страницу и проверяет её на фатальную ошибку. При ошибке возвращается прошлая версия, администратор получает письмо. Проверяется только главная: ошибку в корзине, личном кабинете или админке проверка не заметит. Темы не проверяются вовсе.
• Минорные обновления ядра, то есть исправления и патчи безопасности вроде 7.1.3 → 7.1.4, WordPress ставит сам (на ноябрь 2026 актуальная версия 7.1.4, вышла 28 октября). С мажорными иначе. Сайт, установленный на WordPress 5.6 или новее, по умолчанию сам переходит и на новую мажорную версию, например с 7.0 на 7.1. Проверьте это в «Консоль → Обновления». Если там написано «Этот сайт автоматически обновляется при выходе каждой новой версии WordPress», нажмите ссылку «Переключить на автоматическую установку только выпусков технического обновления и безопасности». Хостинг или плагин могут менять эту настройку.

Как обновлять WordPress без простоя

Ниже регламент, который мы считаем минимально достаточным для сайта, приносящего деньги. Для визитки на пять страниц часть шагов можно упростить, для магазина нельзя.

1. Проверенный бэкап

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

2. Тестовая копия (staging)

Staging — копия сайта на отдельном адресе, закрытая от поисковиков и посетителей. У части хостингов она создаётся из панели. Все обновления сначала ставят на неё. FAQ команды тестирования WordPress к выходу версии 7.0 прямо советует не обновлять рабочий сайт сразу, без предварительной проверки, и спокойно подождать, пока вы не протестируете сайт.

Копию делают свежей, прямо перед обновлением. Staging трёхмесячной давности с другим набором плагинов ничего не проверяет.

3. Порядок обновления

На тестовой копии:

1. Прочитайте список изменений и требования крупных плагинов (WooCommerce, конструктор страниц, кеширование, платёжные модули): есть ли упоминания несовместимости, какая версия WordPress нужна.
2. Решите, что обновлять первым. Если новая версия плагина требует более свежее ядро, начинайте с ядра: так, WooCommerce 10.8 требует WordPress 6.9 или новее и прямо советует сначала обновить WordPress. Если таких требований нет, мы советуем сначала обновить плагины и тему до версий, которые работают на текущем ядре, а мажорную версию ядра ставить отдельным шагом. Тогда при сбое сразу видно, что его вызвало.
3. Обновляйте плагины по одному, начиная с тех, от которых зависят другие: сначала WooCommerce, потом его расширения. После каждого открывайте сайт.
4. Обновите тему. Если тема дочерняя, обновляется родительская.
5. Пройдите проверочные сценарии (ниже).

Затем повторите ту же последовательность на рабочем сайте в часы с минимумом заказов и снова пройдите проверку.

Мажорные версии ядра на рабочий сайт в день выхода мы ставить не советуем. Дождитесь исправлений у основных плагинов и проверьте сайт на копии. Случай WP Rocket и WordPress 7.1 показывает, зачем: сайты, которые отложили обновление ядра хотя бы на пару дней, к этому времени уже могли поставить исправленную версию плагина. Откладывать на полгода тоже плохо: новые версии плагинов перестают поддерживать старое ядро, как в примере с WooCommerce. Следующая мажорная версия, WordPress 7.2, запланирована на 8 декабря 2026 года.

С обновлениями безопасности плагинов логика обратная: их ставят быстро. По отчёту Patchstack за 2025 год, у массово атакуемых уязвимостей взвешенная медиана времени до первой атаки составила 5 часов. Если в списке изменений плагина написано «security fix», обновление ставят в тот же день, проверив хотя бы главные сценарии.

4. Проверочные сценарии

«Главная открылась» ещё не значит, что сайт работает. Запишите сценарии один раз и проходите их после каждого обновления:

• главная, каталог, карточка товара (для вариативных товаров выберите несколько вариантов);
• поиск и фильтры;
• корзина, оформление заказа, тестовая оплата или хотя бы переход на страницу платёжной системы;
• письмо о заказе пришло покупателю и менеджеру, заказ появился в админке и, если есть интеграция, в учётной системе или CRM;
• формы заявок: заявка дошла до почты или CRM, а не только показала «Спасибо»;
• вход в личный кабинет и в админку;
• мобильная версия;
• всё то же после сброса кеша плагина, сервера и CDN.

5. Мониторинг после обновления

Часть ошибок проявляется не сразу: на редко посещаемой странице, в фоновой задаче, при оплате определённым способом. Мониторинг доступности сообщит, если сайт перестал отвечать. Журнал ошибок PHP в панели хостинга (не debug.log, его мы выключили) в первые дни после обновления открывайте специально. Бэкап, снятый перед обновлением, не удаляйте, пока не убедитесь, что всё работает.

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

С версии 5.5 WordPress позволяет включить автообновление для каждого плагина и каждой темы отдельно: колонка «Автообновления» на странице «Плагины» и ссылка в карточке темы. По умолчанию они выключены. О прошедшем или сорвавшемся автообновлении WordPress пишет администратору на почту; эти письма нужно читать, а не отправлять в фильтр. Подробнее в документации wordpress.org об автообновлениях.

Наша позиция:

• Минорные обновления ядра оставьте включёнными. Это исправления и патчи безопасности; разработчики ядра пишут, что отключать их настоятельно не рекомендуется.
• Мажорные обновления ядра на сайте, который продаёт, ставьте вручную по регламенту, а автоматический переход на новые версии выключите (как это сделать, написано в разделе о встроенном откате).
• Плагины, через которые идут деньги (WooCommerce и его расширения, оплата, доставка, конструктор страниц, кеширование), обновляйте вручную через тестовую копию. Случай YOP Poll показывает, что одно обновление плагина может закрыть доступ к админке. Автообновление проходит без вас, часто ночью, а встроенная проверка смотрит только главную. Ошибку в оформлении заказа первыми увидят покупатели.
• Простые плагины без влияния на заказы и вёрстку (например, редирект или карта сайта) можно оставить на автообновлении.

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

Когда справитесь сами, а когда нужен специалист

Владелец сайта или маркетолог справится сам, если:

• пришло письмо, ссылка работает и в письме назван конкретный плагин;
• есть доступ к файлам и понятно, какую папку переименовать;
• есть свежий бэкап, и хостинг восстанавливает его по кнопке.

Зовите специалиста, если:

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

Как с этим помогает RIVERIT

Предлагаем взять сайт на техподдержку WordPress. Обновления ядра, тем и плагинов обычно проводим раз в месяц, бэкапы входят в поддержку, сайт и домен находятся под мониторингом. Клиентам на поддержке отвечаем в течение часа, остальным в течение рабочего дня; если сайт упал ночью или в выходной, чиним и вне рабочего времени, когда это входит в тариф. Для сайтов на Laravel или Django есть общий раздел поддержки и сопровождения сайтов. Стоимость рассчитываем под объём и сложность сайта.