Техническое задание на разработку сайта: структура и шаблон

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

Что такое техническое задание на разработку сайта#

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

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

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

Зачем нужно техническое задание сайту#

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

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

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

Из каких разделов состоит структура ТЗ#

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

Раздел ТЗ	Что фиксирует	Почему без него рискованно
Цели и аудитория	Задачу сайта и портрет пользователя	Дизайн и контент делаются «на вкус», а не под задачу
Структура сайта	Карту страниц и связи между ними	Появляются страницы-сироты и нелогичная навигация
Функционал	Формы, фильтры, интеграции, личный кабинет	Забытая функция всплывает после сдачи как доработка за отдельную смету
Технические требования	CMS, хостинг, скорость, адаптивность	Сайт формально работает, но не проходит проверку по факту
Контент	Кто и в каком объёме пишет тексты	Пустые страницы к моменту запуска
SEO-требования	Метатеги, микроразметку, ЧПУ	Сайт запускается без базовой SEO-совместимости
Дизайн	Стиль, референсы, обязательные элементы	Бесконечные правки «на вкус» без критерия остановки
Сроки и приёмка	Этапы и критерии готовности	«Готово» определяет подрядчик, а не заказчик

Каждый раздел стоит закрывать конкретикой: не «сайт должен быть быстрым», а измеримым порогом со ссылкой на то, как его проверять, а не оценкой на глаз.

Как описать цели проекта и аудиторию сайта#

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

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

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

Как прописать функционал и структуру страниц#

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

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

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

Какие технические требования включать в ТЗ#

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

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

Также в ТЗ имеет смысл заранее указать требования к структурированным данным: без этого пункта разметку schema.org на сайте, скорее всего, никто не добавит, потому что визуально сайт будет выглядеть готовым и без неё. Какие типы разметки нужны и зачем — в статье про структурированные данные schema.org.

Как задать требования к дизайну и контенту#

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

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

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

Какие SEO-требования внести в техзадание#

SEO-требования в техническом задании фиксируют то, что нельзя добавить в сайт постфактум без переделки: структуру URL, метатеги, микроразметку, файлы robots.txt и sitemap.xml, правила формирования заголовков страниц. Если эти пункты не прописаны заранее, сайт запускается без базовой SEO-совместимости, и её приходится встраивать в уже готовый код.

В разделе указывают требования к человекопонятным URL, к уникальным title и description на каждой странице шаблона, к наличию системы для управления этими полями без правки кода. Отдельно стоит закрепить, что структура сайта строится от семантического ядра, а не от произвольного набора страниц, — как это сделать, описано в статье про сбор семантического ядра.

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

Как прописать сроки и критерии приёмки#

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

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

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

Частые ошибки при составлении технического задания#

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

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

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

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

Источники#

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

• Google Search Central — стартовое руководство по SEO
• Schema.org — спецификация структурированных данных
• web.dev — руководства по производительности сайтов