Какого объёма должно быть ТЗ на разработку сайта?

Для лендинга достаточно 3–5 страниц, для корпоративного сайта — 10–15, для интернет-магазина — от 20. Важен не объём, а проверяемость: каждый пункт должен позволять однозначно ответить «сделано» или «не сделано» при приёмке.

Можно ли обойтись без ТЗ на маленьком проекте?

Нет. Даже для лендинга нужен минимальный документ: список блоков страницы, кто готовит тексты и фото, куда приходят заявки, критерии приёмки и сроки. Это 2–3 страницы, которые экономят недели споров.

Кто платит за составление ТЗ — заказчик или студия?

Либо проектирование входит в стоимость разработки (как в АОСА), либо оформляется отдельным платным этапом, результат которого — ТЗ и прототипы — остаётся у заказчика даже при смене подрядчика. Обе схемы рабочие.

ТЗ и договор — это одно и то же?

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

Что делать, если в процессе разработки захотелось изменить ТЗ?

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

ТЗ на разработку сайта: что включить — пошаговая инструкция, чек-лист и типовые ошибки

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

Зачем нужно ТЗ и почему «как у конкурента» — не ТЗ

Техническое задание — не бюрократия «для галочки», а единственный документ, который переводит ожидания в проверяемые требования. Пока договорённости живут в переписке и памяти о созвонах, любой спор решается по принципу «кто настойчивее». Когда требования записаны, спор решает текст: сделано по пункту 4.2 — принято, не сделано — доработка.

Фраза «сделайте как у конкурента» не работает: вы видите у конкурента фасад — дизайн, тексты, картинки. Вы не видите структуру каталога, скорость, разметку Schema.org, логику форм, админку и интеграции — то есть 80% того, что определяет результат. А главное — «похоже» и «непохоже» не проверяются: это вопрос вкуса, а не критерий приёмки. Если чужой сайт нравится, разложите ощущение на конкретику: структура услуг? калькулятор? скорость страниц? Каждый пункт превратится в проверяемое требование — и вот это уже ТЗ.

Кто должен писать техническое задание на сайт

Рабочая схема — совместная. Заказчик отвечает за бизнес-часть: цели, аудиторию, услуги и приоритеты, ограничения. Исполнитель — за техническую: структуру, функциональность, стек, требования к скорости и SEO. На практике заказчик заполняет бриф, студия превращает его в проект ТЗ, стороны обсуждают и подписывают итоговую версию как приложение к договору.

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

Что должно быть в ТЗ на сайт: структура-шаблон

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

Таблица «Шаблон разделов ТЗ на разработку сайта» из статьи «ТЗ на разработку сайта: что включить»: колонки — Раздел, Что фиксирует, Риск, если раздела нет; строки — 1. Цели и задачи, 2. Аудитория и сценарии, 3. Карта страниц, 4. Прототипы ключевых страниц, 5. Контент, 6. Функциональные требования, 7. Технические требования, 8.… — Шаблон разделов ТЗ на разработку сайта — сводная таблица

Шаблон разделов ТЗ на разработку сайта
Раздел	Что фиксирует	Риск, если раздела нет
1. Цели и задачи	Бизнес-результат: заявки, звонки, продажи — и как их измерять	Сайт «красивый», но не решает задачу
2. Аудитория и сценарии	Кто приходит и что должен сделать на каждой странице	Структура «от отделов компании», а не от клиента
3. Карта страниц	Полный список страниц и типов страниц с URL	«А где страница про доставку?» — на приёмке
4. Прототипы ключевых страниц	Состав и порядок блоков главной и продающих страниц	Дизайн-сюрприз и правки по кругу
5. Контент	Кто готовит тексты, фото, прайсы — объём и сроки	Готовый сайт месяцами ждёт тексты
6. Функциональные требования	Формы, фильтры, калькуляторы, корзина — с логикой работы	«Форма есть», но заявки не приходят
7. Технические требования	Стек, адаптивность, браузеры, скорость, SEO-минимум	Медленный сайт без метатегов, «зато сдан»
8. Интеграции	CRM, аналитика, телефония, оплата — кто даёт доступы	Интеграции «за отдельные деньги» после сдачи
9. Админка и роли	Что заказчик правит сам без разработчика	Каждая правка цены — платная задача студии
10. Порядок приёмки	Этапы, критерии, итерации правок, гарантия, доступы	Бесконечная сдача или приёмка «на доверии»

