ТЗ на лендинг vs многостраничный сайт

Коротко: Разница ТЗ лендинга и многостраничника заключается в целях и глубине проработки. Лендинг требует детальной проработки сценариев конверсии и форм захвата данных. Многостраничный сайт требует описания сложной архитектуры, системы фильтрации и интеграции с базами данных. В 2026 году в обоих случаях критически важно разделять согласия на обработку ПДн и на рекламу.

Кстати, в AmSales мы делаем внедрение и настройку Битрикс24 и разработку сайтов под ключ под ключ. Если нужна помощь - напишите нам.

Ключевые цели и архитектура проектов

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

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

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

Сравнительная логика выбора проекта выглядит следующим образом:

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

Функциональные требования к лендингу

Когда вы решите составить ТЗ на лендинг, забудьте про общие фразы вроде "красивый дизайн" или "удобная навигация". Разработчику нужны конкретные параметры. В лендинге функционал завязан на три вещи: скорость загрузки, корректность работы форм и анимация, которая не отвлекает от покупки. Любая задержка в 2 секунды на мобильном устройстве может стоить вам половины рекламного бюджета.

Особое внимание уделите блоку формах обратной связи. В ТЗ нужно прописать не просто "форма для заявки", а конкретные поля: имя, телефон, email, выбор услуги. Важно указать, какие поля являются обязательными, а какие - нет. Также необходимо описать поведение страницы после отправки формы. Пользователь должен увидеть сообщение "Спасибо, мы свяжемся с вами" или быть перенаправлен на страницу "Спасибо" (Thank You Page). Это критически важно для настройки сквозной аналитики.

Еще один важный блок - интерактивные элементы. Если вы планируете использовать калькуляторы стоимости, квизы или слайдеры, это должно быть описано максимально подробно. Например: "При изменении параметра А, значение в поле Б должно пересчитываться мгновенно без перезагрузки страницы". Это требует использования определенных скриптов, и программист должен заранее знать объем работы.

Не забудьте про адаптивность. В 2026 году доля мобильного трафика в B2B-сегменте достигла критических отметок. В ТЗ должно быть четко указано: сайт должен корректно отображаться на устройствах с разрешением от 320px до 2560px. При этом важно прописать, как элементы меняются при смене ориентации экрана. Кнопки должны быть удобного размера для нажатия пальцем, а не только курсором мыши.

Что обязательно включить в функционал лендинга:

1. Логика работы всех форм захвата (валидация полей, маски для телефонов).
2. Сценарии отображения элементов (появление при скролле, анимация кнопок).
3. Настройка переходов по якорям (клик по меню - переход к нужному блоку).
4. Механика работы изображений (lazy load для ускорения загрузки).

Сложная структура многостраничного сайта

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

Первое, что нужно прописать - это карта сайта (Sitemap). Это не просто список страниц, а иерархическая структура. Например: Главная -> Каталог -> Категория -> Карточка товара -> Дополнительные услуги. Для каждой страницы нужно определить тип шаблона. Есть шаблон для текстовых статей, есть шаблон для карточек товаров, есть шаблон для FAQ. Если вы не укажете это в ТЗ, разработчик сделает всё "на свое усмотрение", и в итоге вы получите 50 разных по дизайну страниц, которые невозможно поддерживать.

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

Третий важный аспект - права доступа и личный кабинет. Если на сайте есть регистрация пользователей, в ТЗ должны быть прописаны все роли: Гость, Зарегистрированный пользователь, Менеджер, Администратор. Вы должны четко указать, что видит каждый из них. Могут ли пользователи оставлять отзывы? Могут ли они скачивать документы? Есть ли у них история заказов? Без этого раздела проект превращается в хаос.

Для SEO-специалиста в многостраничном сайте критически важны технические требования к структуре URL. В ТЗ нужно заложить человекопонятные URL (ЧПУ), автоматическую генерацию мета-тегов (Title, Description) на основе заголовков, а также возможность ручной правки этих тегов для каждой страницы. Без этого ваш сайт будет "невидимкой" для поисковых систем, сколько бы вы ни вкладывали в контент.

Техническое задание на сбор персональных данных

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

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

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

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

Правила оформления форм в 2026 году:

• Никаких предустановленных (предварительно проставленных) галочек. Пользователь должен совершить активное действие.
• Отдельное согласие на рекламу (ст. 18 закона № 38-ФЗ) от согласия на обработку ПДн.
• Наличие прямой ссылки на Политику обработки ПДн непосредственно под формой.
• Логирование (фиксация) момента, времени и IP-адреса, с которого было дано согласие.

Требования по закону о рекламе и ПДн

Юридическая чистота сайта - это часть технического задания. С 1 сентября 2025 года правила стали еще жестче: согласие на обработку персональных данных должно оформляться отдельно от оферты или пользовательского соглашения. Это означает, что в ТЗ нельзя прописать: "Пользователь, нажимая кнопку, принимает оферту и соглашается с политикой конфиденциальности". Это старый подход, который больше не работает. Теперь у вас должно быть два разных механизма подтверждения.

