Зачем обновлять CMS и плагины и что бывает, если этого не делать

Сайт, который не обновляли год-два, ломается не сам по себе: в старом плагине находят уязвимость, и через неё заходят. Лечение обходится в 10-30 тысяч рублей плюс простой, а обновление по регламенту занимает час в месяц.

Каждый второй клиент, который приходит ко мне с проблемой «сайт сломался ни с того ни с сего», в действительности не обновлялся 1-2 года. Дырка в старом плагине, через которую кто-то зашёл и закинул бэкдор. Или конфликт с обновлённой версией PHP на хостинге, которую владелец не заметил. Или просто настолько древний WordPress, что новый плагин уже не ставится.

Обновления это не каприз разработчика и не возможность что-то продать. Это базовая гигиена сайта, без которой через год вы получаете полный набор проблем сразу.

Что вообще обновляется

На типичном WordPress-сайте есть пять слоёв, каждый из которых живёт своей жизнью.

Ядро CMS. Сам движок: WordPress core, Битрикс ядро, OpenCart engine. Релизится раз в 1-3 месяца, минорные патчи безопасности по мере необходимости.

Темы. Дизайн-шаблон. Обновляется реже, иногда вообще не обновляется (если автор бросил тему).

Плагины и модули. Десятки расширений: SEO, форма, кеширование, аналитика, резерв, безопасность. Обновляются плагин на плагин, кто как попало.

Серверная инфраструктура. PHP-версия, MySQL, Apache, nginx, OpenSSL. Хостер обновляет сам, обычно с предупреждением.

Сторонние библиотеки внутри плагинов. jQuery, lodash, Bootstrap. Когда плагин обновляется, заодно подтягиваются новые версии библиотек.

Каждый из этих слоёв в каждый момент имеет свежую версию и свои уязвимости. И именно несвежие версии становятся вектором атаки.

Что бывает, если не обновлять

Я видел все варианты. Перечисляю по частоте.

Сайт взламывают через старый плагин

Самый частый сценарий. У плагина была RCE-уязвимость (Remote Code Execution позволяет выполнить произвольный код), её закрыли в новой версии 6 месяцев назад. Старая версия осталась у вас. Бот сканирует интернет и находит уязвимый плагин. Через 5 минут на сайте бэкдор.

Конкретный пример из 2024: уязвимость в популярном плагине LiteSpeed Cache (CVE-2024-44000). Закрыта в версии 6.4.5. Сайты, которые не обновились в течение недели, массово ломали. Я лично разбирал три таких случая у клиентов, которые до этого работали без меня.

Симптомы взлома: чужие админы в списке пользователей, странные файлы в /wp-content/, редиректы на чужие сайты, появление сайта в чёрных списках Яндекса и Google.

Восстановление обычно: бэкап + чистая установка + ручная проверка. Стоимость работы 10-30 тысяч рублей плюс стоимость потерянной репутации в Яндексе.

Сайт перестаёт работать после обновления PHP

Хостер обновляет PHP с 7.4 на 8.2. Старый плагин использует функции, которые в 8.0 уже deprecated, а в 8.2 удалены. Сайт ломается на главной с белым экраном или с фатальной ошибкой.

Симптомы: 500 Internal Server Error, белый экран, ошибки в логе вроде «Call to undefined function» или «Cannot use object as array».

Чтобы такого не было, надо либо проверять плагины перед обновлением PHP, либо держать всё в свежих версиях, потому что свежие плагины уже умеют работать с новыми PHP.

Подробно про переход на 8.2 я писал в отдельной статье.

Перестают приходить заявки

Форма работает, но не доставляет. Причина: SMTP-протокол в старой версии плагина перестал работать с новым требованием хостера (например, обязательный TLS 1.2 или новые правила SPF/DKIM).

Симптомы: форма «спасибо, мы свяжемся», на email ничего не приходит, в логах хостера видно «email rejected».

Это незаметная катастрофа, потому что владелец думает, что просто никого не интересует, а на самом деле теряет десятки заявок в неделю.

Сайт пропадает из выдачи

Поисковики постепенно меняют требования. Например, Яндекс с 2024 года жёстко наказывает за плохой LCP. Старая тема WordPress, в которой главное изображение грузится через PHP-скрипт, а не напрямую, может проседать по LCP на 0.5 секунды и потерять полпозиции в выдаче.

