ТЗ на разработку сайта: что в нём должно быть, образец структуры и как проверить чужое

ТЗ на разработку сайта — это документ требований к результату, который подписывают заказчик и исполнитель и прикладывают к договору. В нём описывают платформу, карту страниц, блоки каждой страницы, функции, интеграции, сроки, права на код и способ проверки каждого требования. Нужен он прежде всего заказчику: без описанных требований качество работы определяется не вашими ожиданиями, а «требованиями, обычно предъявляемыми к работам соответствующего рода» (п. 1 ст. 721 ГК РФ), поэтому спор «сайт сделан плохо» превращается в спор о вкусе. Ниже — состав ТЗ по разделам с пояснением, что писать в каждом, фрагмент настоящего документа и 12 вопросов, чтобы проверить задание, которое прислал исполнитель.

Нужен сайт под ключ вместе с прототипом и техническим заданием? Посчитайте проект в калькуляторе стоимости — бриф и разбор задачи у нас бесплатные и ни к чему не обязывают.

Это не юридическая консультация. Статья описывает общие правила на октябрь 2026 года для сайта малого и среднего бизнеса. Если проект идёт по госконтракту, затрагивает медицинские или биометрические данные либо стоит несколько миллионов, договор и ТЗ стоит показать юристу.

Что такое ТЗ на разработку сайта и чем оно отличается от брифа и договора

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

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

Бриф и ТЗ — разные документы с разными авторами. Бриф заполняете вы: сколько у вас услуг, кто клиент, какой бюджет и к какой дате нужен запуск. Это сырьё.

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

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

Что даёт ТЗ и чем грозит его отсутствие

Без ТЗ вы теряете право определять, что считается нормальным результатом. П. 1 ст. 721 ГК РФ: качество работы должно соответствовать условиям договора, «а при отсутствии или неполноте условий — требованиям, обычно предъявляемым к работам соответствующего рода». Планку задаёт не заказчик, а обычная практика, и исполнитель всегда может сказать «так делают все».

Второе — приёмка. По п. 1 ст. 720 ГК заказчик обязан осмотреть работу и сразу заявить о недостатках, а по п. 3 принявший без проверки лишается права ссылаться на то, что можно было заметить. Поэтому раздел «как проверяем» — ваш собственный список того, что надо успеть до подписания акта.

Нашлись недостатки — п. 1 ст. 723 ГК даёт выбор: бесплатно устранить, уменьшить цену или возместить ваши расходы. Но выбор работает там, где есть с чем сверять: «мне не нравится шрифт» недостатком не считается, «заголовки — Inter Semibold 32/40 по макету стр. 4» считается.

Третье узнают поздно. По п. 4 ст. 709 ГК цена считается твёрдой, и подрядчик не вправе требовать её увеличения. Звучит как защита заказчика, и это она — но именно поэтому спор идёт не про цену, а про границы: исполнитель не поднимает ставку, он доказывает, что спорная работа в ТЗ не входила.

Как это выглядит в жизни — четыре типичных исхода:

• Доплата за то, чего «не было в ТЗ». В задании «форма заявки», а вам нужно, чтобы заявка попадала в CRM с источником и UTM-меткой. Это разные объёмы работ, второй оплачивается отдельно.
• Срыв срока из-за контента. «Тексты предоставляет заказчик», дата не названа. Проект встаёт на вёрстке, разработчик уходит на другой проект, три недели превращаются в два месяца.
• Нечего проверять при приёмке. Требования написаны пожеланиями, и приёмка превращается в спор о вкусах, где позиция исполнителя сильнее.
• Потеря трафика при переделке. Адреса поменялись, редиректов нет: заявки с поиска прекращаются и возвращаются месяцами.

