Техническое задание на разработку сайта и интернет-магазина: структура, образец и пример

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

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

В SEO-Evolution мы обычно советуем начинать не с дизайна, а с описания бизнес-логики: что сайт должен продавать или объяснять, откуда должны приходить клиенты, какие действия пользователя являются целевыми, кто обрабатывает заявки, какие страницы должны продвигаться в Google и что будет считаться готовым результатом.

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

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

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

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

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

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

Зачем нужно ТЗ перед разработкой

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

Для заказчика ТЗ на разработку сайта полезно по нескольким причинам:

• становится понятно, за что именно он платит;

• легче сравнивать предложения разных подрядчиков;

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

• проще контролировать работу разработчиков;

• появляется основа для тестирования и приемки готового сайта;

• легче отделить первый запуск от будущих доработок.

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

Кто должен готовить ТЗ для сайта

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

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

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

Что подготовить перед написанием ТЗ

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

• Описание бизнеса. Чем занимается компания, какие товары или услуги продает, в каких регионах работает, кто ее клиенты.

• Цели сайта. Заявки, продажи, консультации, бронирования, регистрации, повторные покупки, подписки или поддержка офлайн-продаж.

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

• Текущие материалы. Логотип, брендбук, фото, тексты, каталог товаров, прайсы, документы, старый сайт, доступы к аналитике.

• Ограничения. Бюджет, желаемые сроки, нужные интеграции, обязательная CMS, особенности учета, юридические требования.

• Текущие проблемы. Если сайт уже существует, нужно понять, что именно не работает: структура, скорость, заявки, дизайн, SEO, аналитика, админпанель.

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

Как правильно описывать требования в ТЗ

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

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

Структура ТЗ на разработку сайта

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

1. Описание проекта

В первом разделе нужно коротко объяснить, какой сайт создается и какую задачу он должен решать. От описания проекта зависит структура, дизайн, функционал, контент и будущее продвижение.

В этом блоке стоит указать:

• тип сайта: корпоративный сайт, каталог, интернет-магазин, портал, сервис, лендинг;

• краткое описание бизнеса;

• основные товары или услуги;

• географию работы;

• языковые версии;

• главную цель сайта: заявки, продажи, бронирования, консультации, регистрации, подписки.

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

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

2. Цели сайта

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

Примеры целей:

• получать заявки из органического поиска и рекламы;

• продавать товары онлайн с оплатой на сайте;

• показать экспертность компании через кейсы, блог и страницы услуг;

• снизить нагрузку на менеджеров за счет автоматизации заказов;

• подготовить сайт к SEO-продвижению еще на этапе разработки.

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

3. Целевая аудитория

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

В ТЗ для сайта достаточно описать 2–4 основные группы пользователей:

• кто эти люди или компании;

• какую задачу они хотят решить;

• что для них важно при выборе;

• какие возражения могут возникать перед заявкой или покупкой;

• какие устройства они чаще используют.

Пример: для интернет-магазина мебели одна группа аудитории может искать недорогие решения с доставкой по Украине, вторая – мебель под конкретные размеры, третья – товары для офиса с безналичной оплатой. Для каждой группы могут быть разные фильтры, аргументы, блоки доверия и сценарии покупки.

4. Структура сайта

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

Для сайта услуг структура может выглядеть так:

• главная страница;

• страницы основных услуг;

• отдельные посадочные страницы под направления или города;

• о компании;

• кейсы;

• блог;

• контакты;

• служебные страницы: политика конфиденциальности, условия использования, страница 404.

Для интернет-магазина структура обычно шире:

• главная страница;

• каталог товаров;

• категории и подкатегории;

• страницы фильтров, если они нужны для SEO;

• карточка товара;

• корзина;

• оформление заказа;

• личный кабинет покупателя;

• доставка и оплата;

• обмен и возврат;

• акции;

• бренды;

• блог или советы;

• контакты.

Для структуры желательно сразу добавить примеры URL. Например: /catalog/ , /catalog/mebli/ , /catalog/mebli/stoly/ , /product/nazva-tovaru/ , /delivery/ , /payment/ , /blog/ . Это помогает разработчику, SEO-специалисту и контент-менеджеру одинаково понимать будущую архитектуру сайта.

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

5. Функциональные требования к сайту

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

Для обычного сайта в этом блоке могут быть такие пункты:

