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

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

Что такое ТЗ для создания сайта и когда оно спасает

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

Такое ТЗ особенно нужно, когда сайт создаётся не «для присутствия в интернете», а для решения задачи:

• Запуск нового продукта или услуги. Сайт должен объяснять ценность, собирать заявки и не терять пользователей на первом экране.
• Переход с старого сайта. Нужны редиректы, сохранение SEO-позиций, перенос контента, форм и аналитики.
• Интеграция с CRM, оплатой, складом или 1С. Без описания данных и сценариев связи сайт остаётся красивой витриной без процесса.
• Рекламный трафик. Если на сайт пойдёт платный трафик, важны скорость, мобильная версия, формы, аналитика и понятный CTA.
• Командная работа. Когда в проекте участвуют маркетолог, дизайнер, копирайтер, разработчик и менеджер, ТЗ синхронизирует всех и снижает число «я думал, это входит».

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

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

Специфика ниши создания сайта: 5 особенностей, которые влияют на ТЗ

Создание сайта отличается от разработки приложения, дизайна логотипа или написания текстов. У него есть свои ловушки, которые нужно закладывать в ТЗ заранее.

1. Сайт — это сборка разных работ, а не один артефакт

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

2. Инфраструктура важнее, чем кажется на старте

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

3. Зависимости между этапами создают срывы сроков

Нельзя делать вёрстку до утверждённого дизайна, наполнять сайт до готовности текстов, настраивать интеграции без доступов к CRM, запускать рекламу без аналитики. ТЗ должно содержать не просто дедлайн, а порядок: прототип → дизайн → черновая вёрстка → контент → интеграции → тестирование → предбоевой стенд → запуск. Без этого проект превращается в ожидание «пока все всё сделают».

4. Приёмка сайта должна быть сценарной, а не визуальной

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

5. AI в 2026 году ускоряет создание, но не снимает ответственность

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

Структура ТЗ для создания сайта

1. Цель: зачем создаётся сайт

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

• собирать не менее 50 заявок в месяц из органического поиска;
• обеспечить запись на консультацию через форму и Telegram-бота;
• запустить интернет-магазин с оплатой картой и доставкой по РФ;
• перенести старый сайт без потери позиций по 30 ключевым запросам;
• сделать корпоративный сайт для тендеров и партнёрских писем.

Если цель размыта — «увеличить продажи», «стать современнее», «выглядеть дорого» — исполнитель не сможет предложить адекватный объём работ. Лучше всего работает формула: «Сайт нужен, чтобы [аудитория] совершила [действие] в [срок/канал]». Например: «Чтобы владелец малого бизнеса за 2 минуты понял пользу сервиса и оставил заявку на демо».

2. Требования: функциональные, технические и контентные

Требования делятся на несколько групп. В ТЗ их лучше не смешивать, а разложить по блокам.

Функциональные требования — что сайт должен уметь:

• формы заявки с обязательными полями и отправкой на почту/в CRM/в Telegram;
• калькулятор стоимости;
• личный кабинет, корзина, оплата, статусы заказа;
• фильтры каталога, поиск, сравнение товаров;
• многоязычность, роли пользователей, админка для редакторов.

Нефункциональные требования — как сайт должен работать:

• адаптив под мобильные, планшеты и десктопы;
• скорость: например, LCP до 2,5 сек, общая загрузка главной до 3 сек на 4G;
• доступность: читаемые шрифты, контраст, работа с клавиатуры, alt-тексты;
• безопасность: HTTPS, защита форм от спама, ограничение попыток входа, резервные копии;
• SEO-база: ЧПУ, метатеги, sitemap, robots.txt, микроразметка, канонические ссылки.

Контентные требования — чем сайт наполняется:

• кто пишет тексты: заказчик, копирайтер, AI с последующей редактурой;
• сколько страниц, сколько товаров, сколько статей, сколько фото;
• нужны ли УТП, кейсы, отзывы, FAQ, сертификаты, вакансии;
• в каком формате передаётся контент: таблица, DOCX, Figma, CMS.

Для дизайна и структуры страниц удобнее отдельно использовать ТЗ для сайта: структура страниц, дизайн и админка. Оно помогает не потерять детали по макетам, адаптиву и управлению контентом.

3. Объём: что входит и что не входит

Самая частая причина конфликтов — разное понимание объёма. В ТЗ нужно прямо перечислить:

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

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

4. Сроки: календарный план и точки контроля

Для создания сайта одного дедлайна «через месяц» недостаточно. Нужен план по этапам:

• сбор информации и утверждение ТЗ;
• прототип и структура;
• дизайн ключевых страниц;
• вёрстка и настройка CMS;
• подготовка и перенос контента;
• интеграции и тестирование;
• предбоевой стенд;
• запуск и передача доступов.

Укажите, кто и в какой срок согласовывает каждый этап. Например: «заказчик согласует прототип в течение 2 рабочих дней, иначе срок сдвигается на время задержки». Это защищает исполнителя от бесконечных пауз, а заказчика — от срыва запуска из-за одной незакрытой задачи.

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

5. Критерии приёмки: как понять, что сайт готов

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

• пользователь с мобильного может отправить заявку за 3 поля и получить подтверждение;
• данные заявки дублируются в CRM с корректными статусами;
• главная грузится не дольше 3 секунд на тестовом канале;
• все формы защищены от спама;
• 404-страница работает и ведёт на главную;
• редиректы со старого сайта настроены без цепочек и ошибок;
• метатеги, sitemap и robots.txt заполнены;
• админка позволяет менять тексты, картинки и порядок блоков без разработчика.

