ТЗ для сайта пример: готовый образец, структура и чек-лист

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

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

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

Особенно пример ТЗ спасает в таких ситуациях:

• Когда заказчик не знает, что вообще писать в ТЗ. Пустой лист пугает больше, чем плохой черновик. Пример даёт каркас: какие разделы обязательны, какие формулировки проверяемы, где обычно теряются сроки.
• Когда сайт делают несколько подрядчиков. Дизайнер, копирайтер, разработчик, SEO-специалист, контент-менеджер — каждому нужен общий язык. Пример ТЗ помогает не передавать требования устно и не тереться о разные трактовки.
• Когда запуск привязан к рекламе, выставке, сезону или релизу товара. В таких проектах нельзя обнаружить проблему с формой, скоростью или доступами за день до старта. Пример показывает, какие точки контроля нужно заложить заранее.
• Когда идёт редизайн или перенос старого сайта. Нужно сохранить SEO-позиции, URL, контент, заявки, интеграции и историю. Без примера легко забыть про редиректы, метатеги, микроразметку и доступы.
• Когда исполнитель просит «просто ТЗ», а заказчик мыслит желаниями. Пример переводит фразы «современно», «удобно», «как у конкурентов» в конкретные страницы, сценарии, размеры, форматы и критерии приёмки.

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

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

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

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

1. Сайт — это система сценариев, а не набор страниц

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

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

2. Пример ТЗ нельзя копировать дословно

Частая ошибка: найти чужое ТЗ, подставить название компании и отдать разработчику. Но у разных сайтов разные ограничения: один работает на заявки, другой на продажи, третий на доверие к бренду, четвёртый на SEO-трафик. Пример должен быть адаптивным: сохранять структуру, но менять объём, приоритеты и критерии приёмки.

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

3. Инфраструктура и доступы часто выпадают из ТЗ

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

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

4. Контент определяет срок сильнее, чем дизайн

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

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

5. AI ускоряет черновики, но не снимает ответственность

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

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

Структура ТЗ для сайта

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

1. Цель: зачем нужен сайт

Цель должна быть сформулирована не как «сделать современный сайт», а как измеримое бизнес-действие. Например: «получать не менее 50 заявок в месяц из органического поиска», «обеспечить запись на консультацию через форму и Telegram», «запустить каталог с оплатой и доставкой», «перенести старый сайт без потери позиций по 30 ключевым запросам».

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

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

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

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

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

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

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

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

• кто пишет тексты: заказчик, копирайтер, AI с последующей редактурой;
• сколько страниц, товаров, статей, кейсов, отзывов;
• нужны ли фото, иллюстрации, видео, схемы, инфографика;
• в каком формате передаётся контент: 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 такие договорённости удобно фиксировать в чате заказа: переписка имеет силу ТЗ и помогает отделить правку от новой задачи.

Готовый пример ТЗ

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

Проект: корпоративный сайт компании по монтажу инженерных систем.

Цель: получать не менее 40 квалифицированных заявок в месяц из органического поиска и рекламы, сократить время первичной обработки заявки до 15 минут за счёт интеграции с CRM.

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

Тип сайта: корпоративный сайт с каталогом услуг, кейсами, блогом и формой заявки. Без личного кабинета и онлайн-оплаты на первом этапе.

Структура страниц:

• главная: оффер, преимущества, услуги, кейсы, форма заявки, контакты;
• услуги: 6 страниц, каждая с описанием, этапами работ, ценами «от», FAQ и формой;
• кейсы: 10 карточек с фильтром по типу объекта и региону;
• о компании: команда, лицензии, документы, история, вакансии;
• блог: список статей, карточка статьи, рубрики, поиск;
• контакты: карта, реквизиты, форма, телефоны, email, мессенджеры;
• служебные: 404, политика конфиденциальности, согласие на обработку данных, карта сайта.

Функционал:

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

Дизайн:

• стиль: сдержанный, технический, вызывающий доверие; без кричащих градиентов и «стартаперской» агрессии;
• использовать фирменный синий, тёмно-серый и белый фон;
• крупная типографика, понятная иерархия, много воздуха;
• обязательна мобильная версия и адаптив под планшеты;
• кнопка заявки должна быть заметной, но не агрессивной;
• референсы: структура и плотность блоков как на сайтах X и Y; не нужен тёмный неоновый стиль как на Z.

Контент:

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

SEO и аналитика:

• ЧПУ, метатеги title/description для всех страниц;
• микроразметка Organization, Service, FAQPage, BreadcrumbList;
• sitemap.xml, robots.txt, canonical, редиректы со старого сайта;
• подключение Яндекс.Метрики и Google Analytics 4;
• события: отправка формы, клик по телефону, открытие калькулятора, скачивание файла.

Технические требования:

• CMS: WordPress или согласованная альтернатива с удобной админкой;
• хостинг и домен оформляются на заказчика;
• HTTPS обязателен;
• скорость главной: LCP до 2,5 сек на мобильном 4G;
• резервные копии ежедневно, хранение 14 дней;
• защита форм от спама, ограничение попыток входа в админку;
• поддержка основных браузеров: Chrome, Safari, Firefox, Edge последних двух версий.

Интеграции:

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

Этапы и сроки:

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

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

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

Передача: доступы к домену, хостингу, CMS, FTP, базе данных, почте, CRM; исходники дизайна в Figma; архив проекта; инструкция администратора; список использованных плагинов и лицензий; акт приёмки.

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

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

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

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

• Все согласованные страницы существуют и открываются без ошибок. Нет пустых ссылок, битых изображений, 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% за вывод: прозрачные условия без удержания при выводе средств.
• Доработки бесплатно до соответствия ТЗ: если сайт не соответствует согласованным требованиям, исполнитель дорабатывает результат.
• Договорённости в чате имеют силу ТЗ: всё, что вы обсудили по страницам, интеграциям, срокам, доступам и правкам, фиксируется в переписке и защищает обе стороны.

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

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

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

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