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

Техподдержка, сопровождение и доработка сайта: в чём разница

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

Меня зовут Богдан Квитка, я руковожу студией GoodFellazz. Мы разрабатываем сайты на Laravel и Vue для производителей и B2B-компаний и после запуска остаёмся с клиентами на поддержке. Большая часть нашей работы с постоянными клиентами идёт именно через сопровождение: сайт живёт годами, и всё это время его кто-то обновляет, чинит и достраивает.

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

Услуга	Что это	Как обычно оплачивается
Техническая поддержка	Сайт работает, обновлён, защищён, ошибки исправляются	Абонемент, ежемесячно
Сопровождение	Поддержка плюс постепенное развитие сайта	Абонемент или абонемент с доработками
Доработка	Разовая задача с конкретным результатом	По часам или по смете

Поддержка сохраняет работоспособность. Сопровождение развивает сайт. Доработка создаёт новый результат.

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

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

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

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

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

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

Безопасность. Контроль доступов, обновление уязвимых зависимостей, реакция на подозрительную активность. Ориентиром по типовым угрозам служит список OWASP Top 10: инъекции, ошибки контроля доступа, уязвимые компоненты.

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

Обмены и интеграции. Если сайт получает товары, цены и остатки из 1С, обмен нужно контролировать. Выгрузка может остановиться из-за изменений в учётной системе, и сайт неделю показывает старые остатки. Как устроен такой обмен, мы разбирали в статье про интеграцию сайта с 1С.

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

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

Доработка сайта: какие задачи выходят за рамки поддержки

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

Типовые доработки сайта, с которыми к нам приходят клиенты:

• новый раздел или шаблон страницы;
• доработка каталога: фильтры, сортировки, сравнение товаров;
• доработка интернет-магазина: оформление заказа, способы оплаты и доставки;
• интеграции: 1С, CRM, службы доставки, платёжные сервисы, маркетплейсы;
• личный кабинет клиента или дилера;
• ускорение сайта и оптимизация тяжёлых страниц;
• модернизация дизайна отдельных экранов;
• техническая база для SEO: метатеги, структура URL, микроразметка.

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

Граница между поддержкой и доработкой на практике размыта. Поправить текст в форме - поддержка. Добавить в форму новое поле, которое уходит в CRM, - уже маленькая доработка. Чтобы не спорить о каждой задаче, у нас часы пакета расходуются на любые работы по сайту, а всё, что выходит за объём пакета, оплачивается отдельно.

Как устроен абонемент на техподдержку: пакеты часов

Техподдержку мы оформляем абонементом с пакетом часов на месяц. Пакеты три: 20, 30 и 40 часов. Клиент выбирает объём под свой сайт, и в течение месяца мы расходуем эти часы на задачи по нему.

Условия абонемента:

1. Пакет покупается на месяц: 20, 30 или 40 часов.
2. Чем больше пакет, тем ниже стоимость часа.
3. Неиспользованные часы техподдержки сгорают в конце месяца и на следующий не переносятся.
4. Доработки сверх объёма пакета оплачиваются отдельно.

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

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

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

Базовая ставка на доработки у нас 3500 рублей за час. В пакете техподдержки час дешевле: от 3000 до 3400 рублей в зависимости от объёма.

Объём	Стоимость часа	Стоимость пакета в месяц
Без пакета, разовые доработки	3500 ₽	по факту часов
Пакет 20 часов	3400 ₽	68 000 ₽
Пакет 30 часов	3200 ₽	96 000 ₽
Пакет 40 часов	3000 ₽	120 000 ₽
Больше 40 часов в месяц	3000 ₽	по согласованному объёму

Разница в ставке на длинной дистанции заметна. Сорок часов по 3000 рублей обходятся на 20 000 рублей в месяц дешевле тех же часов по базовой ставке 3500. За год это 240 000 рублей.

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

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

Абонемент или почасовая оплата: расчёт на примере

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

Вариант	Расчёт	Итого в месяц
Без пакета	25 ч × 3500 ₽	87 500 ₽
Пакет 20 ч + доработки сверх	68 000 ₽ + 5 ч × 3500 ₽	85 500 ₽
Пакет 30 ч	30 ч × 3200 ₽	96 000 ₽, из них 5 ч сгорят

На таком объёме выгоднее пакет 20 часов с доплатой за превышение. Пакет 30 часов даёт более низкую ставку, но пять часов в месяц остаются неиспользованными. Если же объём задач стабильно держится у 30 часов, пакет 30 часов становится дешевле: 96 000 рублей против 105 000 по базовой ставке.

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

