После обновления WordPress сломался сайт: что делать и как восстановить

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

Ниже — безопасный порядок действий, который помогает сначала вернуть контроль над сайтом, затем найти причину и только после этого повторно обновляться. Материал рассчитан прежде всего на обычные WordPress-сайты и WooCommerce. Если сайт приносит заявки или продажи, не экспериментируйте на продакшене без резервной копии.

Какие поломки чаще всего появляются после обновления

Шаг 1. Не делайте полный откат вслепую

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

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

Шаг 2. Проверьте Recovery Mode WordPress

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

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

Официальный источник: WordPress Recovery Mode.

Шаг 3. Если Recovery Mode не помог — смотрите логи

Скриншот «critical error» почти ничего не говорит о причине. Нужна конкретная PHP-ошибка: имя файла, строка, тип исключения или несовместимая функция. На хорошем хостинге это видно в error log. В WordPress для диагностики есть WP_DEBUG и WP_DEBUG_LOG.

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

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

После диагностики режим отладки нужно вернуть в нормальное состояние. Официальный источник: Debugging in WordPress.

Шаг 4. Как временно отключить проблемный плагин без админки

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

Не переименовывайте всю папку plugins, если уже знаете виновника. Чем меньше изменений вы делаете одновременно, тем легче проверить гипотезу. После возврата сайта переименуйте каталог обратно только тогда, когда понимаете дальнейший план: установить исправленную версию, откатить одну версию назад или заменить компонент.

Шаг 5. Если виновата тема

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

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

Шаг 6. Когда нужен откат версии

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

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

Что проверить после того, как главная снова открывается

Аварийное восстановление заканчивается не в тот момент, когда загрузилась главная. На сайте могут остаться скрытые ошибки в JavaScript, REST API, cron, оплате или внешней интеграции.

• открыть несколько типовых страниц на компьютере и телефоне;
• отправить тестовую форму и убедиться, что письмо/CRM/Telegram получили обращение;
• проверить вход в админку и сохранение записи;
• если есть WooCommerce — пройти путь товар → корзина → checkout → тестовый заказ;
• проверить расчёт доставки и подключённые способы оплаты;
• проверить планировщик задач и фоновые синхронизации;
• посмотреть консоль браузера и свежие серверные логи.

Если после обновления пострадал действующий коммерческий сайт, можно обратиться за доработкой и восстановлением WordPress. Для оценки полезно сразу прислать URL, что именно обновлялось, точный текст ошибки и время возникновения проблемы. Общий порядок работы описан на странице WordPress-разработчика.

Когда проблема не в самом обновлении

Иногда обновление просто совпадает по времени с другой аварией. Например, закончилась память PHP, истёк SSL у внешнего API, хостинг переключил версию PHP, база достигла лимита, CDN отдаёт старый JavaScript или защита блокирует REST-запрос. Поэтому хороший диагноз всегда начинается с фактов из логов, а не с предположения «сломал WordPress».

Как обновляться после восстановления

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

1. Сделать актуальную резервную копию.
2. Проверить доступное место, PHP и системные требования.
3. Если сайт важен для бизнеса — сначала обновить staging-копию.
4. Обновлять компоненты небольшими группами, а критичные — по одному.
5. После каждого этапа проверять ключевые сценарии.
6. Только после успешного теста повторить изменения на продакшене.

Отдельный материал о безопасном обновлении: WordPress 7.1: что нового и как обновиться.

FAQ

Можно ли восстановить сайт без доступа в админку?

Да. Обычно используют файловый менеджер/SFTP/SSH, серверные логи и временное отключение проблемного компонента. Наличие бэкапа значительно снижает риск.

Нужно ли сразу восстанавливать весь сайт из резервной копии?

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

Почему сайт сломался после обычного обновления плагина?

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

Можно ли просто отключить WP_DEBUG после восстановления?

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

Сколько стоит исправление такой ошибки?

Стоимость зависит от воспроизводимости и причины. Локальный конфликт одного плагина и сложная ошибка с WooCommerce, API или повреждением базы — разные по объёму задачи. Ориентиры есть в материале о стоимости доработки WordPress в 2026 году.

Когда стоит передать восстановление разработчику

Если сайт принимает оплаты, хранит заказы, связан с CRM или внешними API, а ошибка затрагивает базу или сервер, стоимость неправильного эксперимента может быть выше стоимости диагностики. В такой ситуации полезнее сохранить текущее состояние и передать специалисту логи и историю обновления. Для связи: A.S Groups.

Официальные источники

• WordPress.org — Recovery Mode
• Developer.WordPress.org — Debugging in WordPress
• Theme Handbook — Debugging