Договор на оказание услуг по разработке сайта: образец, ключевые пункты и шаблон

Пошаговый гид по договору на оказание услуг по разработке сайта: ключевые положения, риски, образцы формулировок и чек‑лист для заказчика и исполнителя ✅

Короткий ответ: договор на оказание услуг по разработке сайта должен формально фиксировать предмет работ, состав и формат результата (deliverables), порядок приема‑передачи, сроки и этапы, условия оплаты, ответственность сторон, права на ИС/контент, гарантийные обязательства и порядок внесения изменений. Для проектов, ориентированных на бизнес‑результат, в договоре обязательно предусмотреть требования по SEO‑готовности и передачу прав на базовую оптимизацию/доступы — SEO остаётся долгосрочным каналом, а контекстная реклама — ускорителем.

Что такое договор на оказание услуг по разработке сайта и зачем он нужен

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

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

Стороны договора и базовые понятия

В договоре указываются:

Заказчик: юридическое лицо или ИП, с контактами и реквизитами.
Исполнитель: агентство или разработчик, с реквизитами.
Определения ключевых терминов: «сайт», «сдача», «акты приёмки», «исходные материалы», «внедрение», «поддержка», «SEO‑работы» и т.д.

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

Предмет договора и объем работ (SOW)

Раздел «Предмет договора» должен быть максимально конкретен и опираться на приложение «Техническое задание (ТЗ)» или «Scope of Work (SOW)».

Что включать в SOW

Список страниц и их функционала: лендинг/корпоративный/интернет‑магазин, поиск, корзина, личный кабинет.
Модульные решения: формы обратной связи, интеграции с CRM, платёжными системами, сервисами аналитики.
Требования к дизайну: адаптивность, количество макетов, ревизии, авторские права на дизайн.
Требования к безопасности и соответствию законам (например, хранение персональных данных, обработка cookies).
Технические требования: CMS, версии PHP/Node, коды ответов, требования к скорости и SEO‑оптимизации.

Примечание: по опыту, чем детальнее SOW, тем меньше споров и дороже расчёт на старте. Но инвестировать в точное ТЗ выгоднее, чем перекраивать проект по ходу.

Доставляемые результаты (deliverables) и формат передачи

Укажите конкретный перечень артефактов, которые передаются заказчику:

Исходные коды (архив/репозиторий) или доступ к приватному репозиторию.
Готовая сборка на продакшн и/или на тестовом сервере.
Макеты дизайна в исходниках (Figma, Sketch) и экспортах.
Документация: readme, инструкции по деплою, контрольные чек‑листы, инструкции для администратора.
Доступы: FTP, SSH, панель хостинга, домен, аналитика, CRM (если интеграции).

Важно прописать формат и сроки передачи доступов, а также кто несёт ответственность за перенос контента и корректность данных при приёме.

Сроки, этапы, milestone и акты приёмки

Разбейте проект на этапы и опишите критерии приёмки каждого этапа. Для каждого milestone укажите:

Что именно должно быть готово.
Срок исполнения (дата или период).
Критерии проверки и приёмки (тесты, чек‑лист, баг‑лист).
Форма акта приёмки‑сдачи.

Рекомендуемая схема: прототип → дизайн → разработка (бэкенд/фронтенд) → интеграции → тестирование → выкат на прод. Для каждого этапа — подпись акта приёмки. Без подписанного акта считается, что этап не принят.

Оплата: модель, график, аванс и удержания

Стандартные схемы оплаты:

Фиксированная цена за проект с этапным графиком (milestones + акты).
Почасовая оплата по факту (time & materials) — когда объем непредсказуем.
Гибрид: аванс + фикс за этапы + почасовые работы на допы.

Практические рекомендации:

Аванс 20–40% в зависимости от масштаба и условий.
Удержание 5–15% до окончательной приёмки и передачи всех доступов.
Уточните условия возврата аванса в случае расторжения и случаи, когда исполнитель имеет право остановить работы (неоплата, несвоевременная передача материалов).

Изменения объема работ: допсоглашения и оценка

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

Как оформляется запрос на изменение (формат, кто подписывает).
Сроки оценки и согласования изменения.
Право исполнителя приостановить работу до согласования, если изменение критично.

Без строгой процедуры scope creep (расползание требований) съест бюджет и сроки. Заказчика стоит предупреждать заранее о вероятных последствиях изменений: перерасчёт стоимости и смещение дат.

Интеллектуальная собственность и права на код/контент

Один из главных пунктов: кто и на каких правах получает код, дизайн и контент. Варианты:

Полная передача исключительных прав после полного расчёта — наиболее безопасно для заказчика.
Лицензия на использование — если исполнитель сохраняет право использовать на портфолио/код в других проектах.
Постепенная передача прав по этапам — на практике удобно: права на готовые модули переходят после оплаты соответствующего этапа.

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

Как включить SEO в договор (рекомендации и KPI)

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

Два подхода

Базовая SEO‑готовность в рамках разработки: техническая оптимизация (семантическая структура, мета-теги, корректные H1/H2, ЧПУ, семантические URL, sitemap, robots.txt, микроразметка, скорость загрузки, адаптивность). Это — обязательный минимум, который должен быть прямо в SOW.
Дальнейшее SEO‑продвижение как отдельный сервис: контент‑стратегия, линкбилдинг, аналитика, регулярные работы по росту органики и KPI (трафик, конверсии). Это отдельный договор по продвижению с метриками и оплатой.

Гарантии, поддержка и SLA

Четко разделите гарантийный период и платную поддержку:

