Поддержка сайта: что входит и как часто нужна

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

Техническая поддержка сайта — это регулярная работа, которая этого не допускает. В статье объясняем, что входит в поддержку, как часто выполнять каждую задачу, чем отличаются потребности корпоративного сайта, интернет-магазина, WordPress и кастомного веб-приложения, от чего зависит стоимость и когда стоит держать поддержку внутри компании, а когда отдать команде. Мы опираемся на то, как сопровождаем сайты, созданные в рамках разработки корпоративных сайтов.

Что такое техническая поддержка сайта и зачем она

Техническая поддержка сайта — это регулярный набор технических, контентных и мониторинговых задач, которые держат сайт защищенным, быстрым, актуальным и работоспособным после запуска. Ее еще называют сопровождением или обслуживанием сайта, но цель одна: сайт должен каждый день выполнять свою работу для бизнеса без неприятных сюрпризов.

Что бывает без поддержки, вполне предсказуемо:

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

Падение скорости. Изображения добавляют без оптимизации, плагины накапливаются, база данных растет, настройки кэша «съезжают». Каждое изменение мелкое, но за год сайт может загружаться заметно медленнее, чем на старте, а это бьет и по конверсии, и по Core Web Vitals.

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

Простои. Просроченный домен или SSL-сертификат, переполненный диск, неудачное обновление. Проблемы с аптаймом часто вызывают вещи, которые легко было предотвратить напоминанием в календаре.

Технический долг. Каждое отложенное обновление делает следующее сложнее. Сайту, который пропустил два года обновлений, может понадобиться частичная перестройка только для того, чтобы вернуться на поддерживаемую версию. Подробнее о том, как он накапливается и кто за него отвечает, мы писали в статье про технический долг.

Хорошая поддержка в основном незаметна. Ее ценность видна в том, чего не происходит: нет взломов, нет простоев, нет медленного падения трафика.

Что входит в поддержку сайта

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

Технические обновления

• Обновления ядра CMS. WordPress, Drupal или любая другая CMS регулярно выпускает обновления безопасности и функциональности. Патчи безопасности стоит ставить быстро, крупные версии — после тестирования.

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

• Версия PHP. У каждой версии PHP фиксированный срок поддержки. Работа на версии, которая уже не поддерживается, означает отсутствие исправлений безопасности. Переход на новую версию требует проверки совместимости темы и плагинов.

• Фреймворки и среды. Для кастомных сайтов и headless-фронтендов это версии Node.js, фреймворки вроде Nuxt.js или Next.js, зависимости npm или Composer.

Все обновления сначала идут на тестовую копию, а не сразу на рабочий сайт. Тестовая копия (staging) — это закрытая копия сайта с теми же версиями ПО. Команда ставит обновления там, проверяет ключевые страницы, формы и оформление заказа и только потом повторяет обновление на живом сайте. Это добавляет час к процессу и убирает большую часть риска увидеть сломанную верстку или белый экран в понедельник утром.

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

Проверяйте SEO после каждого существенного обновления. Обновление темы или плагина может незаметно изменить title, убрать микроразметку, добавить noindex на страницы или сломать редиректы. Особенно это касается многоязычных сайтов: после обновления плагина переводов иногда пропадают hreflang или меняются адреса языковых версий. После каждого существенного обновления откройте несколько ключевых страниц на каждом языке, проверьте title и статус индексации в Google Search Console и быстро просканируйте самые важные шаблоны. Это занимает полчаса, а ошибку, замеченную сразу, исправить намного проще, чем через месяц, когда трафик уже упал.

Безопасность и резервные копии

• Бэкапы. Автоматические ежедневные резервные копии файлов и базы данных, которые хранятся отдельно от основного сервера, с несколькими версиями.

• Проверка на вредоносный код. Регулярное автоматическое сканирование на внедренный код, подозрительные файлы и наличие сайта в черных списках.

• Ревизия доступов. Удалите бывших сотрудников и подрядчиков, проверьте роли администраторов, убедитесь, что включена двухфакторная аутентификация.