Показательный пример. Производитель мебели заказал сайт с «каталогом продукции»: исполнитель заложил 40 карточек с ручным заполнением, а у заказчика 900 позиций с остатками в 1С. Обе стороны честны, и обе правы — в задании не было ни числа позиций, ни выгрузки. Разница между пониманиями — несколько месяцев работы, а снимает её одна строка: «каталог: 900 позиций, свойства и остатки загружаются из 1С раз в сутки».

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

Отдельно про задание от нейросети, потому что в 2026 году так делают часто. Модель выдаёт правдоподобный каркас разделов, и на этом польза заканчивается: она не знает ни вашу CRM, ни число позиций в каталоге, ни срок, к которому вы отдадите тексты, а нормы о персональных данных берёт из текстов до 2025 года. Возьмите у неё структуру и перечень вопросов, а содержание требований впишите сами или вместе с исполнителем — проверять работу будут по вашим строкам.

Кто составляет ТЗ: вы, студия или вместе

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

Пишет заказчик. Границы заданы вашими словами — это плюс. Минус в том, что вы не знаете, какие требования вообще бывают: в самодельных заданиях нет разделов про редиректы, права на код, передачу доступов и запуск аналитики после согласия на cookie. Такое ТЗ стоит отдать на вычитку второму исполнителю — он бесплатно назовёт, чего в нём нет.

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

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

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

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

Из каких разделов состоит ТЗ: образец структуры и что писать в каждом

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

Блок 1. О проекте: зачем сайт и для кого

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

2. Аудитория и сценарии. Кто придёт и что будет делать: «прораб с телефона на стройке ищет цену на профнастил и звонит». Сценарии полезнее портретов, потому что из них вырастают требования к интерфейсу — из «прораба с телефона» сразу следует крупный шрифт цен и кнопка звонка в шапке.

3. Конкуренты и референсы. Три-пять ссылок с пояснением, что именно взять: «у этих — порядок блоков на главной». Ссылка без пояснения опасна, потому что «сделайте как здесь» каждый прочитает по-своему. Напишите и то, что не нравится: это экономит круг правок по дизайну.

Блок 2. Что именно делаем

4. Платформа, хостинг и домен. Конструктор с названием и тарифом, известная CMS или стек на открытых технологиях; на кого регистрируется домен, где хостинг, кто платит и продлевает. Расплывчатость здесь обходится дороже всего — об этом отдельный разговор ниже.

5. Карта сайта. Полный список страниц с вложенностью и адресами. Это одновременно смета в миниатюре, потому что число страниц определяет объём работ. Как разложить страницы под запросы — в статье про структуру сайта.

6. Шаблоны страниц по блокам. Для каждого типа страницы — блоки сверху вниз и что в каждом. Шаблонов обычно 5⁠–⁠8 на весь сайт, например карточка услуги и страница каталога, поэтому описывать 60 страниц поштучно не нужно: опишите шаблоны и укажите, сколько страниц делается по каждому.

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

8. Интеграции. Сервисы с названиями: CRM, 1С, платёжный шлюз, доставка, телефония, аналитика; по каждой — кто заключает договор, кто платит, какие данные передаются и как проверяется работа. Добавьте строку про UTM-метки: они должны доезжать до CRM, иначе вы не узнаете, какой канал приносит заявки. Интеграции чаще всего и ломают срок, потому что зависят от третьей стороны.

Блок 3. Как это должно работать

9. Контент: кто даёт тексты и фото и к какой дате. Не только «предоставляет заказчик», но и в каком виде, к какой дате и что будет при опоздании. Самый недооценённый раздел, ниже есть отдельный разбор.

10. Дизайн и фирменный стиль. Брендбук, логотип в векторе, цвета, шрифты, число кругов правок и что считается кругом. Отдельная строка — лицензии на шрифты и стоковые фото: они оформляются на лицо и в комплект работ по умолчанию не входят.

11. Адаптивность. Перечислите разрешения проверки: 375, 768 и 1440 пикселей закрывают телефон, планшет и ноутбук. «Корректно отображается на всех устройствах» требованием не считается, потому что проверить это нельзя. Отдельно оговорите таблицы, калькуляторы и карты — на телефоне они ведут себя иначе.

