Кратко: Гарантия подрядчика — это письменное обязательство бесплатно устранить недостатки, которые появились по его вине уже после сдачи сайта. На практике это несколько разных вещей: гарантия на код и вёрстку (обычно 6–12 месяцев), гарантия на корректную работу функционала и интеграций и техническая поддержка после запуска, которую чаще всего оплачивают отдельно. Все условия должны быть зафиксированы в договоре: срок, что именно покрывается, что считается недостатком, сроки реакции на обращение и порядок связи. Гарантия не покрывает правки по вашему желанию, изменения после вмешательства третьих лиц, последствия обновлений, установленных вами, и ущерб от взлома при слабых паролях. Ниже — какие гарантии бывают, что закрепить в договоре, на что смотреть до подписания и что делать, если подрядчик отказывается давать гарантии.
Почему вопрос гарантий стоит решать до оплаты
Заказчик сайта почти всегда думает о гарантиях неправильно: как о приятном бонусе, который «наверное, есть». На деле это один из главных пунктов, который определяет, чем закончится проект. Сайт — живая система: после запуска обнаруживаются мелкие ошибки в вёрстке, конфликты плагинов, некорректно работающая форма, письма, которые не доходят, или блок, который разъезжается на новом смартфоне. Всё это не значит, что подрядчик плохой. Это нормальная жизнь любого веб-проекта, и вопрос только в том, кто и за чей счёт это будет исправлять.
Если гарантия прописана, вы открываете чат, описываете проблему и получаете исправление. Если гарантии нет, каждый такой случай превращается в отдельный коммерческий разговор: подрядчик выставляет счёт, вы торгуетесь, теряете время, а иногда просто платите дважды за одну и ту же работу. Особенно неприятно, когда проблема проявляется через месяц после сдачи, когда предоплата давно закрыта, а проект кажется «завершённым».
Второй момент — гарантия напрямую влияет на стоимость. Иногда подрядчик готов существенно снизить цену, если заказчик отказывается от гарантийных обязательств и подписывает закрывающие документы без права на бесплатные исправления. Такая экономия почти всегда обходится дороже: одна правка у другого специалиста стоит от 3 000 до 15 000 рублей, а сложные случаи — заметно больше. Именно поэтому сравнение подрядчиков нужно начинать не с цифры «за разработку», а с полного пакета условий, в котором гарантия занимает не последнее место. Как сопоставлять предложения, подробно разбирает материал про сколько стоит разработка сайта в 2026 году.
Какие гарантии даёт подрядчик: четыре разных вида
Главная путаница в том, что словом «гарантия» называют четыре разных вещи. Если вы не разграничиваете их, подрядчик может говорить «гарантия есть», а в реальности иметь в виду лишь одну из них. Вот эти виды.
1. Гарантия на вёрстку и код. Это обязательство исправить технические дефекты, допущенные специалистами: разъезжающуюся вёрстку, неверно работающие скрипты, несоответствие макету, ошибки в шаблонах. Обычно действует 6–12 месяцев с момента сдачи. Это базовая и самая ожидаемая гарантия.
2. Гарантия на функционал и интеграции. Касается того, что сайт делает: корзина, расчёт доставки, приём платежей, отправка писем, выгрузки в CRM, связка с картами и каталогами. Здесь важно понимать, что часть работы зависит не от кода, а от внешних сервисов, и гарантия ограничена рамками интеграции.
3. Техническая поддержка. Это уже не гарантия в строгом смысле, а договорённость о содержании сайта: обновления ядра и плагинов, резервные копии, мониторинг доступности, мелкие правки, консультации. Почти всегда она оформляется отдельным договором и оплачивается ежемесячно. Путать поддержку с бесплатной гарантией нельзя: подрядчик имеет право отказать в бесплатной правке, которая не является дефектом, и предложить её в рамках поддержки. Что входит в такую работу и сколько она стоит, объясняет статья про заказать поддержку сайта.
4. Гарантии по срокам и по исходным данным. Некоторые подрядчики отдельно фиксируют обязательства по срокам сдачи и по передаче исходников (файлы макетов, доступы, лицензии, исходный код). Это не «гарантия» в юридическом смысле, но именно эти пункты чаще всего становятся предметом спора после запуска.
Полезно также понимать разницу между гарантией проекта целиком и гарантией на отдельные работы. Если вы позже закажете доработку у другого исполнителя, гарантия на основную часть обычно сохраняется, но гарантия на изменённый участок уже не распространяется ни на кого. Как в таких случаях делить ответственность, разбирает материал про доработку сайта у программиста.
Что должно быть в договоре: обязательные пункты
Гарантия, о которой договорились на словах, не существует. Спустя месяц вы не сможете доказать, что она вообще обсуждалась. Всё, что важно, должно быть в тексте договора или в отдельном приложении к нему. Ниже — минимальный набор пунктов, которые стоит проверить перед подписанием.
| Пункт договора | Что должно быть написано | Почему это важно |
|---|---|---|
| Гарантийный срок | Конкретный период с даты подписания акта: например, 12 месяцев на вёрстку и 6 месяцев на интеграции | Без точной даты невозможно понять, действует гарантия или закончилась |
| Что считается недостатком | Определение: несоответствие техническому заданию, макету или заявленному функционалу | Защищает от спора «это баг» против «это новое пожелание» |
| Что покрывается и что нет | Список гарантийных случаев и отдельный список исключений | Позволяет заранее увидеть, за что придётся платить отдельно |
| Порядок обращения | Куда писать, в каком виде, что приложить (скриншот, описание, ссылка) | Ускоряет исправления и создаёт историю обращений |
| Сроки реакции и устранения | Например: подтверждение в течение рабочего дня, критичные ошибки — исправление до 3 дней | Иначе формальная гарантия может «растянуться» на месяцы |
| Передача исходников и доступов | Все доступы, лицензии, исходные файлы и код передаются заказчику | Без этого вы не сможете привлечь другого специалиста |
| Условия расторжения и ответственность | Что происходит при нарушении сроков или отказе устранять недостатки | Даёт реальный рычаг влияния, а не только формальную запись |
| Гарантия после сторонних правок | Прямая формулировка: при вмешательстве третьих лиц гарантия на изменённый участок прекращается | Это нормальная практика, но её нужно понимать заранее |
Если договор типовой и в нём нет отдельного раздела о гарантиях, попросите приложение или дополнительное соглашение. Нормальный подрядчик не откажется: он и сам заинтересован в том, чтобы условия были понятны обеим сторонам. О том, какие ещё разделы должны быть в документе, подробно рассказывает статья про договор на разработку сайта, а перечень этапов, к которым привязываются гарантийные обязательства, описан в материале про этапы разработки сайта от брифа до запуска.
Гарантийные сроки: сколько длятся и от чего зависят
Единого «правильного» срока не существует, но есть отраслевая практика, на которую можно ориентироваться при обсуждении. Важно понимать логику: чем сложнее и чем более «живой» участок, тем короче гарантия, потому что на него влияет слишком много внешних факторов.
| Что за работа | Обычный гарантийный срок | От чего зависит |
|---|---|---|
| Вёрстка и адаптивность | 6–12 месяцев | Количество шаблонов страниц, поддержка старых браузеров |
| Функционал под техническое задание | 6–12 месяцев | Сложность логики, число сценариев, объём тестирования |
| Интеграции с внешними сервисами | 3–6 месяцев | Изменения на стороне сервиса, смена API, лимиты тарифов |
| Перенос и миграция данных | 1–3 месяца | Объём данных, качество исходной базы, сторонние правки |
| Работы по SEO-настройке при запуске | 1–3 месяца | Индексация, изменения алгоритмов поиска, конкурентная среда |
| Хостинг и настройка сервера | По договору с провайдером | Условия тарифа, ответственность хостера, нагрузка |
Есть простое правило: чем точнее техническое задание, тем дольше и спокойнее действует гарантия. Когда требования описаны расплывчато, любая претензия превращается в спор о том, было ли это обещано. Материал про как составить техническое задание на разработку сайта помогает закрыть именно эту зону риска.
Отдельно стоит уточнить, с какой даты отсчитывается срок. Самый распространённый вариант — с даты подписания акта сдачи-приёмки. Иногда подрядчик считает срок от начала проекта, и это невыгодно заказчику: к моменту запуска часть гарантии уже истечёт. Настаивайте на отсчёте от сдачи. Также полезно уточнить, что срок продлевается, пока идёт устранение недостатка, — иначе возможна ситуация, когда гарантия заканчивается ровно в тот момент, когда ошибку наконец начали исправлять.
Что гарантия не покрывает: типичные исключения
Даже самая честная гарантия не бессрочна и не универсальна. Если подрядчик заранее перечисляет исключения, это признак профессионализма, а не попытка увильнуть. Вот что почти всегда выходит за рамки гарантийных обязательств.
Новые пожелания и изменение требований. Если после сдачи вы решили, что кнопка должна быть другого цвета, добавился новый раздел или изменилась логика оформления заказа, это не недостаток, а новая задача. Она оценивается и оплачивается отдельно.
Правки, сделанные вами или третьими лицами. Как только в код или настройки вмешался другой специалист, подрядчик теряет контроль над проектом и не может отвечать за последствия. Гарантия на изменённый участок прекращается.
Обновления, которые вы установили сами. Обновление плагина или темы может сломать совместимость. Если это сделал подрядчик в рамках поддержки — он отвечает; если вы самостоятельно в один клик — риск на вас. Именно поэтому обновления лучше делать в рамках регламента, о котором рассказывает статья про поддержку и содержание сайта.
Сбои на стороне внешних сервисов. Если платёжный провайдер изменил правила, хостинг переехал на новый сервер или почтовый сервис поменял настройки, это не дефект разработки. Подрядчик может помочь, но уже в рамках платных работ.
Взлом и последствия слабой защиты паролей. Если сайт взломали из-за простого пароля, устаревшего плагина или отсутствия резервных копий, ответственность лежит на владельце. Профилактика взлома — отдельная тема, и ей стоит заниматься заранее.
Внешний вид на устаревших браузерах и устройствах. Обычно гарантия покрывает актуальные версии популярных браузеров и современные мобильные устройства. Поддержка очень старых браузеров и нестандартных сборок почти всегда оговаривается отдельно и оплачивается дополнительно, как и проверка на редких экранах.
Контент, который вы загружаете сами. Огромная картинка, сломанная ссылка, неудачный текст — это не технический дефект. Подрядчик может подсказать, как исправить, но гарантия такие случаи не покрывает. То же касается последствий, которые возникли из-за действий сотрудников или подрядчиков по продвижению сайта.
Бесплатные гарантийные исправления и платная поддержка: где граница
Самая частая причина конфликта после запуска — спор о том, гарантийный это случай или платная доработка. Граница довольно простая: если работа сделана не так, как было зафиксировано в техническом задании и макетах, это недостаток и исправляется бесплатно. Если требование появилось после сдачи или требования не было вовсе, это новая задача.
На практике спорных ситуаций не так много, если техническое задание детальное. Например, форма заявки, которая не отправляет письма, — это дефект. Желание добавить в форму ещё одно поле, которого не было в ТЗ, — это доработка. Кнопка «Купить», которая на телефоне перекрывается другим элементом, — дефект вёрстки. Просьба сделать кнопку ярче — дизайнерская правка.
Чтобы спора не возникало, полезно придерживаться трёх правил. Первое: любые изменения фиксировать письменно, даже если они кажутся мелкими. Второе: вести переписку в одном канале, а не в пяти мессенджерах, — тогда история договорённостей всегда под рукой. Третье: разделять бюджеты на «гарантию» и на «развитие». Гарантия бесплатна, развитие стоит денег, и это нормально. Как выстроить работу так, чтобы правки не превращались в бесконечный проект, помогает понять материал про сроки разработки сайта и про приёмку сайта у подрядчика.
Что говорит закон: права заказчика
Многие заказчики считают, что гарантия — исключительно добрая воля исполнителя. Это не совсем так. Отношения по разработке сайта регулируются договором и нормами гражданского права, а если заказчик — физическое лицо и заказывает работу для личных нужд, в дело вступает законодательство о защите прав потребителей. Практический вывод простой: даже если в договоре гарантия описана коротко, у заказчика есть определённые права, а у исполнителя — обязанность выполнить работу качественно и в согласованный срок.
Что из этого следует для вас. Первое: если недостатки возникли по вине исполнителя, требование об их устранении законно, и отказ не всегда правомерен. Второе: если исполнитель нарушил сроки, у заказчика, как правило, есть право на соразмерное уменьшение цены или на отказ от договора с возвратом средств — конкретика зависит от формулировок и обстоятельств. Третье: важна доказательная база, а именно договор, техническое задание, переписка, скриншоты, акты и даты. Без документов даже обоснованное требование сложно подтвердить.
Именно поэтому грамотное оформление проекта — это не бюрократия, а защита. Если вы фиксируете требования, этапы и приёмку по акту, у вас на руках оказывается всё необходимое. Общие принципы такого оформления разобраны в статьях про договор на разработку сайта и про проверку подрядчика при заказе сайта. Если спор всё же дошёл до конфликта, полезно помнить: письменная претензия с описанием недостатков и требованием их устранить в разумный срок — первый и обязательный шаг, который сам по себе часто решает вопрос.
Отдельно стоит сказать про сайты, которые уже живут несколько лет. Через год-два после запуска может потребоваться редизайн сайта: он нужен не потому, что подрядчик плохо сделал свою работу, а потому что изменились задачи бизнеса, требования поиска и привычки пользователей. Такие изменения планируются отдельно и не относятся к гарантии.
Что делать, если подрядчик отказывает в гарантии
Отказ бывает разным, и важно отличать обоснованный от формального. Сначала разберитесь в причинах: возможно, случай действительно попадает под исключения, о которых вы просто забыли. Но если речь о реальном дефекте работы, действовать стоит последовательно.
Шаг 1. Проверьте документы. Найдите договор и техническое задание, посмотрите формулировки о гарантии, сроках и порядке приёмки. Часто именно там уже есть ответ, и достаточно сослаться на конкретный пункт.
Шаг 2. Напишите письменную претензию. В ней должно быть: описание недостатка, дата обнаружения, ссылка на пункт ТЗ или договора, требование устранить недостаток и разумный срок. Приложите скриншоты и видео, если проблема визуальная или сценарий сложный. Отправляйте так, чтобы у вас осталось подтверждение получения: по электронной почте с уведомлением или заказным письмом.
Шаг 3. Зафиксируйте состояние сайта. Сделайте резервную копию, сохраните текущие версии файлов и списки плагинов, сделайте скриншоты проблемы. Это пригодится и для независимой оценки, и просто для спокойствия.
Шаг 4. Дайте шанс решить миром. Большинство конфликтов заканчиваются на этом этапе: подрядчику проще исправить ошибку, чем портить репутацию. Если речь о небольшой сумме, иногда выгоднее договориться о компромиссе, чем втягиваться в долгий спор.
Шаг 5. Привлекайте третью сторону. Если диалог не работает, вариантов немного: независимая техническая экспертиза, обращение к юристу, претензия и, при необходимости, суд. Это долго и требует затрат, поэтому вложения должны быть соразмерны ущербу. Зато качественно оформленные документы резко повышают шансы на положительный исход.
И главное — не доводите до этой ситуации. Большая часть проблем решается на старте: договором, детальным ТЗ и понятной процедурой приёмки. Материал про чек-лист проверки подрядчика помогает отсеять исполнителей, которые избегают любых обязательств ещё на этапе обсуждения.
Как проверить гарантии до подписания: чек-лист
Удобнее всего смотреть на гарантии вместе с остальными условиями, сравнивая исполнителей по одинаковым критериям. Ниже — короткий чек-лист и сравнение трёх распространённых вариантов. Конкретные цифры у всех разные, но логика рисков одинаковая.
| Критерий | Фрилансер | Небольшая студия | Крупное агентство |
|---|---|---|---|
| Гарантия на код и вёрстку | Часто на словах, редко в договоре | Прописана в договоре, 6–12 месяцев | Стандартный регламент, 12 месяцев |
| Сроки реакции на обращение | Зависят от загрузки, не фиксируются | Обычно 1 рабочий день | Регламент с приоритетами и SLA |
| Стоимость проекта | Ниже | Средняя | Выше |
| Риск исчезновения исполнителя | Высокий | Средний | Низкий |
Чек-лист вопросов, которые стоит задать до подписания договора:
1. Какой гарантийный срок и с какой даты он отсчитывается? 2. Что именно считается недостатком и что относится к исключениям? 3. Как и куда обращаться при проблеме, какой срок реакции? 4. Передаются ли исходники, доступы и лицензии? 5. Оформлена ли поддержка после запуска и что в неё входит? 6. Есть ли примеры похожих проектов и можно ли связаться с их владельцами?
Если на эти вопросы отвечают уверенно и письменно — риск минимален. Если подрядчик уходит от конкретики, ссылается на «всегда всё решаем» и не хочет закреплять сроки — это сигнал отложить подписание. Оценить адекватность бюджета помогает статья про цены на разработку, а понять, какой тип сайта вам вообще нужен, — материал про сайт для бизнеса. Если вы пока выбираете между проектом под ключ и отдельными работами, полезно сравнить варианты в статье про разработку сайта под ключ.
Частые вопросы о гарантиях подрядчика
Какой срок гарантии считается нормальным при разработке сайта?
Для вёрстки и функционала нормальной практикой считаются 6–12 месяцев с даты подписания акта сдачи-приёмки. Для интеграций с внешними сервисами срок обычно короче — 3–6 месяцев, потому что на них влияют изменения на стороне сервиса. Если подрядчик предлагает всего 1 месяц или не даёт гарантию вовсе, это повод либо отказаться, либо настаивать на письменных условиях.
Что не покрывает гарантия подрядчика?
Новые пожелания и изменение требований после сдачи, правки, сделанные заказчиком или третьими лицами, последствия самостоятельно установленных обновлений, сбои на стороне внешних сервисов, взлом из-за слабых паролей и устаревших плагинов, внешний вид на устаревших браузерах и контент, загруженный самим заказчиком. Эти случаи либо решаются в рамках платной поддержки, либо остаются зоной ответственности владельца сайта.
Чем гарантия отличается от технической поддержки?
Гарантия — это бесплатное устранение недостатков, допущенных подрядчиком, в течение определённого срока. Поддержка — это регулярная платная работа по содержанию сайта: обновления, резервные копии, мониторинг, мелкие правки, консультации. Гарантия обычно ограничена по времени и по видам работ, а поддержка действует столько, сколько вы её оплачиваете.
Можно ли отказаться от гарантии в обмен на скидку?
Технически можно, но почти всегда невыгодно. Одна правка у стороннего специалиста стоит от 3 000 до 15 000 рублей, а сложные случаи — дороже, и вам придётся ещё найти того, кто согласится разбираться в чужом коде. Скидка редко покрывает хотя бы пару обращений. Если бюджет ограничен, разумнее сократить объём проекта, а не лишать себя гарантийных обязательств.
Что делать, если подрядчик отказывается исправлять недостаток?
Сначала проверьте договор и техническое задание: возможно, случай попадает под исключения. Если это реальный дефект, направьте письменную претензию с описанием проблемы, ссылкой на пункт ТЗ и требованием устранить недостаток в разумный срок, приложите скриншоты или видео. Зафиксируйте состояние сайта резервной копией. Если диалог не помогает, дальше идут независимая экспертиза, обращение к юристу и, при необходимости, суд.
Сохраняется ли гарантия, если сайт дорабатывал другой специалист?
Гарантия на основную часть проекта обычно сохраняется, если изменения её не затронули. Но гарантия на изменённый участок прекращается: подрядчик не может отвечать за код или настройки, в которые вмешался кто-то другой. Поэтому перед обращением к стороннему специалисту стоит письменно согласовать объём работ и убедиться, что он умеет работать с текущей технической базой.
Вывод
Гарантия подрядчика — это не формальность, а рабочий инструмент защиты ваших денег и времени. Разберитесь, о какой именно гарантии идёт речь: на вёрстку и код, на функционал и интеграции или на регулярную поддержку после запуска. Затем проверьте, что все условия закреплены письменно: срок и дата отсчёта, определение недостатка, список исключений, порядок обращения, сроки реакции и передача доступов и исходников.
Помните простое правило: если работа сделана не так, как договорились, — это гарантийный случай и исправляется бесплатно. Если требование появилось после сдачи — это новая задача и она оценивается отдельно. Большая часть конфликтов возникает не из-за злого умысла, а из-за размытых договорённостей, поэтому детальное техническое задание и понятная приёмка экономят гораздо больше, чем любая скидка.
Если не хочется разбираться в юридических тонкостях самостоятельно, эту работу можно передать одной команде. Мы делаем сайты на WordPress — от структуры и текстов до запуска, поддержки и продвижения — и фиксируем гарантийные обязательства в договоре. Посмотрите услуги разработки и продвижения сайтов, изучите портфолио выполненных проектов и почитайте блог о сайтах и продвижении. Опишите задачу через форму контактов — расскажем, какие гарантии даём, как они оформляются и сколько будет стоить ваш проект.