Гарантийный срок (обычно 30–90 дней) на исправление багов, возникших по вине разработчика, без дополнительной оплаты.
Опция поддержки/сопровождения по подписке (SLA): время реакции, приоритет, количество часов в месяц, почасовая ставка на внеплановые работы.
Платные услуги: контент, SEO‑продвижение, масштабирование функционала — отдельно оговариваются.

Пропишите SLA в формате: «ответ в течении X часов на критические инциденты, Y часов на некритические» и критерии критичности.

Ответственность, штрафы и форс‑мажор

Укажите порядок ответственности и штрафов за нарушение сроков и качества. Практика:

Штрафы за просрочку сдачи этапа: %, но в разумных пределах.
Ограничение ответственности: не более суммы оплаты по договору, исключая умысел и грубую небрежность.
Форс‑мажор: определите события и процедуру уведомления (сроки, доказательства), освобождающую от ответственности на период форса.

Важно: штрафы должны быть мотивирующими, а не карающими — чрезмерные пени часто блокируют конструктивную работу.

Хостинг, домен, сторонние лицензии

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

Частая ошибка: не оговорить ответственность за простои из‑за неуплаты домена/хостинга со стороны заказчика — тогда сайт не работает, а исполнитель получает претензии. Лучше заранее прописать уведомления и порядок действий.

Прекращение договора и передача проекта

Укажите основания для досрочного расторжения и порядок передачи материалов:

Расторжение по инициативе заказчика с выплатой стоимости фактически выполненных работ.
Расторжение по инициативе исполнителя при систематическом неисполнении обязательств заказчиком (непредоставление контента, неуплата).
Порядок передачи: архив проекта, репозиторий, доступы, акты приёмки/передачи.

Уточните, в каком виде передаются права (например, исключительные права передаются после 100% оплаты) и срок передачи материалов.

Обязательные приложения и чек‑лист для подписания

Перечень приложений, которые должны идти в комплекте:

Техническое задание (SOW).
План проекта и график работ.
Список deliverables и критерии приёмки.
Бюджет/калькуляция и график платежей.
Реквизиты сторон и контактные лица.
Протоколы тестирования и шаблон акта приёмки.

Чек‑лист перед подписанием договора:

Есть ли детализированное ТЗ? Если нет — договор рискует быть абстрактным.
Прописана ли передача прав и доступов?
Установлены ли сроки и критерии приёмки по этапам?
Оговорены ли условия изменения объёма и расчёты допработ?
Включены ли требования по базовому SEO и передаче аналитики/доступов?

Примеры формулировок и шаблонные пункты

Ниже — несколько рабочих формулировок, которые можно адаптировать под проект.

Предмет договора

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

Критерии приёмки

«Этап считается принятым после подписания сторонами Акта сдачи‑приёмки в течение 10 календарных дней с момента передачи соответствующих deliverables. В случае выявления недостатков Заказчик предоставляет Исполнителю баг‑лист, и Исполнитель устраняет недостатки в течение срока, указанного в баг‑листе, но не более 14 календарных дней для критических багов.»

Права на результаты

«После полной оплаты по Договору Исполнитель передаёт Заказчику исключительные права на программный код, макеты и иные результаты работ, за исключением сторонних компонентов, используемых в рамках лицензионных соглашений третьих лиц.»

Техническое SEO

«Исполнитель обеспечивает реализацию следующих технических требований: корректная семантическая разметка H1–H6, формирование мета‑тегов, корректные человекопонятные URL, генерация sitemap.xml и robots.txt, первичная микроразметка для основных карточек товаров/услуг, базовые настройки скорости и кэширования. Гарантии по позициям в поисковых системах не предоставляются.»

Практические советы по переговорам и ценообразованию

Как эксперт и владелец агентства, даю несколько рабочих советов:

Оценивайте проект по ценности для клиента, а не только по часам. Сайт, который генерирует лиды, стоит дороже за счёт ROMI и CPL.
Для стартапа или малого бизнеса используйте вариант минимального MVP‑сайта с возможностью масштабирования: меньше затрат сейчас, больше гибкости в будущем.
Обсуждайте SLA и поддержку заранее — многие клиенты недовольны, когда после сдачи проекта нет оперативной поддержки.
Не смешивайте в одном договоре долгосрочное продвижение и разработку без чёткой метрики; лучше два договора: разработка (фундамент) и продвижение (акселератор результата).

С точки зрения unit‑economics: если сайт для e‑commerce, рассчитывайте ROMI и CPA при выборе функций (корзина, оплата, витрина, скорость). Иногда добавление модуля позволит сократить CPL в Google Ads/Яндекс.Директ, но без SEO‑фундамента это временный эффект.

FAQ

1. Нужен ли отдельный договор на SEO после разработки сайта?

Да. Техническая SEO‑готовность должна быть в договоре на разработку. Комплексное продвижение (контент, линкбилдинг, аналитика) — отдельный сервис с отдельным соглашением и KPI. SEO — накопительный канал, требующий регулярных инвестиций.

2. Как обеспечить передачу всех доступов и избежать проблем после оплаты?

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

3. Можно ли требовать гарантии позиций в поиске в договоре?

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

4. Как учитывать сторонние лицензионные компоненты в договоре?

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

5. Что делать, если заказчик постоянно вносит правки и сдвигает сроки?

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

Как Rose Digital поможет с договором и проектом

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

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

Контрольный чек‑лист перед подписанием (кратко)

Есть ли подробное ТЗ и список deliverables.
Понятны ли сроки и критерии приёмки по этапам.
Прописаны ли права на код и механизм передачи доступов.
Уточнены ли условия оплаты, аванс и удержание.
Включены ли базовые требования по техническому SEO.
Есть ли соглашение о поддержке и SLA после сдачи.