Симптомы: трафик из поисковиков медленно снижается. На графике это плавная кривая вниз за 3-6 месяцев.

Лечится обновлением темы или подменой её на современную.

Не работают новые функции

Поставили новый плагин для оплаты. Он не работает, потому что требует WordPress 6.5 минимум, а у вас 5.2. Пытаетесь обновить WordPress натыкаетесь на конфликт с темой, которая поддерживает только до 5.9.

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

Хостер просит съехать

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

Если ваш сайт не готов к новой версии, переезд это срочный аврал на праздниках.

Почему люди не обновляют

В 90 процентах случаев слышу одну из этих причин.

«Боимся, что что-то отвалится». Понятно. У 5-10 процентов обновлений действительно бывают регрессии. Но в остальных 90-95 процентах всё проходит штатно. И риск пропустить обновление безопасности обычно выше, чем риск регрессии.

«Нас никто не атакует, мы маленькие». Это самый опасный миф. Атаки давно автоматизированы. Бот сканирует все сайты подряд и не разбирается, маленький вы или большой. Маленький сайт интересен ботнету как место для размещения фишинга, как точка для рассылки спама, как площадка для майнинга криптовалюты в фоновом потоке.

«Не хочется платить разработчику». Понятно, но цена расхлёбывания после взлома почти всегда в 5-10 раз выше, чем цена регулярных обновлений.

«У меня нет доступа в админку». Бывает, что владелец давно потерял пароль, а разработчик пропал. Это первое, что я разбираю на старте абонентского обслуживания: восстанавливаем доступ к админке, к хостингу, к домену, к репозиторию.

Регламент обновлений на маленьком сайте

Что я ставлю клиенту в первую неделю работы.

Раз в неделю: безопасные обновления

Каждый понедельник я (или скрипт) проверяет наличие минорных обновлений CMS и плагинов. Минорные это 5.4.3 → 5.4.4. В 99 процентах случаев это патчи безопасности и багов, без новых функций. Накатываются автоматически.

В WordPress можно включить автообновление в wp-config.php:

define('WP_AUTO_UPDATE_CORE', 'minor');

Для плагинов автообновление включается в админке: Plugins → Plugins → Auto-updates Enabled рядом с каждым плагином.

Раз в месяц: мажорные обновления

Мажорные обновления (5.4 → 6.0) накатываются вручную, после проверки на копии сайта.

Процесс:

1. Делаем полный бэкап (файлы + база).
2. Разворачиваем staging-копию: либо на поддомене, либо на локальном сервере.
3. На staging накатываем все мажорные обновления.
4. Прогоняем чек-лист: главная, заявка, корзина, поиск, авторизация.
5. Если всё ровно, накатываем на боевой сайт.
6. Прогоняем тот же чек-лист на боевом.
7. Записываем в журнал: что обновлено, дата, замечания.

Это занимает 1-2 часа в месяц на средний сайт. Ничтожная цена за то, чтобы потом не разбирать инцидент.

Раз в квартал: стек

Раз в три месяца проверяем:

• Версия PHP на хостинге (актуальная против вашей).
• Версия MySQL/MariaDB.
• TLS-сертификат и его срок.
• Используются ли deprecated-вещи в коде темы.
• Не накопились ли устаревшие плагины «которые не обновлялись 2 года».

Если автор плагина бросил его, это повод заменить на аналог. Брошенные плагины это будущая дыра.

Раз в год: тема и архитектура

Раз в год смотрим, не пора ли менять тему. Старая тема WordPress 2015 года против современной это разница в скорости в 2-3 раза. Иногда замена темы это самое полезное обновление, которое можно сделать за весь год.

Как обновлять, чтобы не сломать

Несколько правил, которые сильно снижают риск регрессий.

Правило 1. Перед обновлением бэкап. Полный, файлы плюс база. Если обновление сломает сайт, откатываем за 15 минут.

Правило 2. Сначала staging, потом боевой. Staging это копия сайта на отдельном поддомене или на локальной машине. Любое серьёзное обновление катаем сначала там.

Правило 3. Не обновлять всё разом. Когда зависло 20 обновлений плагинов плюс мажорный WordPress, накатывайте по одному. Если что-то сломается, понятно от чего.

Правило 4. Читать changelog. У серьёзных плагинов есть страница изменений. Если в changelog написано «breaking change», «database migration», «removed function», читаем внимательно перед обновлением.