• Продление SSL. Сертификаты должны продлеваться автоматически. С марта 2026 года максимальный срок действия публичных TLS-сертификатов составляет 200 дней, и в ближайшие годы он будет сокращаться дальше, так что ручное продление уже непрактично.

Почта и домен. Поддержка сайта часто включает и корпоративную почту на домене. Проверьте, что для домена настроены записи SPF, DKIM и DMARC: они защищают от подделки писем от вашего имени и помогают, чтобы письма с форм сайта и рассылки не попадали в спам.

Безопасность — большая отдельная тема. Подробно мы разобрали ее в статье безопасность сайта: чек-лист.

Оптимизация скорости

• Core Web Vitals. Следите за LCP, INP и CLS в Google Search Console и исправляйте страницы, попавшие в зону «требует улучшения» или «плохо».

• Кэширование. Проверяйте, что кэш страниц, браузера и сервера корректно работает после обновлений и изменений контента.

• CDN. Сеть доставки контента отдает статические файлы с серверов, ближайших к посетителю. Пересматривайте ее настройки и правила кэша, когда меняется структура сайта.

• Оптимизация изображений. Новые изображения от редакторов часто слишком большие. Автоматическое сжатие и современные форматы WebP или AVIF держат страницы легкими.

Обновление контента

• Устаревшие страницы. Старые акции, прошедшие события, услуги, которых больше нет, упоминания прошлых лет.

• Юридическая информация. Политика конфиденциальности, политика cookie и условия использования должны соответствовать действующему законодательству и инструментам, которыми вы реально пользуетесь.

• Команда и цены. Контакты, адреса, сотрудники, цены и график работы меняются чаще, чем о них вспоминают.

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

Для многоязычных сайтов добавьте еще одну проверку: обновили ли все языковые версии вместе. Часто украинская версия получает новое описание услуги, а русская или английская до сих пор показывает прошлогодний текст. Поисковые системы и AI‑ассистенты могут цитировать именно устаревшую версию тем, кто ищет на этом языке.

SEO-проверки

• Битые ссылки. Внутренние и внешние ссылки, которые ведут в никуда, вредят и пользователям, и сканированию.

• Ошибки 404. Страницы, которые удалили или перенесли без редиректа. Регулярно просматривайте отчеты об индексации в Google Search Console.

• 301-редиректы. Каждый измененный адрес нуждается в постоянном редиректе на новый. Проверяйте также цепочки и петли редиректов.

• XML sitemap и robots.txt. Sitemap должен содержать все важные страницы и ничего, что возвращает ошибки. Robots.txt не должен случайно блокировать важные разделы, а это случается удивительно часто после обновлений и миграций.

• Google Search Console. Следите за индексацией, ручными санкциями, проблемами безопасности и трендами эффективности.

Аналитика и трекинг

• GA4. Проверяйте, что данные собираются, фильтры работают, а ключевые события записываются.

• Google Tag Manager. Пересматривайте теги и триггеры после изменений на сайте. Обновленная форма или новая кнопка могут незаметно сломать отслеживание.

• Отслеживание форм и конверсий. Тестируйте, что каждая форма действительно отправляет заявки куда нужно, а конверсии доходят до GA4 и рекламных кабинетов.

Сломанный трекинг — одна из самых дорогих тихих поломок. Маркетинговые решения продолжают принимать на данных, которые перестали быть точными несколько недель назад.

Документируйте сайт, а не только задачи. Поддерживать сайт намного проще, когда существует базовая документация. Она не должна быть длинной. Один общий документ должен описывать, где размещен сайт и на каком тарифе, где репозиторий кода, какая версия CMS, тема и плагины установлены и зачем, какие есть интеграции (CRM, формы, оплата, аналитика, службы доставки) и кому принадлежит каждый аккаунт, где хранятся бэкапы и как их восстановить, а также известные особенности, например плагин, который нельзя обновлять без проверки определенной формы. Когда человек, который делал сайт, уходит, этот документ решает, будет ли передача спокойной или команде придется неделями разбираться в чужом коде.