Поддержка корпоративного сайта, магазина и сервиса: на что уходят часы

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

Тип сайта	Куда уходят часы	Что критично
Корпоративный сайт	Обновления, копии, мониторинг, правки контента, новые блоки для маркетинга	Работа форм заявок, скорость, конструктор страниц
Интернет-магазин	Обмен с 1С, цены и остатки, акции, оплата и доставка, скорость каталога	Совпадение данных с учётной системой, оформление заказа
Сервис с бронированием или личным кабинетом	Логика бронирования и расчётов, доступы пользователей, сезонная нагрузка	Доступность в пик, корректность расчётов

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

Интернет-магазин. Здесь больше ситуативных задач. Остановился обмен, служба доставки поменяла условия API, нужно срочно запустить акцию к выходным. Чем больше каталог и чем больше складов и типов цен, тем больше внимания требует обмен данными. У магазинов с оптовыми и розничными покупателями к этому добавляется проверка цен для разных групп клиентов.

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

Примеры сайтов на нашей поддержке

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

Hermes Industries: корпоративный сайт производственной компании

hermes-industries.ru - корпоративный сайт производителя с конструктором страниц на базе Grapes.js. Маркетинг клиента собирает посадочные страницы сам, без программиста.

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

ЗАО «СМС»: интернет-магазин запчастей

zao-sms.ru - магазин запчастей на Laravel с каталогом около 40 000 товаров и обменом с 1С по нескольким складам.

Фокус поддержки: обмен с 1С по складам и контроль расхождения цен и остатков между сайтом и учётной системой на 40 000 позициях. Как проект устроен, мы описали в статье про интернет-магазин запчастей.

Z1 Light: интернет-магазин светотехники

технической поддержки, и мы предложим пакет под ваш объём задач.

Признаки, что сайту нужна техническая поддержка

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

Заявки приходят реже без видимой причины. Трафик на месте, а заявок стало меньше. Одна из частых причин - форма перестала отправлять письма или передавать данные в CRM после изменений на сервере или в почтовом сервисе. Посетитель видит «спасибо, заявка отправлена», а до менеджера она не доходит. Проверяется просто: отправьте заявку с сайта сами и посмотрите, куда она пришла.

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

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

Хостинг присылает предупреждения. Письма о том, что версия PHP устарела и будет отключена, что заканчивается место на диске или что сертификат скоро истекает. Такие письма легко пропустить, а последствия наступают в конкретную дату.

Никто не знает, где резервные копии. Если на вопрос «когда последний раз делали копию и где она лежит» нет быстрого ответа, сайт фактически работает без страховки.

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

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

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

Почему сайт на фреймворке нельзя оставить без обновлений

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

У Laravel политика опубликована в официальной документации Laravel: исправления ошибок для каждой версии выходят 18 месяцев, исправления безопасности - два года. Laravel 11 перестал получать исправления безопасности 12 марта 2026 года. У Laravel 12 исправления ошибок закончились 13 августа 2026 года, исправления безопасности будут выходить до 24 февраля 2027 года.

С PHP похожая картина. По данным php.net, каждая ветка языка два года получает полную поддержку и ещё два года только критические исправления безопасности. Для PHP 8.2 исправления безопасности заканчиваются 31 декабря 2026 года.

Компонент	Сколько поддерживается версия	Пример
Laravel	18 месяцев исправления ошибок, 2 года исправления безопасности	Laravel 12: безопасность до 24.02.2027
PHP	2 года полная поддержка, ещё 2 года только безопасность	PHP 8.2: безопасность до 31.12.2026

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

Точную оценку обновления по конкретному сайту без аудита дать нельзя: объём работ зависит от того, сколько сторонних библиотек в проекте и насколько код отходит от стандартной структуры Laravel. Как устроен аудит, описано ниже.

Как передать сайт на поддержку другой команде

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

1. Собрать доступы. Сервер, репозиторий, домен и DNS, админка, почта, аналитика, интеграции: 1С, CRM, платёжный сервис, доставка. Владельцем аккаунтов лучше быть компании.
2. Получить актуальный код. Код в репозитории должен совпадать с тем, что работает на сервере. Правки, внесённые прямо на сервере, при первом обновлении теряются.
3. Провести аудит кода и инфраструктуры (подробнее в следующем разделе).
4. Настроить базовую страховку. Резервные копии с проверкой восстановления и мониторинг - в первые недели, до любых доработок.
5. Составить список задач и разделить его на срочное, плановое и развитие.
6. Выбрать пакет по итогам первого месяца. В первый месяц задач больше из-за аудита и первоочередных исправлений, регулярный объём виден со второго-третьего месяца.

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

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

