Техническая поддержка сайта: что входит и сколько стоит

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

Базовый набор работ

В стандартный пакет техподдержки входят обновления CMS и плагинов, резервное копирование (чаще всего ежедневное), мониторинг доступности и базовая защита от взломов. Сюда же относится исправление критических ошибок и регулярные консультации. Базовый набор закрывает типовые задачи, но не решает нестандартные проблемы. Если сайт работает на самописной системе или имеет сложную логику, стандартного пакета может не хватить, и тогда логично задуматься о более глубокой проработке, например, о SEO-продвижении параллельно с техническими работами.

Мониторинг доступности в базовой версии настроен на проверку главной страницы раз в 5–10 минут. Этого достаточно, чтобы заметить падение, но не всегда хватает для отслеживания ошибок на внутренних страницах. Резервное копирование делается на внешний сервер: если хостинг ляжет, копия на нём же не спасёт. Обновления CMS выполняются вручную после проверки совместимости, а не автоматически, иначе можно получить конфликт версий. Средний срок реакции на заявку от 4 до 8 рабочих часов.

Дополнительные услуги за отдельную плату

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

Отдельная тема это контентные задачи: обновление цен, добавление товаров, правка текстов. Формально это техподдержка, но такие заявки быстро съедают бюджет, поэтому агентства чаще предлагают помесячные пакеты на определённое количество часов. Если у вас интернет-магазин с большим каталогом, выгоднее считать стоимость за час или за операцию. Уточняйте, входит ли в базовый пакет работа со скоростью загрузки и SEO-правки, потому что одни агентства включают их по умолчанию, а другие выставляют счёт за каждое изменение мета-тегов.

Сколько стоит техподдержка сайта в 2026 году

Сколько стоит техподдержка сайта в 2026 году

Ценовая вилка в 2026 году широкая, разброс в 2–3 раза на одинаковый тип сайта это норма. Для сайта-визитки разовая заявка обойдётся в 1 500–3 000 ₽, ежемесячный тариф стартует от 8 000–15 000 ₽. Корпоративный сайт со сложной структурой потянет на 20 000–40 000 ₽ в месяц, интернет-магазин с каталогом и платёжными системами начинается от 35 000 ₽ и легко уходит за 80 000 ₽ при активной доработке.

Форматы работы делятся на три подхода. Разовая заявка это когда сайт «упал» или нужно срочно поправить мелочь, вы платите за конкретную задачу. Тариф с фиксированной ценой даёт лимит часов в месяц, обычно 5–20, и приоритетную очередь в чате. SLA добавляет юридические гарантии: время реакции 1–4 часа, штрафы за простой и персонального инженера. Цена зависит от того, кто реально будет работать: фрилансер или команда с дежурным инженером, и какой стек технологий, ведь поддерживать самописную CMS сложнее, чем типовой WordPress.

Разница в цене чаще объясняется составом работ и скоростью реакции. В дешёвый тариф за 10 000 ₽ входит только реактивное реагирование, в премиум за 30 000 ₽ уже включены ежедневный бэкап, мониторинг скорости и проактивные правки безопасности. Мы обычно рекомендуем не экономить на SLA, если у вас интернет-магазин: час простоя в чёрную пятницу стоит дороже годовой подписки. В любой тариф должны входить базовые работы по оптимизации, включая настройку ускорение загрузки сайта через CDN. Итоговая стоимость складывается из трёх факторов:

• Тип CMS и количество интеграций, например, 1С или CRM добавляют 30–50% к цене.
• Срочность реакции: 15 минут в SLA стоит в разы дороже, чем 4 часа.
• Количество доработок: тарифы с лимитом часов выгоднее при стабильном сайте.
• Уровень специалистов: команда с DevOps и бэкенд-разработчиком дороже фрилансера.
• География и репутация агентства, московские цены выше региональных на 20–40%.
• Наличие отчётности и ежемесячных аудитов, это тоже закладывается в стоимость.

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

CMS и сложность кода

Первый фактор ценообразования, который мы озвучиваем клиенту еще на этапе аудита, это CMS. Поддержка сайта на самописной системе всегда дороже, чем на популярной платформе вроде WordPress или «1С-Битрикс». К такому коду сложнее найти специалиста, документация часто отсутствует, а каждый новый разработчик тратит время на разбор архитектуры. С популярной CMS обновления ядра и модулей автоматизированы, в сообществе тысячи готовых решений. На практике разница в ежемесячной ставке может достигать 50–70% при одинаковом функционале. Если код писали «на коленке» несколько подрядчиков, мы закладываем в стоимость работы по рефакторингу, иначе любое мелкое изменение превращается в квест.