Резервный контакт. Даже если поддержкой занимается один человек, у вас должен быть запасной вариант на случай его отпуска, болезни или увольнения. Документация и доступы, оформленные на компанию, позволяют быстро привлечь другого специалиста без потери времени.

Чек-лист поддержки сайта по периодичности

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

Еженедельно

☐ Проверить, что бэкапы успешно созданы и сохранены вне основного сервера

☐ Просмотреть уведомления мониторинга аптайма и время ответа сервера

☐ Протестировать ключевые формы: обратная связь, запрос коммерческого предложения, оформление заказа, подписка

☐ Просмотреть уведомления безопасности от файрвола, плагина безопасности или хостинга

☐ Для интернет-магазина: сделать тестовый заказ и проверить оплату

Ежемесячно

☐ Установить обновления CMS, плагинов и зависимостей после проверки на тестовой копии

☐ Просканировать сайт на битые ссылки и новые ошибки 404

☐ Проверить скорость ключевых шаблонов: главная, категория, товар, страницы услуг

☐ Просмотреть аналитику: тренды трафика, конверсии, резкие падения

☐ Проверить Google Search Console на проблемы с индексацией и безопасностью

☐ Запустить проверку на вредоносный код

Ежеквартально

☐ Провести ревизию контента: устаревшие страницы, юридическая информация, цены, команда, контакты

☐ Сделать SEO-аудит: title, meta description, редиректы, sitemap, внутренние ссылки

☐ Провести аудит доступов: удалить лишние аккаунты, пересмотреть роли и пароли

☐ Сделать тест восстановления: развернуть бэкап на тестовой среде и проверить, что все работает

☐ Пересмотреть трекинг: теги, события, конверсии

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

Ежегодно

☐ Проверить продление домена и автопродление, подтвердить, что автоматическое продление SSL работает

☐ Провести UX-обзор: поведение пользователей, формы, навигация, мобильная версия

☐ Провести аудит доступности по актуальным требованиям WCAG

☐ Сделать обзор стека: версия CMS, PHP или Node.js, тариф хостинга, компоненты без поддержки

☐ Пересмотреть сам план поддержки: что сработало, что пропустили, что изменить

Короткий ежемесячный отчет от исполнителя держит всех в одном контексте. Он не должен быть длинным: какие обновления установлены, что найдено и исправлено, аптайм за месяц, события безопасности, динамика скорости и Core Web Vitals, рекомендации на следующий месяц. Если одна и та же проблема появляется в отчете три месяца подряд, это сигнал, что ее нужно исправить по-настоящему, а не латать снова.

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

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

Особенности поддержки для разных типов сайтов

Чек-лист выше касается любого сайта, но вес каждого направления зависит от типа сайта.

Корпоративный сайт. Фокус на актуальности контента, формах заявок, аналитике и базовой безопасности. Трафик и функциональность обычно стабильны, поэтому большинству компаний подходит ежемесячный ритм с ежеквартальной ревизией контента. Самый большой риск в том, что формы или трекинг незаметно ломаются, и заявки пропадают неделями.

Интернет-магазин. Поддержка магазина интенсивнее. Оформление заказа, платежные интеграции, синхронизация остатков, способы доставки и товарные фиды должны работать каждый день. Ошибки в ценах и каталоге стоят денег напрямую. У магазинов и более строгие требования к безопасности, в том числе PCI DSS для оплаты картами, а пиковые сезоны требуют проверки производительности заранее. Для большинства магазинов минимум — это еженедельная проверка сценария заказа и немедленные обновления безопасности.

Сайт на WordPress. WordPress работает на большой части сайтов в мире, поэтому это главная цель автоматизированных атак. Для WordPress на первом месте обновления плагинов, их аудит, плагин безопасности, минимум администраторов и отключенные ненужные функции вроде XML-RPC. Многие проблемы WordPress происходят от избытка плагинов, так что пересмотреть установленное так же важно, как обновить. Если у вас WordPress и нужна помощь с обновлениями или защитой, команда по разработке на WordPress занимается и тем, и другим.