Правило 5. Не обновлять в пятницу вечером. Если что-то сломается, чинить будете в выходные. Обновляем во вторник утром, когда есть весь день на разбор.

Правило 6. Логировать. После каждого обновления пишем строчку в журнал: дата, что обновили, с какой версии на какую, заметили ли что-то странное. Через год этот журнал спасает от вопроса «когда у нас сломалась корзина».

Когда обновляться не нужно

Бывают случаи, когда обновление можно отложить или не делать.

Сайт-памятник, к которому никто не ходит. Если на сайт заходит 5 человек в месяц, и это не приносит денег, его можно держать на консервации, и обновлять только когда хостер скажет. Но и трафик с такого сайта не выкупается, и SEO падает, поэтому стратегически лучше или развивать или закрыть.

Замороженная версия в проде с критичной кастомизацией. Если в плагин внесли свои правки руками, обновление переписывает их, и поведение меняется. Лечится либо переносом правок в виде хук-плагина, либо подбором версии без обновления, либо форком плагина.

Конкретная плагин-связка работает только в старой версии. Например, ваш плагин для интеграции с amoCRM поддерживает только WordPress до 5.9. В этом случае: пишем автору, ищем альтернативу, или закладываем стоимость переписывания.

В остальных случаях обновления не откладываем.

Кейс: что я разбирал на прошлой неделе

Клиент пришёл с проблемой: сайт показывает страницу заглушки от хостера «сайт временно недоступен по причине нарушения политик».

Разбор:

1. Зашёл в админку панели хостера (через резервный доступ, основной заблокирован).
2. В логе ошибок нашёл письмо: «обнаружена рассылка спама с вашего аккаунта».
3. Скачал бэкап последней рабочей версии (вчерашний). На staging развернул.
4. На staging запустил сканер вирусов нашёл в папке плагина файл wp-content/plugins/foobar/inc/license.php, в котором был base64-зашифрованный шеллкод.
5. Посмотрел changelog плагина foobar v3.2.1 закрыли RCE-уязвимость 4 месяца назад. У клиента стоял v3.1.4.
6. Восстановил сайт из бэкапа двухмесячной давности (когда дыры точно ещё не было).
7. Обновил все плагины и WordPress до текущих.
8. Прошёл скрипт-сканер, шеллкодов больше нет.
9. Проверил все учётки в админке убрал двух «странных» admin’ов с email на mailinator.com.
10. Сменил все пароли (админка, FTP, БД, хостинг).
11. Подал апелляцию хостеру: вот лог восстановления, вот свежие версии. Сайт разблокировали через 6 часов.

Время на работу: 6 часов. Стоимость для клиента: 8400 рублей.

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

Что точно нужно обновить уже сейчас

Если вы давно не открывали админку, минимальный план:

1. Зайти в админку и посмотреть, сколько обновлений висит.
2. Сделать бэкап (на хостинге и в облако, см. статью про ретенцию бэкапов).
3. Накатить минорные обновления плагинов и ядра.
4. Накатить мажорные обновления плагинов с проверкой на staging.
5. Проверить, не висит ли в списке плагинов «не обновлялся два года» если есть, заменить.
6. Зайти в Settings → General и в Settings → Privacy: проверить, что email на месте, что URL правильный.
7. Включить автообновления для всего, что вы готовы обновлять автоматически.

После этого ваш сайт переходит из категории «легкая мишень» в категорию «обновляемый, требует работы».

Куда дальше

Связанные материалы: Обновление WordPress без поломок, Как очистить WordPress от вирусов, Безопасные плагины WordPress.

Если еженедельные обновления и проверки делать самому скучно, у меня в годовом и месячном тарифе абонентского обслуживания они входят в стандартный регламент. Не нужно открывать админку, читать changelog, разворачивать staging всё это делается за вас. Заявка на главной.

Частые вопросы

Зачем обновлять CMS и плагины

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

Как часто обновляться

Исправления безопасности сразу, остальное раз в месяц пакетом с проверкой после установки. Раз в квартал имеет смысл смотреть, не заброшен ли какой-то плагин автором.

Почему люди не обновляются

Боятся сломать. Страх обоснованный, если обновляться сразу на боевом сайте и без копии. С тестовой площадкой и бэкапом риск падает почти до нуля.

Сколько стоит не обновляться

Чистка после взлома обходится в 10-30 тысяч рублей плюс простой и потерянные заявки. Плюс время на выход из чёрных списков, если сайт успели туда занести.