12. Браузеры и версии. Chrome, Safari, Firefox, Edge и мобильные, с минимальной версией. Без этого претензия «у меня в старом браузере поехало» становится бесконечной.

13. SEO и скорость. Оба пишутся списками и цифрами, а не словами «сделать SEO». Что входит — ниже отдельным разделом.

14. Безопасность и требования закона. HTTPS, разграничение доступов в админке, резервные копии и требования 152-ФЗ, без которых сайт с формой в 2026 году запускать нельзя. Им тоже посвящён раздел ниже.

15. Админка: что заказчик меняет сам. Перечислите словами владельца: «менять текст, цену и фото услуги», «добавлять статью», «править title любой страницы». Без списка разработчик выберет сам, и половина правок станет платными задачами. Проверка простая: после сдачи вы делаете каждое действие сами.

Блок 4. Как вы это примете и закроете проект

16. Тестирование и критерии приёмки. Как проверяется каждое требование и что считается прохождением. Самый важный раздел документа, потому что именно по нему вы будете принимать работу, — ниже разбор, как писать такие формулировки.

17. Этапы, сроки и признак завершения. По каждому этапу: что сдаётся, в какой срок и по какому признаку он закрыт. «Дизайн готов» — не признак, «макеты 6 шаблонов в Figma согласованы письменно» — признак. Из каких этапов состоит работа — в статье про этапы создания сайта.

18. Передача: доступы, исходники, права. Доступы с правами владельца, исходники — репозиторий, макеты, экспорт базы, права на код и дизайн. Фиксируется актом, а не обещанием «отдадим по запросу».

19. Что не входит в работу. Наполнение каталога, тексты, фотосъёмка, реклама, продвижение, подача уведомления в Роскомнадзор, покупка лицензий. Список снимает разговор «я думал, это входит», поэтому он защищает обе стороны, а не только исполнителя.

20. Порядок изменений. Кто запрашивает, за какой срок исполнитель даёт оценку в часах, как оформляется и как влияет на дату сдачи.

21. Гарантия и поддержка. Срок после приёмки, что входит и что нет, время реакции, кто продлевает сервисы.

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

23. Глоссарий и лист согласования. Расшифровка терминов и подписи сторон. Глоссарий нужен не для солидности: без него «блок», «раздел» и «страница» участники читают по-разному.

Объём выходит такой: лендинг 3⁠–⁠8 страниц, многостраничный сайт 10⁠–⁠25, магазин 25⁠–⁠60. Нумеруйте требования насквозь (1.1, 4.3) — по номеру вы напишете замечание при приёмке быстрее, чем пересказывая пункт словами. На согласовании держите документ там, где его комментируют построчно, а на подписании выгружайте в PDF с датой и версией: без версии через месяц стороны обсуждают разные документы, искренне считая их одним.

Пример ТЗ на разработку сайта: фрагмент рабочего документа

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

``` 4.3. Шаблон страницы услуги (18 страниц по этому шаблону)

4.3.1. Первый экран: H1 с названием услуги, подзаголовок до 140 знаков, цена «от» с единицей измерения, кнопка «Рассчитать стоимость» (открывает форму 5.1), фоновое фото объекта. 4.3.2. Блок «Что входит»: 4⁠–⁠8 пунктов, каждый — иконка, заголовок до 40 знаков, текст до 180 знаков. Пункты редактируются в админке. 4.3.3. Блок «Цены»: таблица из трёх колонок (работа, единица, цена). Строки добавляются и удаляются в админке без разработчика. 4.3.4. Блок «Примеры работ»: 3⁠–⁠6 объектов, у каждого фото, район, срок и стоимость. Берётся из раздела «Объекты» по метке услуги. 4.3.5. Блок «Вопросы и ответы»: 4⁠–⁠7 пар, раскрываются по нажатию. 4.3.6. Форма 5.1 в конце страницы.

5.1. Форма «Рассчитать стоимость»

5.1.1. Поля: имя (обязательное), телефон (обязательное, маска +7 ___ -_-), комментарий (необязательное), чекбокс согласия (обязательный, не отмечен заранее, со ссылками на /politika и /soglasie). 5.1.2. После отправки — переход на страницу /spasibo с номером заявки. 5.1.3. Заявка записывается в базу на сервере в РФ, затем дублируется на почту заказчика и уведомлением в Telegram без имени и телефона. 5.1.4. При недоступности почты или Telegram заявка остаётся в базе, посетителю показывается страница благодарности. ```

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

