CMS, плагины и PHP обновляют не одновременно и не по одной схеме. У каждого — своя частота и свой риск. Ядро CMS и критические патчи безопасности ставят сразу после выхода. Плагины — раз в месяц пакетом. PHP — раз в год, после проверки совместимости. Если система обновлений идёт от случая к случаю, а не по плану, рано или поздно понадобится доработка и обновление сайта уже после того, как накопится десяток непроверенных версий разом.
Короткий ответ: календарь обновлений на год
Таблица ниже — рабочий календарь: что обновлять, с какой частотой, какой риск при пропуске и как проверить, что после обновления ничего не сломалось.
| Что | Как часто | Риск | Как проверить после |
| Критические патчи безопасности CMS | В день выхода | Взлом через известную уязвимость | Версия в админке совпадает с последней у разработчика |
| Ядро CMS (минорные версии) | Раз в месяц | Накопленные баги, конфликт с новыми плагинами | Главные страницы открываются, формы отправляются |
| Плагины и модули | Раз в месяц, пакетом | Конфликт между плагинами, отключение функции | Проверка ключевых сценариев: корзина, форма, поиск |
| PHP | Раз в год, с проверкой совместимости | Часть плагинов не запустится на новой версии | Сайт открывается без ошибок PHP в логах |
| SSL-сертификат | Автопродление или раз в 90 дней вручную | Браузер блокирует сайт как небезопасный | Замок в адресной строке, срок действия сертификата |
| Контент и функционал | Раз в квартал | Устаревшие цены, битые ссылки, забытые акции | Ручной обход ключевых страниц раз в квартал |
| Резервная копия | Перед каждым обновлением | Нечем откатиться при сбое | Тестовое восстановление копии на отдельном стенде |
Семь строк, семь разных ритмов. Смешивать их в один процесс «обновляем всё раз в год» — то, из-за чего сайты чаще всего ломаются на ровном месте.
Как обновлять, не ломая сайт: копия, тест, откат
Одно правило перед любым обновлением: сначала копия, потом изменения. Без свежей резервной копии откат после неудачного обновления превращается в ручную реставрацию по памяти. С копией — это возврат на пару кликов назад. Мало просто сохранить архив. Важно убедиться, что копия действительно восстанавливается, а не просто существует на диске. Как проверить, что бэкап рабочий, до того как он понадобится по-настоящему, — тема отдельной статьи о восстановлении сайта из бэкапа.
Дальше — тест. Крупные обновления (смена мажорной версии CMS, переход PHP) сначала ставят на копию сайта: тестовый поддомен или локальную среду. Мелкие — патчи безопасности, обновления плагинов — можно катить сразу на боевой сайт, если копия свежая, а откат уже проверен на практике. После любого обновления проходят по ключевым сценариям вручную: главная страница, карточка товара, корзина, форма заявки, поиск. Автоматических тестов на большинстве сайтов нет, и ручной обход за пять минут закрывает большую часть рисков.
PHP: почему версия имеет значение для скорости и безопасности
PHP обновляют не только ради новых функций языка. Каждая версия ветки поддерживается два года с активными патчами и ещё какое-то время — только патчами безопасности, после чего поддержка версии прекращается полностью. На конец сентября 2026 активно поддерживаются версии 8.2–8.5. Поддержка PHP 8.2 заканчивается 31 декабря 2026 года (источник: endoflife.date/php, проверено 29.09.2026). Сайт на версии без поддержки не получает патчей безопасности вовсе. Дыры остаются открытыми навсегда.
Помимо безопасности, версия PHP напрямую влияет на скорость: почему сайт тормозит после обновления и как часть замедлений объясняется именно устаревшим PHP, разобрано в отдельном материале о скорости сайта, включая таблицу диагностики за 15 минут.
Особенности по CMS
Общий календарь работает для любой платформы, но у каждой популярной CMS — свои узкие места при обновлении.
Если сайт на 1С-Битрикс
Битрикс тянет за собой не только ядро, но и модули, и лицензию. Часть функциональности перестаёт обновляться при истёкшей подписке. Обновление 1С-Битрикс без падения сайта — ядро, модули и PHP разом — разобрано в отдельной статье про обновление платформы.
Если сайт на WordPress
WordPress по умолчанию ставит минорные и переводные обновления автоматически, а для критических уязвимостей команда WordPress может форсированно включить автообновление даже на сайтах, где оно отключено (источник: developer.wordpress.org, раздел про обновление WordPress, проверено 29.09.2026). Проблема чаще приходит не от ядра, а от плагинов. Конфликт версий после автообновления одного плагина — частая причина белого экрана. Что делать при критической ошибке WordPress и как быстро вернуть сайт в рабочее состояние, разобрано в отдельном материале.
Если сайт на OpenCart
OpenCart 3 официально ещё поддерживается, но новая функциональность и модули выходят уже под 4-ю ветку, и разрыв между версиями со временем растёт. Переход OpenCart на 4-ю версию — обоснованный шаг прямо сейчас или нет, и что при переходе может сломаться в модулях, разобрано в отдельном материале про выбор между OpenCart 3 и 4.
SSL-сертификат и контент: что ещё проверять по расписанию
SSL-сертификат — не разовая настройка. Бесплатные сертификаты Let's Encrypt, на которых работает значительная часть сайтов, выдаются сроком на 90 дней и требуют автоматического продления через настроенный на хостинге сервис — при сбое автопродления браузер начинает помечать сайт как небезопасный уже через три месяца (источник: letsencrypt.org, проверено 29.09.2026). Платные сертификаты живут дольше, но и их срок конечен. Дата окончания тоже должна быть в календаре обновлений — рядом с обновлением CMS.
Контент устаревает тише, чем ломается код, и потому его проверяют реже, но не пренебрегают вовсе. Раз в квартал полезно пройтись по ключевым страницам: актуальны ли цены, работают ли ссылки на внешние ресурсы, не висят ли баннеры давно прошедших акций. Мелочь по отдельности, но в сумме она формирует ощущение заброшенности сайта у посетителя, даже если код полностью исправен.
Когда обновлений уже мало
Регулярные обновления решают техническую часть. Сайт работает, не взломан, не тормозит из-за старого PHP. Задачи роста они не решают: новый функционал, изменившийся дизайн под текущие ожидания аудитории, интеграции, которых не было на старте. Момент, когда обновлений уже мало и пора задуматься о более крупной доработке, а не о плановом патче, разобран в отдельном материале с матрицей решения: доработать существующий сайт или делать новый.
Частые вопросы
Кто должен отвечать за обновления сайта — штатный сотрудник или подрядчик?
Зависит от масштаба сайта и от того, есть ли в компании штатный ИТ-специалист с нужной квалификацией. Для большинства компаний устойчивее вариант с подрядчиком на технической поддержке на регулярной основе: обновления идут по графику, а не когда «руки дойдут» у сотрудника с другими основными задачами.
Что делать, если после обновления плагина сайт сломался?
Сначала откатить именно тот плагин или модуль, который обновлялся последним, — это чаще всего и есть причина. Если откат отдельного компонента не помог, восстанавливайте сайт из резервной копии, снятой перед обновлением, и уже на копии разбирайтесь, что именно пошло не так.
Можно ли не обновлять сайт вовсе, если он и так работает?
Можно, но это временная экономия. Без обновлений безопасности растёт риск заражения через известные уязвимости, а без обновлений PHP сайт со временем окажется на версии без поддержки хостинга. Рано или поздно накопленный долг обходится дороже регулярных плановых работ.