Гарантийный период после запуска сайта: что должен исправлять подрядчик

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

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

Что такое гарантия на сайт после запуска

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

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

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

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

Какой срок гарантийного периода считается разумным

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

Для лендинга с несколькими формами и подключённой аналитикой обычно достаточно 30-60 дней, если заказчик быстро принимает результат и сразу проверяет основные сценарии. Для корпоративного сайта с каталогом, личным кабинетом или обменом данными с внешними системами разумнее обсуждать 3-6 месяцев. Интернет-магазину может потребоваться более длительный период наблюдения, поскольку часть ошибок проявляется только при заказе, оплате, возврате или работе с остатками.

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

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

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

Ошибки в программном коде и логике работы

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

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

Проблемы с отображением страниц

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

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

Неисправности форм и уведомлений

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

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

Ошибки в согласованных интеграциях

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

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

Нарушение согласованной структуры и контента

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

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

Что не входит в гарантийные обязательства

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

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

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

Граница между ошибкой и доработкой

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

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

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

Как оформить гарантийное обращение

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

1. Укажите адрес страницы или раздел в административной панели.
2. Опишите последовательность действий, после которой возникает ошибка.
3. Напишите, что должно происходить и что происходит фактически.
4. Приложите снимок экрана или короткую запись экрана, если проблема визуальная.
5. Укажите устройство, браузер и время возникновения ошибки.
6. Отдельно сообщите, были ли перед этим изменения на сайте, сервере или во внешнем сервисе.

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

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

Какие сроки реакции закрепить в договоре

Срок реакции и срок исправления, разные показатели. Реакция означает, что подрядчик увидел обращение, назначил ответственного и дал первичную оценку. Исправление означает, что проблема устранена и результат проверен.

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

Что проверить перед подписанием акта

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

Минимальный список проверки

• Открываются главная страница, страницы услуг, контактов и все согласованные разделы.
• Работают меню, кнопки, ссылки, поиск и переходы между страницами.
• Формы принимают корректные данные и показывают понятное сообщение об успехе или ошибке.
• Заявки приходят ответственным сотрудникам и не теряются в почте или CRM.
• Страницы нормально отображаются на телефоне, планшете и компьютере.
• Администратор может редактировать обещанные поля и материалы.
• Подключённые системы получают данные в нужном формате.
• Счётчики аналитики фиксируют согласованные события и отправку форм.
• Пользователи с разными ролями получают только предусмотренный доступ.
• В адресах страниц, меню и служебных сообщениях нет тестовых данных.

Проверять нужно не только внешний вид, но и результат действия. Например, недостаточно нажать кнопку «Отправить». Нужно убедиться, что заявка появилась в нужном разделе, уведомление дошло, а пользователю показалось корректное сообщение.

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

Типичные ошибки заказчиков и подрядчиков

Устные обещания вместо условий договора

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

Смешение гарантии и технической поддержки

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

Отсутствие списка исключений

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

Нет резервного способа связи

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

Заказчик ждёт исправления без проверки

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

Подрядчик называет любую новую задачу багом

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

Как защитить интересы бизнеса в договоре

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

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

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

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

Сколько стоит исправление после окончания гарантии

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

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

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

Частые вопросы

Когда начинается гарантийный период?

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

Должен ли подрядчик исправлять ошибку, которую нашли после приёмки?

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

Что делать, если подрядчик считает проблему новой задачей?

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

Распространяется ли гарантия на ошибки в поисковом продвижении?

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

Можно ли требовать гарантию, если сайт передали без исходных доступов?

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

Нужно ли оплачивать исправление сайта после самостоятельных изменений?

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

Что делать: короткий план

1. До старта проекта включите в договор срок гарантии, правила отсчёта и список исключений.
2. Свяжите гарантийные обязательства с техническим заданием, макетами и перечнем интеграций.
3. Зафиксируйте сроки реакции и исправления для критичных и обычных неисправностей.
4. Перед приёмкой пройдите ключевые сценарии на компьютере и телефоне, включая отправку реальных тестовых заявок.
5. Сохраните доступы, исходные файлы, резервную версию и инструкцию по администрированию.
6. Подавайте обращение с адресом страницы, шагами воспроизведения, ожидаемым результатом и снимком экрана.
7. Проверяйте исправление по исходному сценарию и закрывайте задачу только после подтверждения результата.
8. После окончания гарантии заранее согласуйте формат технической поддержки и оценки новых доработок.

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