Техническое задание на сайт: что писать, а что больше не нужно
Правку теперь сделать быстрее, чем описать. Из этого многие делают вывод, что техническое задание больше не нужно, — и получают красивый сайт, который не приводит клиентов. Разбираю, какая часть ТЗ действительно умерла, а какая, наоборот, стала стоить дороже всего остального.
- Умерла форма, а не смысл. Тридцать листов с согласованием по две недели больше не нужны: правку сделать быстрее, чем описать.
- Аналитика перед сайтом — это и есть работа. Кодинг и дизайн при готовых пайплайнах стоят почти ноль, а решение «каким должен быть сайт» — всё ещё сто тысяч рублей и больше.
- Порядок нельзя переставлять: семантика → конкуренты → язык клиента → путь пользователя → структура → дизайн. Дизайн раньше структуры — самая дорогая ошибка.
- Показать готовое на 90% дешевле, чем согласовать ТЗ. Заказчику проще ткнуть в живой макет, чем вычитать документ.
Содержание статьи
Раньше сайт начинался с ТЗ на тридцать листов, которое согласовывали две недели. Логика была понятной: час дизайнера и программиста стоит дорого, поэтому сначала до буквы договариваемся, потом делаем.
Сейчас эта логика сломалась. Поменять дизайн, добавить раздел, переписать блок — вопрос минут. Правку сделать легче, чем составить ТЗ на правку. Я несколько раз брался за работу с постановкой уровня «нужен редизайн» и показывал готовый на девяносто процентов сайт до всякого согласования — заказчику так проще, а мне быстрее.
И параллельно с этим выяснилась вторая вещь, ровно противоположная на первый взгляд.
Что теперь стоит дорого
Когда кодинг и дизайн стали почти бесплатными, стало видно, из чего на самом деле состоит работа над сайтом.
По моей практике заказных сайтов, аналитика и постановка — это порядка 95% работы. Оставшиеся проценты — то, что все обсуждают: промпты, стек, красота. Токены на большой многостраничный SEO-сайт по API обходятся примерно в 80 000 ₽ — без картинок, анимаций и человеко-часов; на подписке пока дешевле, но никто не обещал, что подписки останутся.
Отсюда простой вывод: кто говорит, что сайты теперь ничего не стоят, обычно имеет в виду только генерацию страниц. Я и сам так думал первое время.
Проверка на честность
«Сайт за час с одного промпта» — правда ровно до вопроса «а откуда взялась структура разделов». Если ответ «модель придумала» — сайт построен на её представлении о вашей нише, а не на том, что люди действительно ищут.
Продолжение — в канале
Тут — только метод. Ход запусков, цифры проектов и то, что сломалось на этой неделе, выкладываю в Telegram.
Порядок, который нельзя переставлять
Ниже то, что я собираю до первой строчки кода. Порядок здесь важнее полноты: каждый следующий пункт опирается на предыдущий.
Что входит в ТЗ на самом деле
Семантика — вся. Полный сбор запросов по теме, актуальный, с частотностью. Из него следует структура сайта и набор блоков на страницах. Не «примерно понятно, что ищут», а выгрузка. Как это делается — в разборе про семантическое ядро. Разбор топа. Открываем сайты из выдачи по главным запросам и разбираем поблочно: какие блоки на странице, в каком порядке, что обещают, чем цепляют. Лучшее забираем, слабое отмечаем как возможность отличиться. Язык клиента. Расшифровки звонков, кастдевы, отзывы конкурентов, ветки на форумах. Отсюда берутся формулировки, FAQ и возражения — люди уже описали свою проблему, её нужно только не испортить. Путь пользователя. Куда человек попадает, что видит первым, куда переходит, чем закрывается его запрос на конкретной странице. Не абстрактная воронка, а маршрут по вашим будущим страницам. Структура сайта и страниц. Разделы, шаблоны страниц, набор блоков в каждом шаблоне. Только теперь. Дизайн. После структуры, а не до неё. Тексты по шаблонам и проверка смыслов: не «есть текст», а «текст отвечает на запрос, с которым пришли». Аудиты перед сдачей: техничка, UX, картинки, формы, интеграции. Юридическая часть — документы, согласия, куки.
Самая дорогая перестановка в этом списке — начать с дизайна. Красивый макет, нарисованный до семантики, потом упирается в то, что нужных разделов в нём нет, а половина блоков ни на какой запрос не отвечает. Переделывать приходится не картинку, а логику.
Как это выглядит на практике
ТЗ сегодня — не документ для подписи, а рабочий контекст: файл, который читает и человек, и агент. У него другая форма и другая жизнь.
Тридцать листов, две недели согласования, подписи сторон. Цель — зафиксировать обязательства, чтобы потом не переделывать за свой счёт. Меняется тяжело: любая правка — допсоглашение.
Компактная рамка плюс аналитика: семантика, разбор конкурентов, язык клиента, структура. Цель — чтобы исполнитель и модель понимали, что строим. Меняется на ходу, потому что переделка дешёвая.
С заказчиком это меняет схему разговора. Вместо «согласуйте документ» — договориться о рамке (что за проект, насколько сложный, что прорабатываем) и показать готовое. Пока конкуренты считают смету и согласовывают тридцать листов, можно показать почти готовый сайт и доделать по правкам.
Где эта лёгкость выходит боком
Отказавшись от формального ТЗ, легко отказаться заодно и от аналитики — она ведь тоже «бумажная работа». Получается сайт, который нравится заказчику и не приносит заявок. Дальше начинается спор, кто виноват, хотя виновата пропущенная первая половина списка. Рамку фиксируйте письменно всегда: что делаем, что не делаем, сколько итераций правок.
Минимальная версия для себя
Если сайт вы делаете себе, а не на заказ, полный набор избыточен. Рабочий минимум, который всё равно нужно сделать руками:
ТЗ на свой сайт — короткая версия
Выгрузка запросов по теме с частотностью — из неё разделы сайта. Пять сайтов из топа, разобранные поблочно. Двадцать реальных фраз клиентов: из отзывов, переписок, звонков. Список страниц и что на каждой должно быть. Одно целевое действие на страницу — что человек должен сделать.
Это день работы. Он экономит неделю переделок и решает главный вопрос — не «как сделать сайт», а каким он должен быть.
- Начинайте не с прототипа, а с семантики: структура сайта следует из спроса, а не из вкуса.
- Отзывы и расшифровки звонков — источник текстов на сайте: люди описывают проблему своими словами, вы их переписываете.
- Разбирайте конкурентов из топа поблочно: что за блоки на странице, в каком порядке, что обещают.
- Собирайте ТЗ как рабочий контекст для агента, а не как документ для подписи.
- Договаривайтесь с заказчиком о рамке — сложность и объём, — а детали показывайте макетом.
Гайд «SEO-машина»: как собрать её на ИИ-агентах
Карта из десяти систем: что делает каждая и как собрать такую же — с любым ИИ-агентом, Claude Code или Codex. Бесплатно, отдаёт бот в Telegram.
Частые вопросы
Нужно ли ТЗ, если сайт делает нейросеть?
Нужно, но другое. Модели не нужна форма документа — ей нужен контекст: кто клиент, какими словами он ищет, что у конкурентов, какой путь по сайту он проходит. Это и есть ТЗ сегодня. А вот многостраничный документ для подписи ради подписи потерял смысл: правку теперь дешевле сделать, чем описать.
Сколько стоит составить техническое задание на сайт?
Разработка ТЗ с маркетинговой и SEO-проработкой — от ста тысяч рублей, и это самая дорогая часть проекта. Причина простая: кодинг и дизайн ускорились в разы, а сбор семантики, разбор конкурентов и работа с клиентскими данными — нет.
С чего начать составление ТЗ?
С семантики. Полный сбор запросов даёт структуру сайта: какие разделы нужны, какие страницы под какие запросы и о чём писать на каждой. Всё остальное — конкуренты, тексты, дизайн — надстраивается сверху.
Можно ли взять образец ТЗ и заполнить его?
Как оглавление — да. Но ценность документа не в разделах, а в содержимом: своя семантика, свои конкуренты, свои клиенты. Заполненный чужой шаблон даёт ощущение проделанной работы без самой работы.
Что делать, если заказчик не может сформулировать, чего хочет?
Не мучить его документом. Собрать рамку в двух абзацах — что за бизнес, кому продаёт, чем отличается — и показать готовый на девяносто процентов макет. По живому макету человек скажет о своих требованиях больше, чем при вычитке ТЗ на тридцать листов.
10 лет в маркетинге и онлайн-образовании. Запускаю проекты в одиночку на Claude Code и показываю экономику как есть. Все методы из блога сначала обкатываю на своих проектах и только потом описываю.