Рядом с фрагментом в рабочем документе идёт таблица проверки:

Как формулировать требования, чтобы работу можно было принять

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

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

Когда требования написаны так, приёмка перестаёт быть спором: вы берёте документ и идёте по пунктам. Минимальный набор проверок перед подписанием акта выглядит так:

1. Тестовая заявка с каждой формы, включая всплывающие окна, квиз и корзину, доходит во все каналы: база, почта, мессенджер.
2. Письмо о заявке не попадает в спам — проверьте на двух разных почтовых сервисах.
3. Формы работают с телефона: маска телефона, клавиатура с цифрами, кнопка нажимается пальцем.
4. На ширине 375 пикселей нет горизонтальной прокрутки ни на одной странице.
5. Скорость замерена на мобильном профиле, и цифры совпадают с требованием ТЗ.
6. Title и description каждой страницы правятся из админки, а не в коде.
7. Все действия из раздела «что заказчик меняет сам» вы делаете своими руками, без подсказок.
8. Страницы политики и согласия опубликованы, ссылки стоят в подвале и у каждой формы, галочка не отмечена заранее.
9. Аналитика считает заявки как цель, и вы видите это в отчёте.
10. Доступы, исходники и макеты переданы и приняты по акту, пароли сменены на ваши.

Найденные на приёмке недостатки нужно записать в акт или отдельный документ. Пункт 2 ст. 720 ГК позволяет ссылаться на них позже только тогда, когда они оговорены в акте либо там указана возможность предъявить требование об устранении. Устный разговор «потом доделаете» такой возможности не создаёт.

Что забывают в ТЗ чаще всего — и сколько это стоит

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

Права на код, дизайн, шрифты и фотографии

По п. 1 ст. 1296 ГК РФ исключительное право на произведение, созданное по договору, принадлежит заказчику, если договором не предусмотрено иное. По умолчанию право ваше — и ровно эту оговорку используют, когда вписывают в договор, что код остаётся у исполнителя, а вам даётся лицензия. Показать работу в портфолио подрядчик сможет и без этого: п. 2 той же статьи даёт ему безвозмездную лицензию для собственных нужд.

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

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

Домен, аккаунты и исходники

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

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

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

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

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

Контент: кто даёт тексты и фото и к какой дате

Одна из самых частых причин сдвинутого срока — и почти никогда не вина разработчика. В задании стоит «тексты предоставляет заказчик», даты нет, и проект замирает на вёрстке на три недели, пока владелец пишет описания услуг между делами.

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

Переделка работающего сайта: список адресов и 301-редиректы

Переделываете сайт, который уже есть в поиске, — в задании обязателен пункт про перенаправления: выгрузить действующие адреса из Яндекс Вебмастера, Search Console и карты сайта, сопоставить каждый старый с новым и настроить постоянные перенаправления 301. Без этого после запуска поисковики получают сотни страниц с ошибкой 404, трафик падает и восстанавливается месяцами. Вторая половина пункта — не потерять страницы, которые приносили людей: в новый дизайн обычно влезают не все старые разделы, поэтому заранее выгружают страницы с трафиком за год и каждую либо переносят, либо сознательно склеивают с похожей.

