Вокруг обновлений сайтов существуют две противоположные крайности. Одни владельцы не обновляют ничего годами по принципу «работает — не трогай». Другие нажимают «Обновить всё» в административной панели, как только видят уведомление. Первый путь рано или поздно приводит к взлому, второй — к внезапному падению сайта посреди рабочего дня. Правильный подход лежит посередине: обновлять регулярно, но через понятный процесс с проверкой и возможностью отката.
Что именно обновляется на сайте
Сайт — это не одна программа, а набор слоёв, каждый из которых живёт своей жизнью и получает свои обновления. Важно понимать эту структуру, потому что проблемы часто возникают на стыке слоёв.
Ядро CMS
Основа системы: WordPress, 1С-Битрикс, OpenCart или фреймворк вроде Laravel. Обновления закрывают уязвимости и меняют внутренние механизмы.
Модули и плагины
Дополнительная функциональность от сторонних разработчиков. Самая многочисленная и самая рискованная часть.
Тема и шаблоны
Внешний вид сайта. Если тема доработана напрямую, её обновление может стереть все изменения.
Серверное ПО
Операционная система, PHP, Node.js, веб-сервер, СУБД. Обновляются отдельно от сайта, но напрямую влияют на него.
Кроме того, во фронтенд-проектах на Vue, React или Next есть зависимости из пакетных менеджеров — десятки и сотни библиотек, которые тоже обновляются и тоже содержат уязвимости. Для таких проектов обновления — отдельная регулярная задача разработчика, а не кнопка в панели.
Зачем обновляться, если всё работает
Главная причина — безопасность. Когда в популярной CMS или модуле находят уязвимость, разработчики выпускают исправление и публикуют описание проблемы. С этого момента информация доступна всем, включая авторов автоматических сканеров. Окно между публикацией и началом массовых атак составляет от нескольких часов до нескольких дней. Сайт, который не обновлён, становится лёгкой целью. Подробнее о том, как обычно взламывают сайты, — в статье «Защита сайта от взлома: базовые меры».
Вторая причина — совместимость. Хостинг-провайдеры постепенно отключают старые версии PHP, платёжные сервисы и службы доставки меняют API, браузеры перестают поддерживать устаревшие технологии. Сайт, который годами не обновлялся, однажды перестаёт работать не из-за атаки, а потому что окружение ушло вперёд.
Третья причина — накопленный технический долг. Обновить CMS с версии, вышедшей месяц назад, — задача на час. Обновить с версии пятилетней давности — проект на несколько недель: за это время изменились внутренние механизмы, часть модулей перестала существовать, доработки нужно переписывать. Мы регулярно видим ситуации, когда обновление сильно запущенного сайта стоит сопоставимо с редизайном, и владельцу приходится выбирать между дорогим обновлением и полной переделкой.
Почему обновления ломают сайты
Страх перед обновлениями не беспочвенен. Мы разбирали много случаев, когда после нажатия кнопки «Обновить» сайт показывал белый экран, переставала работать корзина или пропадали настройки модуля. Причины обычно одни и те же.
Правки в чужом коде. Разработчик когда-то поправил что-то прямо в файлах модуля или темы, вместо того чтобы использовать механизмы расширения. Обновление перезаписывает файлы, и правки исчезают. Иногда без них ломается важная функция, иногда просто возвращается старый внешний вид.
Несовместимость модулей. Обновлённый модуль A ожидает новую версию модуля B, а B ещё не обновлён или конфликтует с C. На сайте с 40 плагинами вероятность такого конфликта при массовом обновлении довольно высока.
Изменения в поведении. Крупные обновления меняют не только код, но и логику: настройки по умолчанию, формат данных, внешний вид административной панели. Сайт формально работает, но, например, перестаёт отправлять письма о заказах или меняется расчёт скидок.
Обновление прошло частично. Если процесс прервался из-за нехватки памяти или времени выполнения, сайт может оказаться в промежуточном состоянии, из которого без резервной копии выбраться трудно.
Безопасный процесс обновления
Риски обновлений решаются не отказом от них, а процессом. Вот как мы обновляем сайты клиентов на поддержке.
Резервная копия
Перед любым обновлением делается свежая копия базы данных и файлов. Даже если ночная копия была несколько часов назад, в интернет-магазине за это время появились новые заказы.
Изучение изменений
Разработчик читает список изменений к каждому обновлению. Если это крупная версия с изменениями в поведении, обновление планируется отдельно и согласуется с заказчиком.
Обновление на тестовой копии
Обновления устанавливаются на копию сайта, которая максимально повторяет рабочую: та же версия PHP, те же модули, свежая копия базы.
Проверка ключевых сценариев
Каталог, поиск, карточка товара, корзина, оформление и оплата заказа, формы заявок, личный кабинет, обмен с 1С или CRM, отправка писем. Для крупных проектов часть проверок автоматизирована.
Выкладка в спокойное время
Обновление переносится на рабочий сайт в период минимальной нагрузки, не в пятницу вечером и не перед распродажей. После выкладки — повторная быстрая проверка.
Наблюдение
В течение суток после обновления команда внимательнее следит за логами ошибок и мониторингом. Если что-то пошло не так, есть план отката.
Такой процесс занимает больше времени, чем одна кнопка, но превращает обновление из лотереи в рутину. Для типичного корпоративного сайта плановое обновление по этой схеме — это 1–3 часа работы в месяц.
Как часто обновляться
Универсальной частоты нет, но есть разумные ориентиры, которые мы используем в работе. Они учитывают и риск, и затраты на проверку.
| Тип обновления | Срок установки | Комментарий |
|---|---|---|
| Критическое исправление безопасности | 1–3 дня | Если уязвимость активно эксплуатируется — в тот же день, при необходимости с временной защитой через межсетевой экран |
| Минорные версии CMS и модулей | Раз в 2–4 недели | Пакетом, через тестовую копию |
| Крупные версии CMS | Планово, через 1–2 месяца после выхода | Дать время найти и исправить ошибки в новой версии, проверить совместимость модулей |
| Версия PHP или Node.js | До окончания поддержки текущей версии | Требует проверки всего кода, иногда доработок |
| Операционная система сервера | Обновления безопасности — автоматически или еженедельно | Крупные версии — планово с переездом на новый сервер |
Ожидание после выхода крупной версии — сознательная тактика. Первые выпуски новых версий нередко содержат ошибки, которые исправляют в течение нескольких недель. Кроме того, разработчикам сторонних модулей нужно время на адаптацию. Исключение — если в новой версии закрыта серьёзная уязвимость, которую нельзя закрыть иначе.
Пример из практики
Магазин товаров для рукоделия на WooCommerce пришёл к нам с сайтом, который не обновлялся около трёх лет. Версия PHP на хостинге вот-вот должна была быть отключена, а из 34 установленных плагинов семь больше не поддерживались разработчиками. Обновить всё за один раз было невозможно: ядро, магазинный модуль и половина плагинов несовместимы между версиями. Мы разбили работу на четыре этапа, на каждом поднимали версии до промежуточных и проверяли каталог, корзину и обмен с МойСклад. Заброшенные плагины заменили на поддерживаемые аналоги, два переписали в виде небольших собственных модулей. Вся работа заняла около трёх недель, а после неё регулярные обновления стали занимать 1–2 часа в месяц.
Как уменьшить боль от будущих обновлений
Многие проблемы с обновлениями закладываются ещё на этапе разработки. Если вы заказываете новый сайт или доработки, стоит сразу договориться о нескольких принципах.
Никаких правок в чужом коде. Доработки модулей и тем делаются через дочерние темы, хуки, события, собственные модули — механизмы, которые CMS специально предусматривает для расширения. Тогда обновление сторонних компонентов не затрагивает ваш код.
Минимум модулей. Каждый плагин — это зависимость, которую нужно обновлять и проверять. Если функцию можно реализовать двадцатью строками собственного кода вместо подключения тяжёлого модуля, иногда это лучше в долгосрочной перспективе.
Проверенные источники. Модули из официальных каталогов от разработчиков с историей регулярных обновлений. Никаких «бесплатных версий платных плагинов» — они почти всегда содержат вредоносный код и не обновляются.
Код в системе контроля версий. Тогда любое обновление можно откатить одной командой, а изменения видно построчно.
Тестовая копия с первого дня. Копия сайта для проверки изменений должна существовать постоянно, а не создаваться в спешке перед первым серьёзным обновлением.
Вопросы, которые нам задают
Можно ли включить автоматические обновления?
Для небольших исправлений безопасности ядра CMS на простом сайте — да, это разумный компромисс. Для модулей и крупных версий на магазине или сайте с доработками — нет: риск того, что обновление ночью сломает оформление заказа, слишком велик.
Сайт давно не обновлялся. С чего начать?
С аудита: какие версии установлены, какие модули заброшены, где есть правки в чужом коде, какая версия PHP. Затем — план поэтапного обновления с промежуточными версиями. Прыгать сразу через несколько крупных версий опасно.
Сколько стоят регулярные обновления?
Для типичного сайта это несколько часов в месяц, и обычно они входят в абонентскую техническую поддержку. Разовое обновление запущенного сайта оценивается после аудита.
Выводы
Обновления CMS, модулей и серверного ПО — обязательная часть жизни сайта: они закрывают уязвимости, сохраняют совместимость с внешними сервисами и не дают накапливаться техническому долгу. Опасны не сами обновления, а их бессистемная установка. Резервная копия, проверка на тестовой копии, выкладка в спокойное время и готовый план отката превращают обновление в рутинную процедуру. Критические исправления стоит ставить в течение нескольких дней, плановые — раз в две-четыре недели, а крупные версии — после того, как их проверили другие.
Нужен сайт или интернет-магазин?
Обсудим задачу, подскажем подходящую платформу и оценим сроки и бюджет — бесплатно и без обязательств.
Обсудить проект
