Сайт запускается, все довольны, а через пару месяцев перестаёт приходить письмо о новом заказе, потому что СДЭК обновил версию API, или Tilda выкатила новый редактор и кастомный скрипт с зонами доставки перестал работать. Вот тогда и вспоминают про услугу сопровождения сайта, обычно уже после того как что-то сломалось, а не заранее. Я веду поддержку десятка проектов на разных стеках, от Tilda-лендингов с оплатой через Т‑Банк до Telegram-ботов на aiogram и связок с n8n, и разница между вменяемым подрядчиком и человеком, который просто отвечает на тикеты, видна уже в первый месяц работы.
Что реально входит в сопровождение сайта
Под сопровождением каждый понимает своё. Для одного это «если сайт упал, кто-то придёт и поднимет», для другого - полноценный список регулярных работ. На практике в услугу сопровождения сайта стоит закладывать:
- мониторинг доступности и скорости, чтобы узнать о падении раньше клиентов
- обновление CMS, плагинов и библиотек с проверкой, что после обновления ничего не отвалилось
- устранение ошибок в интеграциях: платёжные шлюзы, CRM, службы доставки
- доработку и починку кастомных скриптов
- регулярные бэкапы базы и файлов с проверкой, что из них реально можно восстановиться
- консультации по мелким изменениям без отдельного технического задания на каждую правку
Мониторинг на практике - это не просто «сайт открывается или нет». Я слежу за временем ответа сервера, ошибками 500 в логах, статусом фоновых задач вроде отправки заказов в CRM и сроком действия SSL-сертификата. Часть таких сбоев незаметна для посетителя сайта: заказ формально проходит, а уведомление менеджеру в Telegram не приходит из-за упавшего бота, и о проблеме узнают только когда клиент сам звонит и спрашивает, почему никто не перезвонил.
Пример из практики: интернет-магазин на WooCommerce с эквайрингом Т‑Банка. Банк обновил протокол на своей стороне, и старая версия плагина перестала принимать платежи с части карт. Без сопровождения владелец магазина заметил бы это по падению выручки через неделю, а с постоянным подрядчиком проблему находят по логам ошибок раньше, чем до первого клиента, который не смог оплатить заказ.
Похожая история со скриптами на Tilda. Зоны доставки на карте, расчёт налога и НДС, ограничение промокодов по категориям - это кастомный JavaScript, который живёт поверх конструктора и ломается при обновлении редактора. У меня в библиотеке уже есть проверенные модули под такие задачи, и в сопровождении дешевле поставить готовый скрипт, чем каждый раз чинить самописный кусок кода с нуля.
То же самое с ботами на aiogram: Telegram периодически меняет поведение API и лимиты, и бот, который никто не трогает полгода, рано или поздно начинает падать на ровном месте без единой строчки новых изменений в коде.
С n8n добавляется отдельный слой хрупкости: сценарий автоматизации завязан сразу на несколько внешних сервисов, и если у одного из них поменялся формат ответа, вся цепочка встаёт, а разобраться, где именно порвалось, дольше, чем в обычном приложении с одним источником данных.
Что не входит в сопровождение сайта
Сопровождение - это не безлимитная переделка сайта под новые идеи каждую неделю. В стандартный пакет обычно не входит разработка новых разделов, редизайн, написание крупных интеграций с нуля и работа над задачами, которые требуют отдельного технического задания и предварительной оценки. Я стараюсь чётко разделять: правка текста на странице или починка сломанного скрипта - это сопровождение, а новый функционал вроде личного кабинета или интеграции с новой CRM - это отдельный проект со своей сметой и сроками.
Смешивание этих двух типов работ - частая причина конфликтов между заказчиком и подрядчиком: заказчик ждёт, что абонентская плата покрывает любые доработки, подрядчик воспринимает крупную задачу как повод для отдельного счёта. Проговорить границы стоит на берегу, желательно прямо в договоре или хотя бы в переписке, чтобы не спорить об этом в разгар работы над сайтом.
Если заранее понятно, что сайт ждёт крупная переделка - смена платформы, новый дизайн, миграция с Tilda на самописное решение - разумнее сначала закрыть этот проект отдельным контрактом, а уже потом переводить обновлённый сайт на регулярное сопровождение.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Штатный специалист, фрилансер-универсал или подрядчик на аутсорсе
Тут обычно есть три варианта, и у каждого свои плюсы и свои дыры.
| Вариант | Плюсы | Минусы |
|---|---|---|
| Штатный сотрудник | Всегда на связи, знает бизнес и историю сайта изнутри | Дорого держать ради задач на несколько часов в неделю, простаивает между инцидентами |
| Фрилансер-универсал | Дёшево на старте, гибкий график, берётся почти за всё | Пропадает в разгар проблемы, нет обязательств по срокам реакции |
| Подрядчик на сопровождении | Фиксированная зона ответственности, договорённости по срокам реакции | Качество сильно разнится, выбирать нужно вдумчиво |
Для интернет-магазина с оплатой и доставкой я обычно рекомендую вариант с подрядчиком на аутсорсе: разовые доработки не оправдывают ставку штатного разработчика, а фрилансер без обязательств по срокам реакции - слишком большой риск для рабочего канала продаж.
На чём нельзя экономить при выборе подрядчика по обслуживанию сайта
Скорость реакции на инциденты стоит зафиксировать заранее, а не выяснять в момент, когда сайт уже лежит: сколько часов до первого ответа и сколько до фактического решения проблемы.
Бэкап перед любым вмешательством в рабочий сайт - обязательное правило, а не формальность для галочки. Я видел, как обновление плагина без предварительного бэкапа превращало часовую задачу в трёхдневное восстановление каталога товаров.
Доступы стоит выдавать по ролям, а не одной общей учёткой с правами администратора: отдельный логин для подрядчика, ограниченный нужными разделами, снимает половину рисков при смене исполнителя в будущем.
Фиксация изменений - что, когда и зачем поменяли - экономит часы на следующем инциденте, потому что новый человек в проекте сразу видит историю правок, а не гадает, откуда взялся кусок кода в шаблоне.
Тестовая среда для проверки изменений перед выкладкой на боевой сайт нужна даже для небольших проектов: правка, которая ломает страницу оплаты, обходится дороже, чем час на настройку копии сайта для тестов.
Смена подрядчика без документации на руках - отдельная головная боль: если предыдущий исполнитель не оставил список доступов и описание нестандартных решений, новому человеку приходится восстанавливать эту картину по крупицам, а заказчик платит за часы, потраченные на разбор чужого кода вместо реальной работы. Поэтому в договор стоит включать пункт о передаче документации и доступов при завершении сотрудничества, кто бы ни был инициатором разрыва.
Сколько стоит техническая поддержка сайта
На рынке услуга сопровождения сайта стоит по-разному: у фрилансеров на биржах ставки начинаются от 5 000-10 000 ₽ в месяц за минимальный набор работ, в студиях за похожий пакет просят от 30 000-60 000 ₽ и выше в зависимости от объёма сайта и условий по срокам реакции. Разброс такой большой, потому что под одной и той же формулировкой скрывается разный набор работ и разная зона ответственности.
| Тип сайта | Что обычно входит | Моя цена |
|---|---|---|
| Лендинг или сайт на Tilda без сложных интеграций | Мониторинг, мелкие правки, починка скриптов | от 15 000 ₽/мес |
| Интернет-магазин с эквайрингом и доставкой | Контроль оплат, интеграций с СДЭК и CRM | от 15 000 ₽/мес, дороже при сложных интеграциях |
| Веб-сервис или SaaS на React или Vue | Мониторинг API, серверной части, деплоев | от 15 000 ₽/мес, ставка обсуждается по нагрузке |
У меня техподдержка начинается от 15 000 ₽ в месяц - в неё входит мониторинг, устранение ошибок и небольшие правки без отдельного согласования сметы на каждую мелочь. Если сайт держится на кастомных интеграциях - эквайринг, CRM, склад, доставка через СДЭК - ставка растёт, потому что растёт и цена ошибки в случае сбоя.
Цена меняется в зависимости от того, сколько у сайта точек отказа: чем больше внешних сервисов завязано на сайт - эквайринг, служба доставки, рассылки, CRM - тем больше мест, где что-то может сломаться, и тем внимательнее приходится следить за логами. На фиксированную ставку также влияет договорённое время реакции: готовность отвечать в течение часа в выходной день стоит дороже, чем реакция на следующий рабочий день.
Как проверить подрядчика перед тем как отдать сайт в сопровождение
Попросите провести короткий аудит текущего состояния сайта перед стартом работ: по тому, что и как подрядчик находит, видно уровень его внимательности к деталям.
Задайте тестовый вопрос вне рабочего времени и посмотрите на реальную скорость и качество ответа, а не на обещания в договоре.
Спросите про случай, когда что-то пошло не так на прошлом проекте, и как это исправляли: честный ответ с деталями говорит о подрядчике больше, чем список довольных клиентов без подробностей.
Уточните заранее, что происходит при инциденте вне оговорённых часов работы: кто-то отвечает по экстренному каналу или всё ждёт до утра следующего дня.
Полезно взять пробный месяц перед долгосрочным договором: за это время видно, как подрядчик ведёт переписку, насколько подробно объясняет сделанные правки и укладывается ли в заявленные сроки реакции. Если после пробного периода остаются вопросы к качеству связи или прозрачности отчётности, дешевле сменить исполнителя сейчас, чем через полгода разбираться с сайтом, доведённым до состояния чёрного ящика.
Частые вопросы
Сколько времени занимает подключение подрядчика к сопровождению сайта
Обычно от одного до трёх дней уходит на передачу доступов и знакомство с проектом, плюс несколько дней на первичный аудит кода и интеграций. Для сайта с десятком кастомных скриптов и внешних сервисов аудит может растянуться до недели, зато после него понятно, где слабые места и что чинить в первую очередь.
Что делать, если сайт уже сломан и нет никакой поддержки
Сначала зафиксировать масштаб проблемы: что именно не работает, с какого момента и что менялось на сайте перед этим. Дальше нужен бэкап текущего состояния, даже нерабочего, чтобы не потерять данные при попытках чинить. После этого имеет смысл обращаться за разовой доработкой, а решение о постоянном сопровождении принимать уже после того, как сайт снова заработает.
Можно ли сопровождать сайт без доступа к исходному коду
Нет, для нормальной работы подрядчику нужен как минимум доступ на чтение к коду, базе и логам ошибок. Без этого любая диагностика превращается в гадание по скриншотам, а правки приходится вносить вслепую через административную панель, что увеличивает риск новых ошибок.
Стоит ли переходить на сопровождение, если сайт почти не меняется
Даже статичный сайт зависит от внешних сервисов: хостинга, платёжного шлюза, служб доставки, сертификатов и обновлений CMS. Если на сайте есть оплата или интеграции, минимальное сопровождение оправдано хотя бы ради мониторинга и своевременного реагирования на изменения на стороне подрядчиков, а не только на стороне самого сайта.