Второй момент касается закона "О рекламе". Если ваш сайт использует инструменты для рассылок (e-mail, SMS, мессенджеры), в ТЗ должно быть заложено получение предварительного согласия именно на получение рекламных материалов. Это не то же самое, что согласие на обработку данных. Это разрешение на коммуникацию. Если вы используете автоматические рассылки, в ТЗ нужно прописать механику "отписки" (Unsubscribe) в каждом сообщении, иначе вы попадете под санкции за спам.

Также актуален вопрос использования Cookie. В 2026 году нельзя просто вешать баннер "Мы используем cookie" и продолжать собирать данные. Технически сайт должен быть настроен так, чтобы маркетинговые и аналитические cookie не загружались до того, как пользователь нажал "Принять" на баннере. Это требует внедрения механизма управления согласием (Consent Management Platform). В ТЗ нужно прописать: "Запрет на загрузку некритичных скриптов до получения согласия пользователя".

Также обратите внимание на трансграничную передачу данных. Согласно изменениям в 152-ФЗ, вступившим в силу в июле 2026 года, если ваш сайт использует зарубежные сервисы (например, зарубежные системы аналитики или CRM), вы должны учитывать правила уведомления Роскомнадзора о трансграничной передаче. В ТЗ это отражается через требования к безопасности передачи данных и шифрованию каналов связи (протокол HTTPS с актуальными сертификатами).

Интеграция с CRM и системами аналитики

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

Например, если вы используете Bitrix24 или amoCRM, в ТЗ нужно указать: "При заполнении формы 'Заказ товара' данные (Имя, Телефон, Товар, ID страницы) должны передаваться в CRM как новая сделка в воронку 'Новые заявки'. Поля должны соответствовать типам данных в CRM (строка, число, дата)". Если в CRM поле называется "Телефон", а в форме это "Mobile_Number", без четкого описания в ТЗ данные могут просто "теряться" при передаче.

Аналитика - это второй столп интеграции. Вам нужно прописать передачу событий (Events). Недостаточно просто установить счетчик Яндекс.Метрики или Google Analytics. Вам нужно, чтобы сайт передавал данные о конкретных действиях: "Клик по кнопке 'Позвонить'", "Завершение оформления заказа", "Добавление товара в корзину". Для этого в ТЗ прописываются названия событий (Event Name) и передаваемые параметры (например, сумма заказа или артикул товара). Только так вы сможете построить сквозную аналитику и понять реальную стоимость лида.

Также стоит заложить интеграцию с системами телефонии (например, Mango Office, UIS или Wazzup). В ТЗ должно быть указано: "При поступлении звонка с номера, оставленного на сайте, в CRM должна отображаться карточка клиента с информацией о просмотренных товарах". Это требует настройки интеграции через API, что является отдельной и довольно трудоемкой задачей, которую нельзя игнорировать на этапе планирования.

Типичные ошибки при составлении ТЗ

Ошибки в ТЗ стоят денег. Самая распространенная - это "избыточность без конкретики". Когда заказчик пишет: "Сделайте сайт, чтобы он был удобным и современным". Для разработчика это пустой звук. Нет "удобства" в техническом смысле, есть только конкретные сценарии использования. Если вы не описываете сценарии, вы получаете продукт, который не решает ваши задачи.

Вторая ошибка - игнорирование этапа тестирования. В ТЗ обязательно должен быть раздел "Приемочные испытания". Вы должны заранее прописать, как вы будете проверять готовность сайта. Например: "Проверить корректность работы формы на iPhone 13 и Samsung Galaxy S22", "Проверить скорость загрузки главной страницы через Google PageSpeed Insights (показатель FCP не менее 1.5 сек)". Если этого нет в ТЗ, разработчик примет работу по принципу "у меня на компьютере всё работает".

Третья ошибка - отсутствие требований к контенту и SEO. Часто разработчики делают "пустышки" - сайты с текстами "Lorem Ipsum". Если вам нужен сайт для продвижения, в ТЗ должны быть прописаны требования к иерархии заголовков (H1-H6), вложенности страниц, генерации sitemap.xml и robots.txt. Без этого вы получите красивую картинку, которую невозможно будет продвинуть в поиске.

Четвертая ошибка - экономия на интеграциях. Попытка сделать "свой самописный модуль для учета заказов" вместо стандартной интеграции с вашей текущей CRM. Это всегда приводит к тому, что через полгода система ломается, а программист, который её писал, пропадает. Всегда выбирайте проверенные решения через API и прописывайте это в ТЗ.

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

Что запомнить:

• Разница между лендингом и многостраничником - в сложности архитектуры и глубине проработки сценариев.
• В 2026 году согласие на обработку ПДн и согласие на рекламу - это разные чекбоксы.
• В ТЗ обязательно прописывайте требования к локализации данных (серверы в РФ) и механику Cookie.
• Интеграция с CRM и аналитикой требует детального описания полей и событий (Events).
• Всегда закладывайте в ТЗ раздел с правилами приемки и тестами.