Краткий ответ: техническое задание на сайт — это рабочий документ, который описывает цель проекта, структуру страниц, функции, контент, SEO-требования, интеграции, этапы разработки и критерии приемки. Хорошее ТЗ снижает риск переделок, помогает точнее рассчитать стоимость и делает результат предсказуемым для заказчика и подрядчика.
Если заказать сайт без понятного ТЗ, проект быстро превращается в цепочку уточнений: “а это имелось в виду?”, “а эта форма должна отправлять письмо?”, “а кто пишет тексты?”, “а почему в мобильной версии блок выглядит иначе?”. Формально сайт может быть сделан, но сроки, бюджет и качество будут зависеть от догадок. Поэтому техническое задание — не бюрократия, а инструмент управления результатом.
Ниже — практическая структура ТЗ на сайт, которую можно использовать перед разработкой лендинга, сайта-визитки, корпоративного сайта, каталога или интернет-магазина. Материал написан с позиции разработки, SEO и приемки проекта: что действительно нужно описать, а что лучше оставить для прототипа, дизайна или брифа.
Что такое техническое задание на сайт
Техническое задание на сайт — это документ, где фиксируются требования к будущему сайту: зачем он создается, из каких страниц состоит, какие функции должны работать, какие материалы нужны, какие технические и SEO-настройки обязательны, как будет проверяться готовность проекта.
В идеале ТЗ отвечает на три вопроса: что делаем, зачем это нужно бизнесу и по каким критериям считаем задачу выполненной. Если хотя бы один из этих пунктов отсутствует, у заказчика и подрядчика появляются разные ожидания.
Бриф, прототип и ТЗ: в чем разница
| Документ | Задача | Когда нужен |
|---|---|---|
| Бриф | Собрать вводные: бизнес, аудитория, цели, конкуренты, пожелания | До оценки проекта |
| Прототип | Показать логику страниц, блоки, сценарии пользователя | Перед дизайном |
| Техническое задание | Зафиксировать требования, функции, SEO, интеграции и приемку | Перед разработкой и подписанием объема работ |
Бриф помогает понять задачу, прототип показывает будущую структуру, а ТЗ превращает договоренности в проверяемые требования. Для простого лендинга эти документы могут быть короче, но логика остается той же: сначала понять бизнес-задачу, затем спроектировать страницу, потом зафиксировать требования.
Когда ТЗ обязательно, а когда достаточно краткого описания
Подробное ТЗ особенно важно, если у проекта есть личный кабинет, каталог, фильтры, онлайн-оплата, интеграции с CRM, импорт товаров, мультиязычность, нестандартные формы, SEO-структура под десятки страниц или несколько ролей пользователей.
Для небольшого сайта-визитки иногда достаточно расширенного брифа, структуры страниц и списка функциональных требований. Но даже в этом случае нужно зафиксировать базовые вещи: количество страниц, формы, адаптивность, SEO-настройки, кто готовит контент, сроки и критерии приемки.
Структура ТЗ на сайт: обязательные разделы
1. Цель сайта и бизнес-задача
Начните не со списка блоков, а с цели. Например: получать заявки на разработку сайта, продавать товары, показывать портфолио, объяснять сложную услугу, собирать лиды из рекламы, поддерживать SEO-продвижение. Цель влияет на структуру, тексты, формы, аналитику и приоритеты разработки.
Хорошая формулировка: “Сайт должен приводить заявки на создание сайтов под ключ из органического поиска и контекстной рекламы, показывать услуги, портфолио, отзывы и давать пользователю быстрый способ отправить запрос”. Плохая формулировка: “Нужен современный красивый сайт”.
2. Целевая аудитория и сценарии пользователей
Опишите, кто будет пользоваться сайтом: владелец бизнеса, маркетолог, частный клиент, закупщик, HR-специалист, постоянный покупатель. Для каждого типа пользователя стоит указать главный сценарий: сравнить услуги, узнать цену, посмотреть кейсы, скачать прайс, оставить заявку, оплатить товар.
Этот блок помогает не перегружать сайт лишними элементами. Если главный сценарий — заявка на расчет, форма и CTA должны быть заметны. Если пользователь выбирает среди кейсов, портфолио и фильтры становятся важнее декоративных блоков.
3. Структура страниц и URL
В ТЗ нужно перечислить все страницы первого запуска: главная, услуги, отдельные посадочные страницы, портфолио, отзывы, блог, контакты, политика конфиденциальности. Для SEO-проектов желательно сразу указать будущие URL, чтобы избежать хаоса после публикации.
Например, для сайта веб-студии логично связать блог с коммерческими страницами: услуги по разработке сайтов, создание сайта на WordPress, создание интернет-магазина, портфолио.
4. Функциональные требования
Функции нужно описывать так, чтобы их можно было проверить. Не “сделать удобную форму”, а “форма содержит поля имя, телефон, комментарий; обязательные поля — имя и телефон; после отправки заявка уходит на email и в Telegram; пользователь видит сообщение об успешной отправке”.
- Формы заявок и обратной связи.
- Фильтры, поиск, сортировка.
- Каталог товаров или услуг.
- Корзина, оплата, доставка.
- Личный кабинет.
- Интеграция с CRM, email, Telegram, аналитикой.
- Мультиязычность.
- Админ-панель и роли пользователей.
5. Контент и материалы
Один из частых провалов проекта — сайт технически готов, но нет текстов, фотографий, логотипов, отзывов, описаний услуг и юридических материалов. Поэтому в ТЗ нужно указать, кто готовит контент, в каком формате он передается и кто отвечает за финальную редактуру.
Если контент готовит подрядчик, это должно быть отдельным пунктом в смете. Если контент готовит заказчик, студия должна дать структуру: какие тексты нужны для каждого блока, какие изображения нужны, какие характеристики товаров обязательны.
6. SEO-требования
SEO нельзя оставлять “на потом”. Уже на этапе ТЗ нужно указать требования к индексируемости, URL, мета-тегам, заголовкам, микроразметке, скорости, внутренней перелинковке и изображениям. Это особенно важно, если сайт должен получать трафик из Google, а не только работать как визитка для рекламы.
- У каждой важной страницы один H1 и логичная структура H2-H3.
- Title и description задаются вручную или через SEO-плагин.
- Служебные страницы закрываются от индексации.
- Canonical настроен без конфликтов.
- Создаются robots.txt и sitemap.xml.
- Изображения имеют понятные alt и оптимальный вес.
- Для статей, услуг и FAQ используется Schema.org.
Подход Google к качеству контента строится вокруг полезности для людей, опыта, экспертности и доверия. Поэтому ТЗ должно учитывать не только технические поля, но и качество будущего содержания: кто автор, какие источники используются, как подтверждается информация и чем страница полезнее похожих материалов.
7. Дизайн и адаптивность
В ТЗ не нужно детально рисовать дизайн, если есть отдельный этап макетов. Но важно указать требования: адаптивность для мобильных устройств, поддерживаемые разрешения, наличие дизайн-системы, состояния кнопок и форм, требования к доступности и читаемости.
Отдельно фиксируйте, что мобильная версия не должна быть вторичной. Для многих ниш большая часть трафика приходит со смартфонов, поэтому формы, меню, телефоны, карточки и CTA должны быть удобны именно на мобильном экране.
8. Производительность и Core Web Vitals
Сайт может быть красивым, но проигрывать из-за медленной загрузки. В ТЗ стоит указать требования к оптимизации изображений, lazy loading, кешированию, шрифтам, критическому CSS и ограничению лишних скриптов. Это влияет на пользовательский опыт и может мешать SEO-росту.
Для большинства бизнес-сайтов разумный минимум: легкие изображения WebP/AVIF, сжатие, кеширование, отсутствие тяжелых видео на первом экране без необходимости, отложенная загрузка сторонних скриптов и проверка мобильной скорости перед запуском.
9. Интеграции и аналитика
Если сайт должен передавать заявки в CRM, Telegram, email или рекламные системы, это нужно описать заранее. Укажите, какие поля передаются, куда именно, что происходит при ошибке отправки, кто получает уведомления и какие цели аналитики настраиваются.
Минимальный набор для запуска: Google Analytics или другая аналитика, события отправки форм, клики по телефону/мессенджерам, базовые цели, защита форм от спама и проверка корректности данных после публикации.
10. Критерии приемки
Критерии приемки — самая недооцененная часть ТЗ. Они показывают, как понять, что работа завершена. Без них спор о “готово/не готово” превращается в субъективную оценку.
| Что проверяем | Критерий приемки |
|---|---|
| Страницы | Все страницы из структуры созданы и доступны по согласованным URL |
| Формы | Заявки приходят в указанные каналы, ошибки обработаны |
| Мобильная версия | Нет наложений, горизонтального скролла и нечитаемых элементов |
| SEO | Title, description, H1, canonical, sitemap и robots настроены |
| Скорость | Изображения оптимизированы, кеширование включено, нет критичных блокирующих ресурсов |
| Контент | Все тексты, изображения, контакты и юридические страницы заполнены |
Пример структуры ТЗ для разных типов сайтов
| Тип сайта | Что обязательно описать | Особый риск |
|---|---|---|
| Лендинг | Оффер, блоки, форма, CTA, аналитика, мобильная версия | Много красоты, мало смысла и конверсии |
| Сайт услуг | Структура услуг, география, портфолио, отзывы, SEO-страницы | Каннибализация запросов и дубли страниц |
| Каталог | Категории, карточки, фильтры, поиск, заявки | Слабая структура фильтров и пустые карточки |
| Интернет-магазин | Товары, оплата, доставка, остатки, CRM, юридические страницы | Ошибки интеграций и сложная приемка |
Если вы пока не уверены, какой формат подходит бизнесу, полезно сначала сравнить варианты: лендинг, сайт услуг, каталог или интернет-магазин. От типа сайта зависит глубина ТЗ и бюджет разработки.
Главные ошибки при составлении ТЗ
- Описывать дизайн вместо результата. Цвета и стиль важны, но бизнес-цель важнее.
- Не фиксировать контент. Без текстов и изображений запуск часто откладывается.
- Забывать про SEO. Потом приходится переделывать URL, заголовки и структуру.
- Не описывать формы и уведомления. Заявки могут теряться или приходить не туда.
- Не указывать критерии приемки. Проект сложно закрыть без понятного чек-листа.
- Писать слишком абстрактно. “Удобно”, “красиво”, “современно” нужно переводить в проверяемые требования.
Как ТЗ влияет на стоимость сайта
Чем точнее ТЗ, тем точнее оценка. Подрядчик видит количество страниц, сложность дизайна, список функций, интеграции, объем контента и требования к SEO. Это снижает риск “доплат за очевидные вещи”, потому что очевидное для заказчика не всегда очевидно для разработчика.
При этом ТЗ не должно раздувать проект. Иногда после составления требований становится понятно, что часть функций лучше перенести на второй этап: сначала запустить сайт, собрать данные, а потом развивать личный кабинет, фильтры или дополнительные посадочные страницы.
Готовый чек-лист ТЗ на сайт
- Цель сайта и ожидаемый результат.
- Описание целевой аудитории и сценариев пользователей.
- Список страниц и предполагаемые URL.
- Функции сайта и логика форм.
- Контент: тексты, изображения, документы, отзывы, кейсы.
- SEO: title, description, H1-H3, canonical, robots, sitemap, schema, alt.
- Дизайн, адаптивность, требования к мобильной версии.
- Производительность: изображения, кеш, скрипты, шрифты.
- Интеграции: CRM, email, Telegram, аналитика, оплата.
- Админ-панель и права доступа.
- Безопасность, резервные копии, обновления.
- Критерии приемки и порядок правок.
Кто должен писать ТЗ
Лучший вариант — совместная работа заказчика и подрядчика. Заказчик знает бизнес, клиентов, продукты и ограничения. Подрядчик знает, как перевести это в структуру сайта, функции, SEO-требования и техническую реализацию. Если ТЗ пишет только заказчик, в нем часто не хватает технических деталей. Если только подрядчик — может не хватить бизнес-контекста.
Перед стартом проекта можно подготовить черновик: цель сайта, список страниц, примеры конкурентов, пожелания, материалы и ограничения. А затем вместе с веб-студией превратить его в рабочее задание. Если подрядчик не помогает уточнять требования, это повод внимательнее проверить процесс работы. Об этом подробнее написано в статье как выбрать веб-студию для создания сайта.
Источники и ориентиры качества
При подготовке ТЗ полезно учитывать не только требования разработки, но и рекомендации поисковых систем. Google отдельно подчеркивает важность полезного контента, созданного для людей, корректной структурированной разметки и понятного описания изображений. Эти принципы помогают сделать сайт не просто опубликованным, а готовым к дальнейшему росту.
- Google Search Central: создание полезного контента
- Google Search Central: Article structured data
- Google Search Central: рекомендации для изображений
- Schema.org: FAQPage
FAQ
Можно ли заказать сайт без технического задания?
Можно, если проект очень простой, но риск переделок будет выше. Даже для небольшого сайта лучше зафиксировать структуру, функции, контент, SEO-настройки и критерии приемки.
Чем ТЗ отличается от брифа?
Бриф собирает вводные о бизнесе и задаче, а ТЗ фиксирует конкретные требования к сайту: страницы, функции, интеграции, SEO, адаптивность и приемку.
Кто должен готовить тексты для сайта?
Это нужно решить до старта. Тексты может готовить заказчик, подрядчик или редактор, но в ТЗ важно указать ответственного, сроки и формат передачи материалов.
Нужно ли включать SEO в техническое задание?
Да. SEO-требования лучше закладывать до разработки: URL, заголовки, meta tags, canonical, robots.txt, sitemap, schema, скорость и alt изображений.
Вывод
Техническое задание на сайт помогает превратить идею в понятный проект: с целями, структурой, функциями, SEO-требованиями, контентом и критериями приемки. Чем точнее ТЗ, тем меньше случайных решений, споров и переделок. Если вы планируете разработку сайта и хотите заранее оценить структуру, сроки и стоимость, можно начать с консультации и подготовки требований вместе с командой Flammaweb.
