Обновление CMS без падения сайта - регулярная процедура, которую владелец бизнеса откладывает до момента, когда сайт уже взломали или хостинг отключил старую версию PHP. Время чтения - 11 минут.
Инструкция собрана по опыту 550+ проектов веб-студии Сайты2.рф с 2008 года. Внутри универсальный алгоритм из 8 шагов, специфика 1С-Битрикс и WordPress, сценарий отката за 5 минут, расписание апдейтов и 6 типовых ошибок. Подойдёт владельцам сайтов из СПб, Кронштадта, Гатчины и других городов Ленинградской области.
Зачем вообще обновлять CMS
Безопасность - первая и главная причина. В старых версиях Битрикс и WordPress находят уязвимости, через которые на сайт заливают шеллы, спам-страницы и фишинг. По внутренней статистике, 7 из 10 взломов в 2024-2025 годах пришлись на сайты с CMS старше 18 месяцев.
Вторая причина - совместимость с PHP. Хостеры регулярно отключают PHP 7.4 и 8.0, оставляя только 8.2 и 8.3. Если ядро не поддерживает свежий PHP, сайт падает с белым экраном в день, когда провайдер обновит сервер. Об этом редко предупреждают заранее.
Третья причина - функции и производительность. Свежий WordPress быстрее работает с REST API. Свежий Битрикс лучше дружит с композитным кешем и Webpack-сборкой. Без апдейтов вы платите за поддержку устаревшего движка и теряете на скорости.
Что ломается при апдейте вслепую
Несовместимые плагины и модули. Половина WordPress-сайтов держится на 15-30 плагинах, и хотя бы один из них перестаёт работать после мажорного апдейта. На Битриксе ту же роль играют кастомные модули из решений с Marketplace.
Сломанный шаблон. Если верстальщик правил файлы темы напрямую, а не через дочернюю тему, обновление CMS затрёт правки. Сайт вернётся к стоковому виду без хедера и меню. Восстанавливать придётся из бэкапа или вручную.
Потеря данных. Битриксовые миграции БД иногда обрываются на середине из-за нехватки памяти PHP. Таблицы остаются в полуразобранном виде, админка перестаёт открываться. На WordPress похожий эффект даёт неудачное обновление WooCommerce, когда теряются заказы за последние сутки.
Универсальный алгоритм обновления CMS без падения
Алгоритм одинаков для Битрикса, WordPress, Laravel и любой другой CMS. Меняются только команды на каждом шаге. Полный цикл занимает 2-4 часа для среднего корпоративного сайта.
Шаг 1. Бэкап файлов и базы данных
Сначала снимите архив файлов через панель хостинга или tar -czf backup-files.tar.gz public_html/. Отдельно сделайте дамп БД через phpMyAdmin или mysqldump. Сохраните оба файла на свой компьютер и в облако, не на тот же сервер.
Проверьте, что бэкап читается. Распакуйте архив на локальной машине, импортируйте дамп в локальный MySQL. Бэкап, который не получается восстановить, не считается бэкапом.
Шаг 2. Развёртывание копии на staging
Staging - отдельный домен или поддомен, на который копируется текущий прод. Удобно держать staging.домен.ру с базовой авторизацией. Перенесите файлы и БД, поменяйте URL в настройках, проверьте, что открывается главная.
Подробнее про устройство тестовых окружений мы писали в материале Как ускорить сайт. Те же подходы работают и для staging.
Шаг 3. Обновление ядра CMS на staging
На staging запускаете апдейт ядра по штатному сценарию: SiteUpdate в Битриксе, WP-CLI или админка в WordPress. Не трогайте плагины и модули на этом шаге, только ядро. Если ядро не встаёт, на прод вы не пойдёте.
Шаг 4. Обновление плагинов и модулей по очереди
Главное правило - не обновлять всё сразу. Берёте один плагин или модуль, апдейтите, открываете 5-7 страниц, проверяете админку. Если упало, откатываете именно этот плагин и фиксируете проблему. Так вы точно знаете, кто виноват.
Шаг 5. Прогон тестов
Минимальный набор сценариев: открытие 10 случайных страниц, отправка формы обратной связи, поиск по сайту, авторизация в личном кабинете, оплата тестовой картой через эквайринг. Для интернет-магазина добавьте оформление заказа от и до.
Дополнительно прогоните консоль Chrome DevTools на главной и в карточке товара. Если в консоли красные ошибки JS, скрипты конфликтуют после апдейта, и пользователь увидит сломанный фронт.
Шаг 6. Проверка регресса
Регресс - сравнение страниц до и после обновления. Удобно ловить через сервисы Percy или BackstopJS, но для среднего сайта хватит скриншотов 8-12 главных страниц в DevTools на десктопе и мобильной ширине 375 пикселей.
Сравните попарно, ищите смещения блоков, изменившиеся шрифты, исчезнувшие иконки. Занимает 20-30 минут, но экономит часы правок после переноса на прод.
Шаг 7. Перенос изменений на прод
Если staging прошёл проверку, переносите изменения. Файлы обычно синхронизируете через rsync -avz staging-host:/path/ prod-host:/path/. БД - дампом из staging, который накатываете на прод поверх свежего бэкапа.
Альтернатива - повторить апдейт на проде по тому же сценарию. Безопаснее, если на проде накопились правки контента, которых нет на staging.
Шаг 8. Финальная проверка на проде
5-10 минут после переноса - окно повышенного внимания. Откройте главную, каталог, корзину, форму. Зайдите в админку. Посмотрите на счётчики метрики, не упал ли трафик до нуля. Прогоните Page Speed Insights, чтобы убедиться, что скорость не просела.
Что делать, если на проде сразу нашли баг, который не воспроизводится на staging - смотрите ниже в разделе про откат.
Специфика 1С-Битрикс
В Битриксе обновления катятся через SiteUpdate из административной панели или скрипт /bitrix/updater.php. Перед запуском очистите кеш в разделе "Настройки - Производительность - Очистка файлов кеша", иначе апдейт зависает на проверке хешей.
Удобный инструмент для staging - Bitrix Site Manager в режиме "Копировать сайт". Создаёт полную копию сайта на тот же или другой сервер в полуавтоматическом режиме. Дальше работаете с копией как с обычным staging.
Обновление редакции (Старт - Малый бизнес - Бизнес) делается через техподдержку 1С-Битрикс и платно. После апгрейда редакции запустите проверку системы и прогоните импорт-экспорт для каталога, потому что у старшей редакции другая структура свойств товаров.
После любого крупного апдейта Битрикса сбросьте все три уровня кеша: системный, компонентов и HTML-кеш. Параллельно проверьте composite-режим: часто отключается после обновления и роняет скорость в 2-3 раза.
Если у вас интернет-магазин на Битриксе, перед апдейтом ядра прочитайте материал про интернет-магазины и согласуйте окно с бухгалтерией: апгрейд во время сверки с 1С даёт двойные заказы.
Специфика WordPress
WordPress различает minor и major обновления. Minor - апдейт вида 6.5.2 → 6.5.3, обычно безопасный, можно ставить автоматически. Major - 6.5 → 6.6, требует проверки совместимости со всеми плагинами.
WP-CLI ускоряет апдейт в 5-7 раз. Базовые команды: wp core update, wp plugin update --all, wp theme update --all. Все они работают из SSH и не требуют входа в админку, что критично, если админка уже сломана.
Несовместимые темы и плагины ищите через wp plugin list --status=active перед апдейтом. Дальше зайдите на сайты разработчиков и проверьте changelog: указана ли поддержка новой версии WP. Если разработчик не обновлял плагин 2 года, смело отключайте и ищите замену.
Отдельная проблема - WooCommerce и его 30+ дополнений. Правило простое: сначала ставите свежую версию ядра WooCommerce на staging, потом по одному обновляете все расширения. Платёжные шлюзы трогайте в последнюю очередь и прогоните тестовую оплату.
Откат за 5 минут, если всё упало
Если после переноса на прод сайт лёг, не пытайтесь чинить вручную. Откатывайте бэкап. Время выполнения - 3-5 минут, если бэкап лежит на том же сервере.
Сценарий отката:
- Включите режим обслуживания: для WordPress положите файл
.maintenance, для Битрикса включите страницу заглушки через/bitrix/php_interface/init.php. - Замените папку сайта на свежераспакованный бэкап файлов.
- Сбросьте БД и накатите дамп:
mysql -u user -p база < backup.sql. - Выключите режим обслуживания.
- Проверьте главную, каталог, форму.
Если бэкапа на сервере нет, а есть только на компьютере, добавьте 10-20 минут на закачку через SFTP. Поэтому правило: всегда держать свежий бэкап рядом с прод-сервером в момент апдейта.
Про восстановление при катастрофическом сценарии - в материале Перенос сайта на другой хостинг. Те же приёмы работают и для отката после неудачного апдейта.
Расписание апдейтов
Раз в неделю: обновление плагинов с пометкой "критическое обновление безопасности". Это minor-патчи, которые закрывают уязвимости. Ставите без staging, через WP-CLI или Битрикс-апдейтер.
Раз в месяц: minor-обновления ядра CMS и всех плагинов. Делаете через полный цикл с staging. Время - 2-3 часа для среднего корпоративного сайта.
Раз в полгода: major-обновления ядра. Полный цикл с staging, регрессом, проверкой совместимости тем и плагинов. Время - 1-2 рабочих дня, обязательно ставите в окно низкого трафика (вторник, утро).
Раз в год: аудит всех плагинов и модулей с удалением неиспользуемых. Каждый лишний плагин - +1 риск падения при следующем апдейте. На корпоративном сайте здоровое число активных плагинов 8-15, не больше.
Соблюдение расписания снижает риск падения сайта в 5-7 раз. Подтверждено выборкой из 200 наших сайтов на поддержке за 2024 год.
Стоимость поддержки с обновлениями
В Сайты2.рф пакеты поддержки с включёнными апдейтами стартуют от 12 000 ₽ в месяц для среднего корпоративного сайта на 30-50 страниц. В пакет входит:
- мониторинг доступности 24/7 с уведомлением через 3 минуты после падения;
- ежедневный бэкап файлов и БД с хранением 30 дней;
- minor-обновления плагинов и модулей по мере выхода;
- major-апдейт ядра раз в полгода;
- откат и восстановление в течение 1 часа при инциденте;
- консультации по телефону и в Telegram в рабочие часы.
Про тарифы и состав пакетов - на странице поддержка и доработка или в калькуляторе. Также можем посчитать индивидуально под ваш стек: контакты или цены.
Для интернет-магазинов и B2B-порталов поддержка дороже из-за интеграций с 1С, эквайрингом и CRM. Диапазон - 25 000-50 000 ₽ в месяц. Чаще такие сайты делаются на базе корпоративных решений с кастомной логикой.
6 ошибок при обновлении
Ошибка 1. Апдейт сразу на проде без staging. Самая дорогая ошибка. Восстановление после падения занимает 4-8 часов, всё это время сайт не приносит заявок.
Ошибка 2. Бэкап только файлов или только БД. Без одной из частей восстановление невозможно. Дамп БД без файлов открывается с белым экраном, файлы без БД - со страницей "ошибка подключения".
Ошибка 3. Не проверять читаемость бэкапа. Архивы иногда повреждаются на лету. Открывайте их сразу после создания, иначе в момент падения окажется, что архив битый.
Ошибка 4. Обновлять всё разом. Если упало, не понять, что виновато. По одному плагину, по одному модулю - и записывайте в лог, что и когда поставили.
Ошибка 5. Хардкод правок в темах и ядре. Любая правка в /bitrix/modules/main/ или в /wp-includes/ затрётся обновлением. Используйте дочерние темы и bitrix/php_interface/init.php.
Ошибка 6. Игнорировать changelog. В changelog пишут breaking changes: например, удалили API-функцию, на которой держался плагин. Прочитайте за 5 минут до апдейта и сэкономите часы.
После апдейта свертесь с чек-листом 152-ФЗ и чек-листом приёмки сайта у студии: они помогают поймать регресс по юридике и формам. Если планируете крупный апдейт на фоне редизайна, добавьте материал Редизайн без потери SEO или сразу обратитесь к услуге редизайна.
FAQ
Как часто нужно обновлять CMS?
Минор-плагины раз в неделю, ядро CMS раз в месяц, мажорный апдейт раз в полгода. Игнорировать апдейты больше 12 месяцев - автоматически входить в группу риска по взлому.
Можно ли обновлять Битрикс без техподдержки 1С-Битрикс?
Можно, если лицензия активна. Без активной техподдержки SiteUpdate не скачает архивы. Продление - от 30% стоимости редакции в год. Для коммерческого сайта экономить не рекомендуем.
Сколько стоит разовое обновление сайта?
Разовый апдейт корпоративного сайта по нашему алгоритму из 8 шагов - от 8 000 ₽ для WordPress и от 15 000 ₽ для Битрикса. Точная цифра зависит от количества плагинов и кастомного кода.
Что делать, если плагин больше не поддерживается?
Ищите аналог с активным разработчиком. Проверяйте дату последнего апдейта на wordpress.org или в Битрикс Marketplace. Если плагин не обновлялся 18 месяцев, заменяйте, не дожидаясь падения.
Можно ли откладывать апдейт PHP, если хостинг разрешает?
Технически да, но через 6-12 месяцев хостер всё равно отключит старую версию. Лучше обновить заранее в спокойном режиме, чем экстренно в день отключения.
Работает ли студия из Кронштадта с заказчиками в Ленинградской области?
Да, обслуживаем сайты компаний из Гатчины, Выборга, Соснового Бора, Всеволожска, Тосно и других городов ЛО. Работа удалённая через SSH и Git, выезд в офис клиента не требуется.