Границы работы, гарантия и поддержка

Раздел «что не входит» из десяти строк снимает половину будущих обид. Обычно туда попадают:

• наполнение каталога;
• тексты;
• фотосъёмка;
• покупка лицензий;
• настройка рекламы;
• продвижение после запуска;
• подача уведомления в Роскомнадзор;
• онлайн-касса и договор с платёжным сервисом.

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

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

Требования 152-ФЗ, которые обязаны быть в ТЗ 2026 года

Шаблоны заданий 2019⁠–⁠2022 годов в этой части устарели целиком: за 2025 год требования к сайтам с формами менялись трижды. Пять строк ниже обязательны для любого сайта с заявками, и каждая из них — требование к разработке, а не к тексту документов.

• Заявки записываются в базу на территории России, в мессенджер уходит только уведомление без имени и телефона. Хранение данных граждан РФ за границей не допускается (ч. 5 ст. 18 152-ФЗ), штраф по ч. 8 ст. 13.11 КоАП — от 1 до 6 млн ₽, и ИП отвечает как юридическое лицо.
• У каждой формы отдельный чекбокс согласия, не отмеченный заранее, со ссылками на документы — включая всплывающие окна, квиз и корзину. С 1 сентября 2025 года согласие оформляется отдельно от других документов, поэтому одна галочка «согласен с политикой, офертой и рассылкой» больше не годится. Как оформить согласие на обработку персональных данных, разобрали отдельно.
• Две отдельные страницы — политика и согласие — и ссылки на них в подвале и рядом с каждой кнопкой отправки. О том, что писать в политике конфиденциальности, — в отдельной статье.
• Cookie-баннер, а счётчики запускаются после согласия. Обычным способом подключённый счётчик стартует сразу при загрузке, поэтому нужен код, который подгружает аналитику только после нажатия «Принять».
• HTTPS и отдельные учётные записи в админке с разными правами, а не общий пароль на всех.

Кто за что отвечает. Оператор персональных данных — вы, владелец сайта, а не студия и не конструктор: они обрабатывают данные по вашему поручению. Уведомление в Роскомнадзор подаёте вы, подписать его за вас исполнитель не может (ст. 22 152-ФЗ), штраф за неподанное — от 100 до 300 тыс. ₽ одинаково для ИП и компании. Но сведения для уведомления знает исполнитель, поэтому впишите в ТЗ строку «исполнитель передаёт заказчику сведения о местонахождении базы данных и о принятых мерах защиты», а саму подачу отнесите в раздел «что не входит в работу».

Проверьте и шаблон, из которого берёте формулировки: типовые задания до сих пор предписывают Google Analytics и reCAPTCHA, а это трансграничная передача с отдельным уведомлением. Заменить их российскими аналогами на этапе требований дешевле, чем переделывать после запуска. Если на сайте будет оплата, добавьте ещё две строки: онлайн-касса с признаком готовности «тестовый платёж прошёл и чек пришёл покупателю» и обязательные страницы магазина — оферта, доставка, возврат и реквизиты в подвале (п. 2 ст. 26.1 закона «О защите прав потребителей»). Их регулярно забывают заложить в карту сайта.

Что писать в ТЗ про SEO и скорость сайта

Слово «SEO» требованием не считается: его можно выполнить любым способом или не выполнить вовсе. Работает только список того, что должно быть сделано в коде и в админке:

• адреса страниц читаемые и по согласованной схеме, например /uslugi/montazh-krovli, а не /page?id=27;
• title, description и H1 каждой страницы редактируются из админки, без обращения к разработчику;
• на странице один H1, заголовки идут по уровням без пропусков;
• sitemap.xml обновляется автоматически при добавлении страницы, robots.txt не закрывает нужные разделы;
• микроразметка Organization и BreadcrumbList, а для статей и вопросов — Article и FAQPage;
• у изображений заполняется alt, и поле для него есть в админке;
• канонический адрес у страниц с параметрами, чтобы фильтры каталога не создавали дубли;
• адреса склеены: с www и без, с косой чертой на конце и без — один вариант, остальные отдают 301;
• страница 404 с навигацией, а не пустой экран.