Второй момент, который сильно влияет на чек, это сложность функционала и количество страниц. Поддержка визитки на десять страниц и интернет-магазина с каталогом на пять тысяч позиций, фильтрами и личным кабинетом это разные объемы работы, даже если трафик сопоставим. Каждая интеграция, будь то CRM, служба доставки или платежный шлюз, добавляет точки отказа. Когда что-то ломается, мы тратим время на диагностику и выяснение, кто виноват: наш сайт или внешний сервис. Часто причина проблем вообще не в коде, а в настройках сервера или несовместимости версий, как в случае с ошибкой 500 на сайте, которую вызывают десятки разных причин, от битого .htaccess до нехватки памяти.

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

Как выбрать подрядчика: чек-лист из 7 пунктов

Регламент и SLA

Перед подписанием договора требуйте конкретный регламент работ. В нём должны быть прописаны сроки реакции на заявки: например, 15 минут на критичную ошибку и 4 часа на правку контента. Проверьте, есть ли в SLA пункт о времени восстановления сайта после сбоя, обычно это 2–4 часа, и что подрядчик делает, если не уложился в срок. Обратите внимание, включена ли работа в нерабочие часы и праздники, иначе срочная проблема в пятницу вечером останется без ответа до понедельника.

Отдельно посмотрите на зону ответственности: кто отвечает за ущерб, если подрядчик удалил базу данных или сломал вёрстку. В договоре должно быть прописано возмещение, а не формулировка «приложим все усилия». Уточните, делает ли компания резервные копии и как быстро их можно восстановить. Также зафиксируйте, какие работы не входят в поддержку и оплачиваются отдельно: например, написание текстов или разработка новых блоков.

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

Типичные ошибки при заказе техподдержки

Типичные ошибки при заказе техподдержки

Чаще всего клиенты приходят к нам после того, как сэкономили на поддержке и получили взломанный сайт или потерянную базу. Самая распространённая модель: выбрать самый дешёвый тариф у фрилансера, который «обновляет что-то по мере необходимости». В реальности это означает, что обновления ядра CMS не ставятся месяцами, а доступы к админке и хостингу хранятся в открытом чате. Когда сайт падает в пятницу вечером, подрядчик не отвечает до понедельника, а восстановление из резервной копии оказывается невозможным, потому что копии никто не делал.

Вторая системная ошибка, отсутствие регламента и прописанного плана действий при сбое. Заказчик не фиксирует в договоре время реакции, перечень работ и ответственность сторон. Мы обычно советуем проверять у подрядчика три вещи ещё до подписания: как часто создаются бэкапы, куда они выгружаются (на отдельный сервер или в облако, а не на тот же хостинг) и есть ли пошаговая инструкция по восстановлению. Если ответы расплывчатые, это верный признак того, что при реальной аварии вы останетесь один на один с проблемой.

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

• Регулярное резервное копирование с выгрузкой на внешнее хранилище, минимум раз в сутки.
• Обновление ядра CMS, плагинов и шаблонов в течение 2–3 рабочих дней после выхода патча безопасности.
• Мониторинг доступности сайта с уведомлением о сбое за 5–10 минут.
• Прописанный в договоре план восстановления с указанием ответственных и времени реакции.
• Проверка на вредоносный код и чистка при заражении без дополнительной оплаты.
• Смена паролей и аудит доступов хотя бы раз в квартал.

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

Что делать, если сайт уже сломался

Первые шаги при взломе

Если сайт уже лежит или появилась подозрительная активность, первым делом отключайте его от интернета. Это может быть временная страница на хостинге или остановка виртуального сервера, главное остановить распространение заразы и не потерять данные. Дальше снимаем логи веб-сервера, CMS и SSH, смотрим, что происходило перед сбоем: обычно там видны подозрительные запросы к админке и аномальный трафик с конкретных IP. В Яндексе и Google параллельно проверяем индексацию, чтобы оценить, не подставляют ли злоумышленники спам-страницы. Срочная помощь нужна, если счёт идёт на минуты: сайт раздаёт вирусы клиентам или в письмах о взломе уже упоминается ваш домен. В таких ситуациях мы в Cinar подключаемся в течение часа, но если у вас есть подрядчик, звоните ему, а не пишите в тикеты.

Восстановление из резервной копии работает только тогда, когда бэкапы реально есть и они свежие. Мы обычно откатываемся на последнюю чистую копию, а не на ту, что упала в момент взлома, иначе вернёте вместе с сайтом и дыру. После отката меняем все пароли: от CMS, хостинга, FTP, базы данных, а также ключи API и токены. Если бэкапа нет, а сайт критичен, есть вариант вычистить заражение вручную, но это дороже и дольше, чем кажется. Поэтому в договоре на техподдержку сайта всегда должна быть прописана частота резервного копирования и срок хранения копий, иначе восстановление превращается в лотерею.

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

Часто задаваемые вопросы

Кирилл Токарев

Senior SEO-специалист

Подписаться на ТГ