• формы заявок;

• клик по номеру телефона с мобильного;

• подписка на рассылку;

• фильтрация услуг или кейсов;

• поиск по сайту;

• мультиязычность;

• управление страницами через админпанель;

• загрузка документов, фото или видео.

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

Что добавить в ТЗ для интернет-магазина

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

Каталог товаров

Каталог товаров интернет-магазина нужно описывать через реальную структуру, а не общей фразой - нужен каталог. В ТЗ стоит указать:

• категории и подкатегории;

• основные характеристики товаров;

• фильтры и сортировку;

• бренды или производителей;

• наличие товаров;

• вариации: размер, цвет, объем, комплектация;

• условия показа товаров, которых нет в наличии;

• правила формирования URL для категорий, фильтров и товаров.

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

Карточка товара

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

• название товара;

• артикул или SKU;

• бренд;

• фото и видео;

• цена;

• старая цена, если есть скидка;

• наличие;

• срок доставки;

• краткое и полное описание;

• характеристики;

• вариации товара;

• гарантия;

• условия доставки и оплаты;

• отзывы;

• похожие или сопутствующие товары;

• кнопки добавления в корзину и быстрой покупки.

Для SEO и товарной выдачи также стоит предусмотреть микроразметку Product. Google рекомендует использовать структурированные данные, чтобы лучше понимать информацию о товаре, цене, наличии и отзывах. Детальные требования лучше проверять в официальной документации Google по Product structured data , потому что поддерживаемые свойства и требования могут меняться.

Корзина и оформление заказа

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

• добавлять товар в корзину;

• изменять количество;

• удалять позиции;

• видеть сумму заказа;

• видеть скидку или промокод;

• видеть стоимость доставки, если ее можно рассчитать до оформления;

• возвращаться к покупкам без потери товаров в корзине.

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

Оплата и доставка

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

Для доставки стоит прописать:

• службы доставки;

• расчет стоимости;

• выбор города и отделения;

• курьерскую доставку;

• самовывоз;

• ограничения по весу, региону или сумме заказа;

• передачу трек-номера покупателю.

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

Личный кабинет покупателя

Личный кабинет покупателя не всегда нужен на первом этапе. Если покупки разовые, иногда достаточно оформления без регистрации. Если же в магазине есть повторные заказы, бонусы, история покупок, B2B-клиенты или персональные цены, кабинет лучше прописать в ТЗ сразу.

В кабинете могут быть:

• личные данные покупателя;

• история заказов;

• статусы заказов;

• сохраненные адреса доставки;

• список желаний;

• бонусный баланс;

• повторение предыдущего заказа.

Админпанель и роли пользователей

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

Типовые роли пользователей в админпанели:

• администратор;

• контент-менеджер;

• менеджер заказов;

• маркетолог;

• SEO-специалист;

• бухгалтер или сотрудник, который работает с оплатами.

Для каждой роли стоит определить права доступа: кто может редактировать товары, кто видит заказы, кто меняет цены, кто управляет скидками, кто имеет доступ к настройкам сайта.

Импорт, экспорт и синхронизация товаров

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

Отдельно прописывают:

• формат файлов: CSV, XLSX, XML, YML или API;

• частоту обновления;

• источник данных;

• что делать с товарами, которых нет в новом файле;

• как обрабатывать ошибки импорта;

• нужно ли вести журнал изменений.

Если планируется синхронизация цен и остатков с учетной системой, это нельзя оставлять на потом. Интеграция интернет-магазина с CRM, 1С, ERP или складским учетом часто влияет на всю архитектуру проекта.

Интеграции в техническом задании

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

CRM лучше не оставлять одной строкой в стиле подключить CRM. Нужно зафиксировать, какие именно данные передаются, когда создается лид, кто видит заявку и что происходит, если CRM временно недоступна.

В ТЗ на разработку сайта или интернет-магазина стоит отдельно описать:

• CRM-систему;

• учетную систему;

• платежную систему;

• службы доставки;

• email- и SMS-сервисы;

• маркетплейсы;

• Google Merchant Center;

• Google Analytics 4 и Google Tag Manager;

• системы коллтрекинга или сквозной аналитики.

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

SEO в техническом задании