Второй пункт пропускают чаще всего, а стоит он дороже прочих: без него разработчик пропишет мета-теги в коде, и каждая правка title станет задачей на разработку. Это не злой умысел, а экономия — чего нет в задании, того не делают. Какие страницы вообще нужны сайту, разобрано в статье про структуру сайта, и карту страниц из неё в ТЗ переносят целиком.

Скорость записывают цифрами, и теми, которые показывает PageSpeed Insights: LCP ≤ 2,5 с, CLS ≤ 0,1, INP ≤ 200 мс. Последняя метрика с 12 марта 2024 года заменила прежнюю FID, поэтому в шаблонах 2022 года встречается устаревшее название.

Обязательно укажите условия замера — без них спор неразрешим: один и тот же сайт на мобильном профиле с медленной сетью и на ноутбуке с оптоволокном покажет разницу в разы. Рабочая формулировка: «LCP ≤ 2,5 с, CLS ≤ 0,1, INP ≤ 200 мс по PageSpeed Insights, мобильный профиль, для главной и двух внутренних страниц». Рядом полезны изображения в WebP не тяжелее 250 КБ и ленивая загрузка картинок ниже первого экрана.

Нужно ли ТЗ по ГОСТу

Для коммерческого сайта — нет. Стандарт существует: ГОСТ 34.602-2020 действует с 1 января 2022 года, есть и более старый ГОСТ 19.201-78, на который ссылается часть шаблонов в интернете. Но документы по стандартизации применяются добровольно — это прямо записано в ст. 4 и ч. 1 ст. 26 закона 162-ФЗ «О стандартизации».

Обязательными они становятся в двух случаях: когда на ГОСТ ссылается ваш договор и когда так требует закон. Второй случай — госзакупки: при закупке по 44-ФЗ описание объекта обязательно и живёт по своим правилам (ст. 33). Закупаете сайт для бюджетной организации — вам нужно задание по правилам контрактной системы, а не шаблон из этой статьи.

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

Как проверить ТЗ, которое вам прислали: 12 вопросов

Если задание составлял исполнитель, читайте его как договор. Пройдите по списку: каждое «нет» — это либо вопрос исполнителю, либо будущая доплата.

1. Есть ли у требований способ проверки? Найдите раздел о приёмке. Если его нет или в нём написано «работа принимается по факту выполнения», принимать вам будет нечего.
2. Есть ли раздел «что не входит в работу»? Его отсутствие не в вашу пользу: границу всё равно проведут, но позже и в разговоре о доплате.
3. Названы ли платформа, хостинг и тариф? «Собственная CMS исполнителя» и «административная панель разработчика» означают, что поддерживать сайт сможет только автор.
4. Перечислены ли интеграции с названиями сервисов? «Интеграция с CRM» без названия и без описания передаваемых полей — требование, которое можно выполнить как угодно.
5. Сказано ли, кто даёт контент, в каком виде и к какой дате? Если даты нет, срыв срока по вине контента будет вашей проблемой без объяснений.
6. Есть ли строки про права, исходники и доступы? Проверьте, что передаются доступы с правами владельца, исходники и права на код и макеты, и что в договоре нет оговорки про лицензию вместо передачи прав.
7. Есть ли требования 152-ФЗ? База в России, отдельная галочка у каждой формы, страницы политики и согласия, запуск аналитики после согласия. Без них сайт нельзя будет запускать без доработки.
8. Требования к скорости — в цифрах и с условиями замера? «Быстрая загрузка» не проверяется, «LCP ≤ 2,5 с на мобильном профиле» проверяется.
9. Есть ли сроки по этапам и признак завершения этапа? Один общий срок на весь проект означает, что о проблеме вы узнаете в последнюю неделю.
10. Описан ли порядок изменений? Кто запрашивает, за какой срок исполнитель оценивает, как это влияет на дату сдачи и сколько кругов правок включено.
11. Нет ли оценочных слов? Пройдитесь поиском по словам «современный», «удобный», «качественный», «оптимальный», «и т. п.», «и другое»: каждое найденное — место будущего спора.
12. Совпадает ли ТЗ со сметой построчно? Возьмите смету и отметьте, какой пункт задания оплачивает каждая её строка. Работ, которых нет в ТЗ, но есть в смете, быть не должно, и наоборот.

