Обновления в WordPress закрывают дыры безопасности и держат плагины совместимыми — но именно «нажал обновить, не глядя» чаще всего и роняет сайт. В практике сопровождения сценарий повторяется: владелец видит плашку «доступны обновления», жмёт «обновить всё», и через минуту вместо сайта белый экран или форма заявки молчит. Разберём порядок, при котором обновление почти никогда не ломает прод.
Почему безопасное обновление — это не «кнопка», а процесс
Само ядро WordPress обновляется аккуратно и редко ломает сайт в одиночку. Проблема почти всегда в связке: устаревший PHP на хостинге, тяжёлый плагин-конструктор, который автор давно не трогал, или тема без обновлений. Когда всё это обновляется одной кнопкой и без бэкапа, при сбое непонятно, что именно сломалось — и откатывать приходится вслепую.
Поэтому безопасное обновление держится на трёх вещах: свежий бэкап, тестовая копия и правильный порядок. Ниже — каждый шаг.
Шаг 1. Бэкап, который реально разворачивается
«Хостинг делает бэкапы» — не считается, пока вы хотя бы раз не развернули копию и не убедились, что она рабочая. Перед любым обновлением нужен свежий бэкап файлов и базы данных, лежащий не на том же сервере, что и сайт.
Способы и куда складывать копии в России (Яндекс.Диск, S3-совместимые хранилища) мы разбирали в отдельной статье — «Бэкапы WordPress: 4 рабочих способа и какой выбрать». Минимум перед обновлением: один полный бэкап «как сейчас».
Шаг 2. Тестовая копия (staging) вместо экспериментов на проде
Тестовая копия — это клон сайта на поддомене (test.ваш-домен.ru) или отдельной папке. Многие хостинги (Beget, Timeweb) умеют создавать staging в один клик. Все обновления сначала ставятся на копию: если что-то ломается — боевой сайт цел, а вы уже знаете, какой именно плагин виноват.
Для визитки на 3–5 плагинов staging иногда избыточен — достаточно бэкапа и спокойного времени. Для магазина, сайта с заявками или интеграцией с CRM тестовая копия обязательна.
Шаг 3. Порядок обновления: PHP → плагины → тема → ядро
Порядок важнее, чем кажется. Он позволяет ловить причину сбоя по одному, а не разбирать кашу из десяти одновременных изменений.
- PHP. Если на хостинге PHP 7.x — поднять до 8.1–8.2 на копии и проверить. Современные плагины и свежее ядро рассчитаны на 8.x; старый PHP — частая причина «обновил и упало».
- Плагины. Обновлять по одному или небольшими группами, после каждой — открыть сайт и админку. Особенно осторожно с конструкторами (Elementor, WPBakery), WooCommerce, ACF и кэш-плагинами.
- Тема. Сначала родительская, потом дочерняя. Если правки внесены прямо в тему без дочерней — обновление их затрёт; это повод сделать дочернюю тему заранее.
- Ядро WordPress. В последнюю очередь, когда плагины и тема уже на свежих версиях и сайт работает.
Перед пакетным обновлением полезно убрать мусор: неактивные и дублирующие плагины. Как это сделать — в статье «Сколько плагинов нужно WordPress». Меньше плагинов — меньше точек отказа при обновлении.
Шаг 4. Что проверить сразу после обновления
Обновление прошло без ошибок в админке — это ещё не «всё хорошо». Нужно прогнать сценарии, которые приносят деньги и заявки:
- главная и 5–10 типовых страниц на телефоне и десктопе;
- форма заявки — отправить тестовую и убедиться, что письмо дошло;
- для магазина — тестовый заказ от корзины до оплаты;
- личный кабинет, фильтр каталога, виджеты, которые писали под сайт;
- скорость витрины — не просел ли PageSpeed.
Если после обновления перестали уходить письма — это частый и отдельный сюжет, разобран в статье про письма WooCommerce. Если внутренние страницы отдают 404 — зайдите в Настройки → Постоянные ссылки и нажмите «Сохранить» без изменений: это пересобирает правила ЧПУ.
Шаг 5. Автообновления — что доверить, а что держать под контролем
WordPress умеет обновляться сам. Разумная схема для бизнес-сайта:
- Минорные версии ядра (7.0.1, 7.0.2) и безопасность — можно оставить автоматическими, они почти всегда безопасны.
- Мажорные версии ядра (например, переход на новый релиз) — вручную, через staging. Про обновление на крупную версию у нас есть отдельный чек-лист — «WordPress 7.0: как обновить без поломок».
- Тяжёлые плагины и конструкторы — вручную, чтобы автообновление не легло в три часа ночи без вашего ведома.
Главный риск автообновлений — они срабатывают в неудобный момент и без бэкапа под рукой. Поэтому бэкап по расписанию (шаг 1) должен работать всегда, а не «когда вспомнили».
Откат, если после обновления сайт лёг
Алгоритм по убыванию удобства:
- Есть бэкап — развернуть копию «до обновления». Самый надёжный путь.
- Админка открывается — плагин WP Rollback откатывает плагин или тему на предыдущую версию в пару кликов.
- Админка не открывается — по FTP переименовать папку последнего обновлённого плагина в
wp-content/plugins/, проверить сайт; если не помогло — то же с темой. Подробный разбор проблем — в статьях про белый экран и ошибку 500.
Откат ядра без отката базы обычно безопасен — если вы не запускали «обновить базу данных» под несовместимую схему. Для типовых сайтов это редкость.
Чего не делать при обновлении
- Не жать «обновить всё» одной кнопкой без бэкапа — при сбое не найти причину.
- Не обновлять в пик (понедельник утром, старт рекламы, распродажа). Лучшее окно — утро буднего дня, не пятница.
- Не поднимать PHP сразу до максимума (с 7.4 до 8.4) на боевом сайте — шаг 8.1–8.2, проверка, потом выше.
- Не игнорировать обновления полгода — копятся уязвимости. Золотая середина: подготовка, staging, обновление в течение 2–4 недель после релиза.
- Не править ядро и плагины напрямую — следующее обновление затрёт правки. Для кастомизации — дочерняя тема и отдельный плагин.
Когда обновление лучше доверить специалисту
- Интернет-магазин с оплатой, доставкой и интеграцией с 1С или CRM.
- Сайт уже нестабилен: периодически белый экран, ошибка 500 или следы взлома.
- Нет доступа к бэкапу и FTP — только кнопка в админке.
- Мажорное обновление ядра на коммерческом сайте, от которого зависят заявки.
В этих случаях разумнее заказать обновление под ключ: копия, тест, выкат в спокойное окно, проверка форм и заказа, откат при сбое. Оценка по задаче — бесплатно, через раздел «Ошибки и сбои WordPress» или Контакты.
Коротко: безопасное обновление за 6 пунктов
- Свежий бэкап файлов и базы, проверенный на разворачивание.
- Тестовая копия для магазинов и сайтов с заявками.
- Порядок: PHP → плагины (по одному) → тема → ядро.
- После обновления — тестовая заявка, тестовый заказ, скорость, ЧПУ.
- Автообновления — для минорных версий и безопасности; мажорные — вручную.
- Под рукой — план отката (бэкап, WP Rollback, FTP).
Обновляться нужно — ради безопасности и совместимости. Главное делать это не «на кнопку», а по процессу. Если предстоит крупное обновление на бизнес-сайте — напишите в Контактах, подскажем по срокам и что проверить на вашей связке тема + плагины.