SEO на этапе разработки сайта дешевле и проще учесть сразу, чем переделывать структуру после запуска. Особенно это касается интернет-магазинов, где ошибки с URL, фильтрами, дублями, canonical, пагинацией и sitemap могут создать проблемы еще до начала продвижения.

В проектах SEO-Evolution мы стараемся согласовывать SEO-требования до старта разработки: структуру URL, мета-теги, индексацию фильтров, sitemap, robots.txt, редиректы и аналитику. Это дешевле, чем исправлять те же вещи после запуска, когда страницы уже попали в индекс.

В ТЗ стоит добавить отдельный блок SEO-требований:

• логичная структура URL;

• возможность редактировать Title, Description, H1;

• человекопонятные URL;

• canonical для страниц, где это нужно;

• настройка robots.txt;

• sitemap.xml для основных типов страниц;

• отдельные sitemap для товаров, категорий, статей или языковых версий, если сайт большой;

• микроразметка для организации, хлебных крошек, статей, товаров;

• корректные 404-страницы;

• 301-редиректы при изменении старых URL;

• возможность добавлять SEO-тексты там, где они действительно нужны;

• скорость загрузки и базовые требования к Core Web Vitals.

Для интернет-магазина SEO-требования должны быть еще точнее: структура категорий, правила индексации фильтров, мета-теги для интернет-магазина, шаблоны Title и Description для товаров, микроразметка Product, sitemap для товаров и категорий, логика работы страниц брендов. Google отдельно описывает подход к URL-структуре eCommerce-сайтов, и эти рекомендации лучше учитывать до запуска, а не после индексации ошибочных страниц. Рекомендации Google по URL для интернет-магазинов стоит использовать как одну из опор при подготовке ТЗ.

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

Если сайт уже существует

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

В такое ТЗ нужно добавить отдельный блок миграции:

• список важных старых URL;

• страницы, которые должны быть перенесены без изменения адресов;

• карту 301-редиректов для страниц, которые изменят URL;

• перенос Title, Description, H1 и основного контента;

• проверку старых страниц с трафиком в Google Search Console;

• перенос кодов аналитики, рекламных тегов и событий;

• проверку robots.txt, sitemap.xml, canonical и статусов страниц после запуска.

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

Аналитика и события

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

Для обычного сайта нужно определить:

• отправку форм;

• клики по телефону;

• клики по email;

• клики по мессенджерам;

• загрузку файлов;

• переход на страницы благодарности;

• события для рекламы.

Для интернет-магазина нужна аналитика электронной коммерции: просмотр товара, добавление в корзину, начало оформления заказа, выбор доставки, оплата, покупка. Google описывает рекомендуемые eCommerce-события в GA4 в своей документации, поэтому эти события лучше предусмотреть до программирования корзины и checkout. Документация GA4 по eCommerce-событиям помогает понять, какие именно действия нужно передавать в аналитику.

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

Дизайн, прототипы и мобильная версия

В разделе о дизайне не нужно описывать только цвета и шрифты. Важнее зафиксировать, какие страницы требуют прототипов, какие блоки должны быть на каждой странице и какие сценарии пользователя нужно продумать.

Для сайта услуг обычно нужны прототипы:

• главной страницы;

• страницы услуги;

• страницы кейса;

• статьи блога;

• контактов.

Для интернет-магазина дополнительно нужны прототипы каталога, категории, карточки товара, корзины, checkout, личного кабинета, страницы заказа и страницы результата оплаты.

В современном ТЗ также стоит прописать адаптивность. Google рекомендует responsive design как самый простой для реализации и поддержки подход для мобильных сайтов. Для бизнеса это тоже практично: один URL, одна страница, одна логика контента для разных устройств. Рекомендации Google по mobile-first indexing стоит учитывать при согласовании дизайна и верстки.

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

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

В этом разделе можно прописать:

• CMS или фреймворк, если есть четкое требование;

• требования к хостингу или серверу;

• поддержку актуальных версий браузеров;

• адаптивность для мобильных устройств;

• резервное копирование;

• логирование ошибок;

• защиту форм от спама;

• SSL-сертификат;

• контроль доступов к админпанели;

• обработку персональных данных;

• возможность дальнейшего масштабирования.