Кастомное веб-приложение. У кастомных приложений нет маркетплейса плагинов, но есть зависимости: фреймворки, библиотеки, среды выполнения, серверное ПО. Поддержка включает обновление зависимостей, мониторинг, анализ логов, обслуживание базы данных и проверку совместимости со сторонними API, которые меняются со временем. Кастомный код также требует разработчиков, которые его знают, поэтому документация и стабильность команды здесь особенно важны.

Украинская специфика поддержки. Для украинского бизнеса к стандартному перечню добавляются несколько пунктов. Первый: устойчивость к перебоям с электроснабжением и связью. Хостинг в дата-центре с резервным питанием или в ЕС, копии вне основной инфраструктуры и мониторинг, который работает независимо от вашего офиса, — здесь не роскошь. Второй: языковые версии. Для компаний, которые продают товары и услуги в Украине, закон требует, чтобы украинская версия загружалась по умолчанию для пользователей в Украине и была не меньше по объему и содержанию, чем иноязычные. Поэтому любое обновление контента должно появляться на украинском не позже, чем на других языках. Третий: местные интеграции. Платежные сервисы, программные РРО, службы доставки и учетные системы время от времени обновляют свои API, и после таких обновлений обмен данными с сайтом нужно проверять. Четвертый: DDoS-атаки, которые для украинских сайтов остаются реальностью, поэтому защиту на уровне WAF стоит включить в поддержку, а не включать в спешке во время атаки.

От чего зависит стоимость поддержки сайта

Стоимость зависит от сайта и от того, сколько ответственности вы хотите передать. Единой цены нет, но есть понятные модели и факторы.

Модели оплаты:

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

• Абонентское обслуживание. Фиксированный ежемесячный платеж покрывает согласованный объем работ и определенное количество часов. Предсказуемо для обеих сторон и самая распространенная модель для бизнес-сайтов.

• Уровни SLA. Соглашение об уровне сервиса определяет время реакции и исправления для разных типов проблем, например критического падения сайта и мелкой правки контента. Более высокие уровни с быстрой реакцией дороже.

Факторы стоимости:

• Платформа и стек: стандартный сайт на WordPress проще поддерживать, чем кастомное приложение с множеством интеграций.

• Размер и сложность: количество страниц, шаблонов, языков и интеграций.

• Функции магазина: оплата, остатки, доставка и более высокие требования безопасности.

• Нужное время реакции: на следующий рабочий день или в течение часа круглосуточно.

• Текущее состояние сайта: сайт с годами отложенных обновлений требует первоначальной «уборки», прежде чем начнется регулярная поддержка.

• Работа с контентом: входят ли в поддержку регулярные обновления контента или только техническая работа.

Точнее всего оценить поддержку можно, посмотрев на конкретный сайт. Мы анализируем платформу, текущие версии, интеграции и ваши ожидания и после брифа предлагаем объем работ и оценку, которые подходят именно этому сайту.

Что должен содержать договор на поддержку. Кто бы ни выполнял работу, письменный договор предотвращает большинство недоразумений. Проверьте, что в нем есть:

• Объем. Какие задачи входят ежемесячно, а какие оплачиваются отдельно, например новые страницы, переделка разделов или новые интеграции.

• Время реакции и исправления. Разное для разных приоритетов: критическое падение сайта, сломанная форма, мелкая правка контента.

• Рабочие часы. Реагирует ли команда ночью и в выходные и как с ней связаться.

• Отчетность. Что содержит ежемесячный отчет и когда вы его получаете.

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

• Условия завершения. Что подрядчик передает, если вы прекращаете сотрудничество: доступы, документацию, свежий бэкап и список открытых задач.

Хороший договор защищает обе стороны и позволяет легко оценить, работает ли сервис.

Штатный разработчик или подрядчик

Есть три распространенных способа организовать поддержку. Каждый может работать, выбор зависит от сайта и вашей команды.