Аудит сайта перед приёмом на поддержку

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

Что проверяем:

• версии Laravel, PHP, Vue/Nuxt и сторонних библиотек, сроки их поддержки;
• структуру кода и насколько она отходит от стандартной структуры фреймворка;
• настройки сервера и окружения, способ выкладки обновлений;
• резервные копии: есть ли, где хранятся, восстанавливаются ли;
• обмены и интеграции: 1С, CRM, оплата, доставка;
• совпадение кода в репозитории с кодом на сервере;
• очевидные проблемы безопасности и производительности.

Детальный технический аудит платный и занимает в среднем от 10 до 20 часов, в зависимости от размера проекта и состояния кода. По его итогам понятно состояние проекта, основные риски и объём первоочередных работ, а значит и подходящий пакет часов.

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

Что зафиксировать в договоре на сопровождение сайта

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

• Объём часов и период. Сколько часов входит в месяц и что происходит с неиспользованными. У нас часы техподдержки сгорают, у других подрядчиков могут переноситься. Главное, чтобы условие было записано.
• Ставка на работы сверх пакета. Сколько стоит час за пределами абонемента и как такие работы согласуются.
• Порядок постановки задач. Через какой канал ставятся задачи, кто со стороны клиента их согласует.
• Сроки реакции. Как быстро исполнитель берёт в работу срочную задачу, например падение сайта или остановку оплаты, и как быстро обычную. У нас срок реакции зависит от формата сопровождения и критичности инцидента. Для аварий, которые блокируют заявки, оплату или обмен с 1С, порядок действий и время реакции фиксируем в договоре до старта работ.
• Отчётность. Как клиент видит, на что потрачены часы: список задач с затраченным временем.
• Доступы и код. У кого хранятся доступы к серверу, репозиторию и админке, кому принадлежит код.
• Резервные копии. Как часто делаются, где хранятся, кто и как проверяет восстановление.
• Порядок завершения. Как передаются доступы, код и документация, если клиент решит сменить подрядчика.

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

Частые ошибки при выборе техподдержки

Выбирают по самому низкому тарифу. Дешёвая поддержка обычно рассчитана на типовые CMS и покрывает копии и мелкие правки. Когда на сайте на фреймворке ломается обмен с 1С, выясняется, что в тариф это не входит. Программиста, который знает проект, у подрядчика тоже нет.

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

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

Не проверяют резервные копии. Копии вроде бы делаются, но из них никто ни разу не восстанавливался. В день сбоя оказывается, что копия неполная или устарела на месяц.

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

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

Чек-лист: как выбрать подрядчика на сопровождение

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

1. Выясните, работает ли подрядчик с вашей технологией: фреймворком, CMS, версией PHP.
2. Попросите показать сайты, которые подрядчик сейчас поддерживает.
3. Если сайт делала другая команда, закажите аудит кода до начала поддержки.
4. Посчитайте средний объём задач за последние три-шесть месяцев.
5. Выберите пакет по среднему объёму задач.
6. Уточните ставку на работы сверх пакета.
7. Уточните, что происходит с неиспользованными часами.
8. Зафиксируйте в договоре сроки реакции на срочные и обычные задачи.
9. Договоритесь о формате отчёта по потраченным часам.
10. Проверьте, где хранятся резервные копии, и попросите тестовое восстановление.
11. Держите у себя доступы к серверу, репозиторию, домену и админке.
12. Узнайте, на каких версиях фреймворка и PHP работает сайт и когда у них заканчивается поддержка.
13. Запишите в договор порядок передачи кода и доступов при завершении работы.
14. Раз в квартал закладывайте часы на одну-две доработки, которые развивают сайт.

FAQ

С чего начать сопровождение сайта

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

Три шага, которые можно сделать самостоятельно:

1. Узнайте, на каких версиях фреймворка и PHP работает ваш сайт, и сверьте их со сроками поддержки по таблице выше.
2. Проверьте, у кого хранятся доступы к серверу, репозиторию и домену, и когда последний раз восстанавливали сайт из резервной копии.
3. Выпишите задачи по сайту за последние месяцы и прикиньте средний объём в часах. По нему выбирается пакет.

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