Отдельно о красных флагах:

• Задание на интернет-магазин короче двух страниц — это бриф, который переименовали.
• Задание на сорок страниц по ГОСТу без описания блоков страниц — шаблон, который заполняли не для вас.
• Фраза «дизайн на усмотрение исполнителя» означает, что круги правок будут платными.
• Формулировка «сделать как у конкурента» без разбора, что именно взять, читается каждым по-своему и приводит к переделке после первого показа.

ТЗ для лендинга, многостраничного сайта и магазина: что меняется

Состав разделов остаётся тем же, меняется вес: на лендинге главное — блоки и формы, в магазине — данные и процессы.

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

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

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

Как мы в PIXONA составляем ТЗ вместе с заказчиком

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

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

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

В базовый состав входит то, что выше перечислено как разделы задания: прототип, дизайн, вёрстка с мобильной версией, формы заявок, Яндекс Метрика, базовое SEO, юридическая часть по 152-ФЗ, запуск и передача доступов. Остальное — например, наполнение каталога или фотосъёмку — выносим отдельными строками сметы, а не прячем в «под ключ». Платформу выбираем под задачу: работаем и на конструкторах, и на собственном коде, поэтому в наших заданиях не бывает строки «административная панель разработчика».

Поддержка после запуска идёт без обязательной абонентской платы: разово по часам или помесячно. Порядок работы по этапам показан в блоке «Как работаем» на главной.

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

Вопросы и ответы

Сколько страниц должно быть в техническом задании на сайт?

Ориентиры такие: лендинг 3⁠–⁠8 страниц, многостраничный сайт 10⁠–⁠25, интернет-магазин 25⁠–⁠60. Но объём — не показатель качества, поэтому проверяйте не число страниц, а наличие способа проверки у каждого требования, раздела «что не входит в работу» и сроков по этапам.

Кому принадлежат права на сайт после сдачи?

По п. 1 ст. 1296 ГК РФ исключительное право на произведение, созданное по договору, принадлежит заказчику, если договором не предусмотрено иное. Именно эту оговорку используют, когда оставляют код у исполнителя. Поэтому проверьте раздел договора про права и убедитесь, что код, макеты и тексты передаются вам, а не выдаются лицензией. Лицензии на шрифты и стоковые фотографии вместе с сайтом не передаются — их оформляют отдельно.

Что делать, если студия просит доплату со словами «этого не было в ТЗ»?

Сначала проверьте, действительно ли этого нет в тексте. Если требование в задании есть, работа входит в твёрдую цену: по п. 6 ст. 709 ГК подрядчик не вправе требовать её увеличения, даже если объём оказался больше ожидаемого. Если требования нет, доплата обоснована, и вопрос только в оценке — просите расчёт в часах и оформляйте допсоглашением. Чтобы такие разговоры были редкими, порядок изменений прописывают в самом ТЗ заранее.

Соберём ТЗ под ваш проект

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

Читайте также

• Как сделать сайт с нуля самому: пошаговая инструкция и бюджет
• Структура сайта: какие страницы нужны и как их разложить
• Этапы создания сайта: что происходит на каждом и сколько длится
• Бриф на разработку сайта: какие вопросы в нём и как отвечать
• Конструктор или код: как выбрать и не переплатить