Для проектов с авторизацией, оплатой, личными кабинетами и персональными данными стоит отдельно прописать требования к безопасности. OWASP ASVS можно использовать как ориентир для проверки безопасности веб-приложений, особенно когда сайт работает с учетными записями, ролями, сессиями и оплатами. OWASP Application Security Verification Standard дает структурированную основу для таких требований.

Доступность и удобство

Доступность часто не попадает в ТЗ, хотя она влияет и на пользователей, и на качество интерфейса. Речь не только о людях с инвалидностью. Контрастный текст, понятные кнопки, правильные подписи полей, заметные ошибки в формах и управление с клавиатуры делают сайт удобнее для всех.

В ТЗ можно прописать базовые требования:

• достаточный контраст текста и фона;

• понятные названия кнопок;

• подписи к полям форм;

• сообщения об ошибках рядом с соответствующими полями;

• alt-тексты для содержательных изображений;

• возможность пользоваться основными элементами с клавиатуры;

• корректную иерархию заголовков.

Для ориентира можно использовать WCAG 2.2 – это международные рекомендации W3C по доступности веб-контента. Документ WCAG 2.2 не нужно механически переносить в ТЗ полностью, но основные принципы стоит учесть в дизайне, верстке и тестировании.

Контент и управление страницами

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

В ТЗ стоит указать:

• кто пишет тексты;

• кто готовит фото и видео;

• какие страницы должны быть заполнены до запуска;

• какие блоки редактируются через админпанель;

• нужны ли шаблоны для страниц услуг, товаров, статей, категорий;

• нужна ли мультиязычность;

• кто отвечает за перенос контента со старого сайта.

Для интернет-магазина отдельно описывают контент товаров: название, описание, характеристики, фото, инструкции, сертификаты, видео, атрибуты для фильтров, SEO-поля, данные для Merchant Center.

Кто за что отвечает

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

В техническом задании на создание сайта стоит зафиксировать:

• кто предоставляет логотип, брендбук, фото, видео и тексты;

• кто готовит товарный файл или данные для импорта;

• кто предоставляет доступы к домену, хостингу, CRM, платежной системе, службам доставки, Google Analytics, Google Tag Manager и Search Console;

• кто согласовывает структуру, прототипы, дизайн и функционал;

• кто тестирует сайт со стороны клиента;

• кто принимает финальный результат;

• в какие сроки предоставляются правки и согласования.

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

Критерии приемки сайта

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

В ТЗ стоит зафиксировать, что проверяется перед запуском:

• все согласованные страницы созданы;

• формы работают, и заявки поступают в нужные каналы;

• сайт корректно открывается на мобильных устройствах;

• нет критических ошибок в верстке;

• админпанель позволяет редактировать нужные данные;

• настроены мета-теги, sitemap, robots.txt;

• подключена аналитика;

• настроены редиректы со старых URL, если был старый сайт;

• проведено базовое тестирование скорости, форм, интеграций и checkout.

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

Что вынести в первый запуск, а что оставить на второй этап

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

Для первого запуска интернет-магазина обычно критичны:

• понятная структура каталога;

• категории, карточка товара, корзина и checkout;

• базовая оплата и доставка;

• админпанель для товаров и заказов;

• SEO-база: URL, мета-теги, sitemap, robots.txt, canonical, микроразметка;

• аналитика GA4 и ключевые eCommerce-события;

• проверенные формы, письма, статусы заказов и передача заявок.

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

Чек-лист технического задания

Перед передачей ТЗ разработчикам пройдитесь по короткому чек-листу. Он поможет быстро увидеть, какие блоки еще не описаны.

Пример технического задания на разработку сайта

Ниже – образец ТЗ на разработку сайта с блоком для интернет-магазина. Его не нужно копировать без изменений, но можно использовать как основу и адаптировать под корпоративный сайт, каталог или eCommerce-проект.

1. Общая информация

Нужно разработать интернет-магазин товаров для дома с доставкой по Украине. Каталог на старте – примерно 1500 товаров, в перспективе – до 10 000. Часть товаров имеет вариации по цвету, размеру и материалу. Данные о ценах и остатках обновляются из учетной системы.

• Тип проекта: интернет-магазин с блогом.

• Языки: украинский и русский на первом этапе, английский – во втором релизе.

• География продаж: Украина.

• Основные цели: онлайн-продажи, заявки, повторные покупки, SEO-трафик.

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

2. Структура сайта

• Главная страница – / .

• Каталог товаров – /catalog/ .