Отдельно про раздел 7: SEO-минимум должен попасть в ТЗ до начала разработки, а не «потом, когда займёмся продвижением». Уникальные title и description, человекопонятные адреса, корректные коды ответов, sitemap, базовая разметка — доделывать это на готовом сайте дороже, чем заложить сразу. При переезде со старого сайта обязательный пункт — карта 301-редиректов со старых адресов: без неё переезд теряет накопленные позиции.

Уровень детализации: где нужна точность, а где она вредит

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

Формулировки, которые защищают заказчика при приёмке

Одна и та же договорённость может быть записана так, что защищает вас, — или так, что оставляет простор для трактовок. Несколько типовых примеров «слабо → сильно»:

Вместо «адаптивная вёрстка» — «сайт корректно работает в актуальных версиях Chrome, Safari, Firefox и Яндекс Браузера на экранах от 320 px; проверка — на реальных устройствах при сдаче».
Вместо «быстрый сайт» — «PageSpeed Insights для главной и трёх страниц из приложения 1 — не ниже 80 на мобильных на момент сдачи».
Вместо «формы работают» — «заявка из каждой формы приходит на e-mail и в CRM; при сдаче отправляется тестовая заявка с каждого типа устройств».
Вместо «сайт оптимизирован под SEO» — «каждая страница имеет уникальные title и description и ЧПУ-адрес; несуществующие адреса отдают код 404; sitemap.xml обновляется автоматически».
Вместо «заказчик предоставляет материалы» — «тексты и фото для 12 страниц по приложению 2 заказчик передаёт до [дата]; задержка сдвигает срок сдачи на срок задержки».
Вместо «правки по договорённости» — «14 дней после сдачи исполнитель бесплатно устраняет несоответствия ТЗ; работы вне ТЗ оформляются допсоглашением с отдельной оценкой».

Чек-лист «Формулировки, которые защищают заказчика при приёмке» из статьи «ТЗ на разработку сайта: что включить»: 6 пунктов — Вместо «адаптивная вёрстка»; Вместо «быстрый сайт»; Вместо «формы работают»; Вместо «сайт оптимизирован под SEO»; Вместо «заказчик предоставляет материалы»; Вместо «правки по договорённости» — Формулировки, которые защищают заказчика при приёмке: чек-лист

Иллюстративный сценарийКак «хотелку» переводят в требование

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

Собирательный пример на основе типовых проектов — не реальный клиент.

Типовые ошибки в техзадании на создание сайта

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

Что дальше: от ТЗ к проекту

Писать ТЗ в одиночку не нужно — это часть работы подрядчика. В АОСА проектирование входит в стоимость разработки сайта: лендинг — от 50 000 ₽ (2–3 недели), корпоративный сайт — от 120 000 ₽ (4–6 недель), интернет-магазин — от 250 000 ₽ (8–12 недель). Мы собираем сайты на статической архитектуре Next.js, и требования к скорости, адаптивности и SEO-минимуму стоят в наших ТЗ по умолчанию — потому что мы же потом эти сайты и продвигаем.

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

Владимир БогдановОснователь и руководитель AOSA · эксперт по SEO и AEO, 12+ лет в поисковой оптимизации

ТЗ на разработку сайта: что включить

Зачем нужно ТЗ и почему «как у конкурента» — не ТЗ

Кто должен писать техническое задание на сайт

Что должно быть в ТЗ на сайт: структура-шаблон

Уровень детализации: где нужна точность, а где она вредит

Формулировки, которые защищают заказчика при приёмке

Типовые ошибки в техзадании на создание сайта

Что дальше: от ТЗ к проекту

Коротко о главном

Разберём вашу нишу так же подробно