Хорошо, если в ТЗ будет таблица тест-кейсов: действие → ожидаемый результат → статус. Тогда приёмка превращается в чек-лист, а не в субъективный разбор «мне не нравится кнопка».

6. Формат передачи: что заказчик получает после запуска

Сайт нельзя принять, если не переданы активы. В ТЗ нужно зафиксировать состав передачи:

• доступы к домену, хостингу, CMS, FTP/SFTP, базе данных, почте, CRM, платёжной системе;
• исходники дизайна: Figma, Sketch, PSD — если это согласовано;
• код репозитория или архив проекта с инструкцией по развёртыванию;
• документация: как добавлять страницы, товары, статьи, менять баннеры;
• инструкция по резервным копиям и восстановлению;
• акт приёмки-передачи и список оставшихся рисков, если они есть;
• гарантийные обязательства: срок, что входит, как обращаться.

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

7. Правки: что входит, а что становится новой задачей

В создании сайта правки неизбежны, но их нужно разграничить. В ТЗ укажите:

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

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

Критерии приёмки результата создания сайта

Сайт можно принимать, если выполнены измеримые условия. Ниже — базовый набор критериев, который подходит для большинства проектов:

• Все согласованные страницы существуют и открываются без ошибок. Нет пустых ссылок, битых изображений, 404 в меню, дублей заголовков.
• Ключевые сценарии работают. Заявка отправляется, письмо уходит, данные попадают в CRM, товар добавляется в корзину, оплата проходит в тестовом режиме, запись создаётся.
• Мобильная версия удобна. Текст читается без масштабирования, кнопки доступны для пальца, формы не «уезжают», меню не перекрывает контент.
• Скорость соответствует требованиям. Например, главная грузится до 3 секунд на тестовом соединении, LCP до 2,5 сек, нет блокирующих ресурсов без необходимости.
• SEO-база настроена. ЧПУ, title/description, H1, alt, sitemap, robots.txt, canonical, микроразметка, редиректы.
• Безопасность обеспечена. HTTPS работает, формы защищены от спама, админка не имеет дефолтных паролей, настроены резервные копии.
• Админка позволяет управлять контентом. Редактор может менять тексты, картинки, порядок блоков, публиковать статьи и товары без доступа к коду.
• Доступы и документация переданы. Заказчик получил все логины, права, исходники, инструкцию и контакты поддержки.
• Тестирование пройдено. Есть акт или чек-лист: что проверяли, какие браузеры и устройства, какие ошибки устранены, какие остались и согласованы как некритичные.
• Запуск не зависит от подрядчика. Домен, хостинг, почта и ключевые сервисы оформлены или передаются заказчику, критичные доступы не остаются только у исполнителя.

Вопросы для уточнения до старта

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

• Какую бизнес-задачу решает сайт и по какой метрике мы поймём успех?
• Кто целевая аудитория и с каких устройств она будет заходить?
• Какие страницы обязательны для запуска, а какие можно отложить на второй этап?
• Есть ли старый сайт, который нужно перенести, и какие URL критично сохранить?
• Какие интеграции нужны: CRM, телефония, оплата, доставка, 1С, email, мессенджеры?
• Кто предоставляет тексты, фото, видео, кейсы, отзывы и товары?
• Нужна ли многоязычность, личные кабинеты, роли, сложный каталог?
• Какие требования к скорости, SEO, безопасности и доступности?
• Кто покупает домен, хостинг, SSL, почту, лицензии на шрифты и плагины?
• Какой стек предпочтителен: WordPress, Tilda, самописный, Headless, 1С-Битрикс?
• Как будет проходить приёмка: по этапам или один раз в конце?
• Сколько кругов правок входит и что считается новой задачей?
• Нужна ли поддержка после запуска, на какой срок и в каком объёме?
• Кто принимает финальное решение: владелец, маркетолог, IT-директор, юрист?

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

Чек-лист готовности ТЗ

Перед публикацией заказа или стартом работ пройдитесь по короткому чек-листу. Если хотя бы два пункта не закрыты, ТЗ лучше дописать.

• Цель сайта сформулирована через действие пользователя и метрику.
• Описаны страницы, функционал, интеграции, роли и контентные объёмы.
• Указаны технические требования: скорость, адаптив, SEO, безопасность, бэкапы.
• Зафиксировано, кто предоставляет домен, хостинг, тексты, фото и доступы.
• Есть календарный план с этапами согласования и ответственностью за задержки.
• Прописаны критерии приёмки в виде тест-кейсов, а не общих слов.
• Определён состав передачи: доступы, исходники, документация, обучение.
• Разведены правки и новые задачи, согласован порядок изменений.

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

Как заказать создание сайта на Workink

На Workink задача по созданию сайта публикуется в категории «Техническое задание (ТЗ)». Это удобно, когда нужно не просто найти дизайнера или разработчика, а собрать понятное задание: цель, функционал, этапы, критерии приёмки, передачу доступов и условия правок.

Платформа снижает типовые риски веб-проектов:

• Безопасная сделка: деньги находятся в резерве до приёмки работы. Вы платите за результат, а не за обещание запустить сайт.
• Комиссия 11% за заказ и 0% за вывод: прозрачные условия без удержания при выводе средств.
• Доработки бесплатно до соответствия ТЗ: если сайт не соответствует согласованным требованиям, исполнитель дорабатывает результат.
• Договорённости в чате имеют силу ТЗ: всё, что вы обсудили по страницам, интеграциям, срокам, доступам и правкам, фиксируется в переписке и защищает обе стороны.

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

Найти исполнителя Разместить заказ Защита покупателей

Полезные материалы по теме

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