Малому бизнесу обычно лучше всего подходит абонентское обслуживание в агентстве. Небольшой компании редко нужен штатный разработчик, но ей нужен кто-то, кто быстро отреагирует, когда сайт ляжет, и кто будет ставить обновления без напоминаний.

Для крупных продуктов граница между поддержкой и разработкой размывается. Если ваш сайт или приложение постоянно развивается, выделенная команда совмещает поддержку с новыми функциями и сохраняет тех же людей на продукте.

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

Как передать сайт новой команде поддержки. Смена подрядчика не должна быть прыжком в неизвестное. Чтобы передача прошла спокойно, сделайте несколько шагов. Сначала соберите все доступы: хостинг, домен, DNS, CMS, репозиторий кода, аналитика, почта, сторонние сервисы. Убедитесь, что главные аккаунты зарегистрированы на компанию, а не на конкретного человека. Дальше попросите предыдущего исполнителя передать документацию, свежий полный бэкап и список известных проблем и незавершенных задач. Новая команда должна провести аудит: проверить версии ПО, безопасность, бэкапы, скорость и состояние SEO, чтобы зафиксировать точку старта. Только после этого стоит менять пароли и закрывать доступ предыдущему исполнителю. И последнее: первые две-три недели держите связь с предыдущей командой, потому что вопросы о неочевидных настройках почти всегда появляются.

Что делать, когда что-то сломалось. Инциденты случаются даже на хорошо поддерживаемых сайтах. Важно, как быстро их замечают и устраняют. Базовый процесс такой: мониторинг обнаруживает проблему и уведомляет ответственного, тот оценивает, критичная она (сайт не работает, оплата сломана, данные под угрозой) или мелкая, исправляет или откатывает последнее изменение, а затем коротко объясняет бизнесу, что произошло и что сделано, чтобы это не повторилось. Заранее договоритесь, кто может принимать решения ночью или в выходные, особенно для интернет-магазинов, где каждый час простоя означает потерянную выручку.

Какую бы модель вы ни выбрали, зафиксируйте письменно три вещи: что входит в работу, как быстро команда реагирует на разные проблемы и кому принадлежат доступы к хостингу, домену, коду и аккаунтам.

Используйте часы поддержки для улучшений, а не только для ремонта. Многие компании воспринимают поддержку только как защиту. Лучший подход — зарезервировать часть ежемесячных часов на небольшие улучшения: исправить непонятное поле формы, замеченное в записях сессий, облегчить тяжелую страницу, улучшить внутренние ссылки на важную услугу, обновить кейс. Каждое изменение мелкое, но за год они складываются в заметно лучший сайт без стоимости и рисков большого редизайна.

Признаки, что текущая поддержка не работает. О падении сайта вы узнаете от клиентов, а не из мониторинга. Никто не может сказать, когда в последний раз проверяли восстановление из бэкапа. Плагины и CMS отстают на несколько версий. Отчетов нет, или каждый месяц в них написано «все хорошо» без деталей. Мелкие запросы выполняются неделями. Если узнаете два пункта или больше, пересмотрите договор или подрядчика, прежде чем что-то сломается.

Когда поддержки уже недостаточно

Поддержка держит сайт здоровым, но не может исправить сайт, который больше не соответствует бизнесу. Признаки, что пора на редизайн или перестройку:

• Устаревшая CMS или стек. Платформа или ее версия больше не поддерживается, и обновление все равно означает переписать большие части сайта.

• Обновления постоянно что-то ломают. Каждое обновление вызывает конфликты, и команда тратит больше времени на исправление последствий, чем на улучшения.

• Скорость не исправить. Core Web Vitals остаются плохими несмотря на оптимизацию, потому что проблема в архитектуре или теме.

• Бизнес перерос сайт. Новые услуги, рынки, языки или функции магазина не укладываются в существующую структуру.

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

• Стоимость поддержки постоянно растет. Когда вы каждый год платите больше, чтобы удержать старый сайт, перестройка за несколько лет часто обходится дешевле.

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