• Категории – /catalog/mebli/ .

• Подкатегории – /catalog/mebli/stoly/ .

• Карточка товара – /product/nazva-tovaru/ .

• Корзина – /cart/ .

• Оформление заказа – /checkout/ .

• Личный кабинет покупателя – /account/ .

• Доставка – /delivery/ .

• Оплата – /payment/ .

• Обмен и возврат – /returns/ .

• Акции – /sale/ .

• Блог – /blog/ .

• Контакты – /contacts/ .

3. Каталог и товары

Каталог должен поддерживать категории, подкатегории, бренды, фильтры, сортировку, поиск и страницы товаров. Для каждого товара нужно предусмотреть название, артикул, бренд, фото, цену, старую цену, наличие, описание, характеристики, вариации, SEO-поля, похожие товары и статус активности.

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

Если товара нет в наличии, кнопка покупки не показывается или заменяется на сообщить о наличии. Неактивные товары не удаляются автоматически, чтобы не создавать лишние 404-страницы без решения по SEO.

4. Карточка товара

В карточке товара должны быть:

• название товара;

• артикул;

• фотогалерея;

• цена и старая цена;

• статус наличия;

• вариации товара;

• характеристики;

• описание;

• условия доставки и оплаты;

• гарантия;

• отзывы;

• блок похожих товаров;

• блок вместе покупают;

• микроразметка Product;

• SEO-поля: Title, Description, H1, canonical, URL.

5. Корзина и заказ

Покупатель должен иметь возможность добавить товар в корзину, изменить количество, удалить позицию, применить промокод, выбрать доставку и способ оплаты. После оформления заказа покупатель видит страницу подтверждения, а менеджер получает заказ в админпанели и CRM.

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

Статусы заказа:

• Новый;

• Подтвержден;

• Ожидает оплату;

• Оплачено;

• Передано в доставку;

• Выполнено;

• Отменено;

• Возврат.

6. Оплата и доставка

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

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

7. Админпанель

Администратор должен управлять товарами, категориями, заказами, клиентами, промокодами, страницами, блогом и SEO-полями. Для менеджеров нужно создать отдельные роли с ограниченным доступом.

Контент-менеджер может редактировать товары, фото, характеристики и тексты, но не имеет доступа к техническим настройкам сайта. Менеджер заказов видит заказы и меняет их статусы, но не редактирует структуру сайта.

8. SEO-требования

• Для всех основных страниц должна быть возможность редактировать Title, Description и H1.

• URL должны быть понятными и логичными.

• Нужно реализовать canonical для страниц, где возможны дубли.

• Нужно создать sitemap.xml для категорий, товаров, статей и статических страниц.

• Нужно настроить robots.txt.

• Нужно добавить микроразметку BreadcrumbList и Product.

• Страница 404 должна быть оформлена и возвращать корректный код ответа.

• При переносе со старого сайта нужно подготовить карту 301-редиректов.

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

9. Аналитика

На сайте нужно установить Google Tag Manager и Google Analytics 4. Для интернет-магазина нужно настроить eCommerce-события: просмотр товара, добавление в корзину, начало оформления заказа, выбор доставки, покупка. Также нужно передавать сумму заказа, валюту, товары и номер транзакции.

10. Тестирование и приемка

Перед запуском нужно проверить работу сайта на актуальных версиях Chrome, Safari, Firefox и мобильных браузерах. Отдельно тестируются формы, корзина, оплата, доставка, личный кабинет, админпанель, интеграции, SEO-поля, sitemap, robots.txt, аналитика и скорость загрузки.

Обязательные сценарии тестирования:

• покупка с оплатой онлайн;

• покупка с наложенным платежом;

• заказ товара, которого нет в наличии;

• применение промокода;

• ошибка оплаты;

• повторная оплата;

• изменение статуса заказа;

• передача заказа в CRM;

• передача покупки в GA4.

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

Что не стоит включать в ТЗ

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

Не стоит включать в основное ТЗ:

• функции, которые пока не имеют бизнес-логики;

• интеграции без доступов и подтвержденной возможности подключения;

• пожелания без конкретного сценария использования;

• технологии, которые выбраны случайно, а не под задачу проекта;

• чрезмерную детализацию дизайна там, где сначала нужен прототип.

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

Вывод

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

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

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