Перейти к содержимому

Продающий лендинг: структура страницы и конверсия

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

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

ФорматНа какой вопрос отвечаетГде разбирается
Лендинг«Что я получу, на каких условиях и как начать?»Эта статья
Доказательный лонгрид«Почему привычное решение не работает и как устроен другой механизм?»Отдельная статья
Страница направления или каталога«Что здесь есть и куда пойти?» — обслуживает несколько намерений и поисковый спросКаталог типов сайтов
CRO«Почему страница не конвертит и что менять первым?»Цикл проверки на живом трафике

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

До макета фиксируются семь пунктов. Без них любой дизайн только маскирует отсутствие решения.

  1. Одна роль читателя и его работа. Кто он, какую задачу решает, в каком контексте и что уже пробовал.
  2. Источник трафика и осознанность. Холодный, тёплый или возврат по бренду; откуда именно пришёл человек.
  3. Одно целевое действие и событие, которым оно измеряется.
  4. Единица покупки: час, слот, этап, подписка, лицензия — то, что человек реально приобретает.
  5. Доказательства и источник каждого: код, кейс, отзыв, документ, процессный артефакт.
  6. Возражения — из переписок, звонков, поддержки и отказов, а не из предположений команды.
  7. Что произойдёт сразу после клика: куда ведёт действие, кто отвечает, за какой срок.

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

Осознанность аудитории меняет первый экран сильнее, чем визуальный стиль:

ТрафикЧто человек уже знаетЧто должно быть на первом экране
Холодный: реклама по проблемеЗнает проблему, не знает компаниюСитуация и её последствие, затем объяснение механизма решения
Тёплый: ретаргетинг, письмо, партнёрский каналЗнает продукт или слышал о нёмОффер, формат работы и условия входа
Поиск по бренду и возвратСравнивает вариантыКонкретика: цены, сроки, кейсы, ограничения
Навигация и внутренние ссылкиПришёл изучить направлениеГраницы направления и один следующий шаг

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

СекцияВопрос читателяЧто в ней должно быть
HeroЭто про меня?Ситуация роли, результат работы, одно главное действие
FitПодхожу ли я?Кому подходит и кому нет, условия входа
OutputЧто я получу?Артефакты и результат в проверяемых единицах
ProcessКак это будет происходить?Этапы, точки контроля, что нужно от клиента
ProofПочему этому можно верить?Доказательство именно предыдущего тезиса
Commercial modelСколько стоит и что входит?Единица оплаты, состав, границы, условия
ObjectionsЧто меня останавливает?Риски переключения и честные ответы
CTAЧто сделать сейчас?Одно действие и ожидание после клика

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

  • Заголовок называет ситуацию и результат, а не название компании, не технологию и не год основания.
  • Подзаголовок уточняет, для кого и в каком формате работает предложение.
  • Одно действие с текстом, описывающим результат: «Получить расчёт», а не «Отправить».
  • Микрокопирайт рядом с кнопкой объясняет, что произойдёт после клика и когда ответят.
  • Визуальный якорь — продукт, интерфейс, схема или реальный результат. Стоковая метафора не объясняет ничего и занимает место оффера.
  • Мобильный первый экран содержит оффер и действие без прокрутки.

Карусель на первом экране, видео с автоплеем и анимация, которая задерживает текст, снижают понятность ради эффекта. Если эффект не помогает принять решение, он лишний.

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

ФормулировкаЧто с ней не так
«Мощный движок»Характеристика вместо результата: непонятно, что это меняет для читателя
«Сайт за 10 дней»Обещание срока при незакрытом объёме работ
«Комплексный подход»Пустая категория, которую нельзя проверить
«Каталог на 50 000 товаров открывается за секунду»Проверяемый результат с источником замера — так и надо
«Работаем по agile»Формат процесса; уместен в Process, а не вместо оффера

Конкретика не обязана быть числом. «Один разработчик в вашем бэклоге, ревью раз в две недели, изменения на staging до релиза» — тоже проверяемое описание, если оно правда.

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

  • Anti-fit формулируется по характеристикам задачи и продукта, а не по людям: «не берём проекты без владельца решения на стороне клиента», «не работаем с задачами без доступа к коду».
  • Условия входа называются честно: наличие бэклога, бюджетного коридора, человека, принимающего решения.
  • Отказ на странице дешевле отказа после трёх встреч.
  • Output перечисляет, что клиент получает: артефакты, доступы, документацию, отчёты, обучение. Единицы должны быть проверяемыми: не «полное сопровождение», а «ежемесячный отчёт по SLA с перечнем инцидентов».
  • Process показывает этапы, точки контроля и роль клиента. Бэклог, staging, регулярный review и критерии приёмки снимают страх «нам принесут чёрный ящик».
  • Разработка и эксплуатация разводятся: запуск не выдаётся за пожизненную поддержку, если поддержка оформляется отдельным договором.
  • Сроки не обещаются при открытом объёме. Вместо срока называются длительность этапа и условия, от которых она зависит.

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

УровеньПримерОграничение
Рабочий код, документация, воспроизводимый примерПубличный репозиторий, документация API, демо с открытыми даннымиНе говорит о результате клиента
Кейс с исходным состоянием, вкладом, периодом и результатомЗадача → что сделали → измеримый результатНужно разрешение клиента
Отзыв с подтверждённым авторомИмя, роль, контекст, ссылка на проектАнонимная цитата слабее отсутствия цитаты
Процессный артефактБэклог, staging, тесты, changelog, SLA-отчётДоказывает процесс, а не результат
Статья или материал базы знанийРазбор метода, ограничений, кодаДоказывает компетенцию, но не результат

Правила, без которых доказательство превращается в риск:

  • каждое число публикуется с источником, периодом и допущениями;
  • гипотетический расчёт называется моделью, а не ожидаемым результатом;
  • демо и структура артефакта не выдаются за клиентский кейс;
  • имя, логотип и отзыв публикуются только с разрешением;
  • доказательство ставится рядом с точкой решения — там, где человек сомневается, а не в отдельном «блоке доверия» в конце.
  • Единица оплаты названа прямо: час, слот, этап, подписка, лицензия, процент.
  • Понятно, что входит в единицу и что оплачивается отдельно: поддержка, SLA, доработки, лицензии, инфраструктура.
  • Числа на странице совпадают с прайсом, офертой и договором. Расхождение — стоп-сигнал: человек узнает другую цену до сделки и уйдёт.
  • Фиксированная цена возможна при закрытом объёме и критериях приёмки; при живом бэклоге честнее назвать лимит мощности и фактический выход итерации.
  • Нельзя смешивать «оплату за часы» и обещание гарантированного объёма результата: это разные модели риска.
  • «От» без нижней границы и условий — не цена, а раздражитель.

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

ВозражениеЧто должно быть на странице
«Дороже, чем своими силами»Сравнение в одинаковой единице: найм, управление, простой, замена, набор компетенций
«Непонятно, что получим за эти деньги»Output в проверяемых единицах и критерии приёмки
«Боюсь потерять контроль над кодом»Репозиторий, review, staging, правила интеграции
«Подрядчик исчезнет, знания уйдут с ним»Бэклог, документация, передача контекста как часть процесса
«Нужна фиксированная цена»Границы fixed price и что остаётся T&M
«Вы работаете только с одним стеком»Честный ответ: стек выбирается после ограничений задачи
«Сроки сорвутся»Точки контроля и условия, от которых зависит срок

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

  • Один CTA по смыслу. Повтор допустим на длинной странице и в футере, но текст, URL и обещание не меняются — меняется только аналитический placement.
  • Текст кнопки описывает результат действия, а не механику интерфейса.
  • CTA ведёт туда, где действие можно совершить. Переход на страницу-перечисление — типичный разрыв маршрута.
  • Форма содержит только поля, без которых нельзя ответить на обращение. Каждое дополнительное поле уменьшает число отправок.
  • Поля используют правильные типы ввода и автозаполнение; ошибки показываются текстом и не стирают введённое.
  • Согласие на обработку данных и ссылка на политику стоят рядом с формой, а не только в подвале.
  • Согласие не предвыбирается, обязательные поля не маскируются под необязательные.
  • После отправки человек видит подтверждение с ожиданием: кто ответит, когда и по какому каналу.
  • Таймеры, фальшивая нехватка мест, счётчики «сейчас смотрят эту страницу».
  • Всплывающие окна-перехватчики сразу при входе и липкая кнопка поверх текста.
  • Предвыбранные чекбоксы согласия и сбор данных сверх необходимого.
  • Карусели и автопрокрутка на первом экране.
  • Обещания лидов, продаж, конверсии или ROMI как гарантии.
  • Сравнение с конкурентом без источника и без даты.
  • «Мы лучшие», «номер один», «быстрее всех» — непроверяемые утверждения, которые снижают доверие к остальным фактам.
  • Стена текста без подзаголовков и списков: читатель не находит ответ и уходит.
  • Первый экран проверяется на мобильной ширине отдельно: на телефоне меняется контекст, а не только вёрстка.
  • Изображения и видео не задерживают первый экран; воспринимаемая скорость важнее формальной метрики. Технические приёмы — в статье оптимизация производительности.
  • Интерактивные цели не меньше 24 × 24 CSS-пикселя, контраст текста не ниже 4.5:1, у кнопок и ссылок виден focus-visible.
  • Sticky-хедер, cookie-баннер и чат-виджет не перекрывают сфокусированный элемент и не закрывают CTA.
  • Формы используют связанные <label>, ошибки дублируются текстом, а не только цветом. Подробнее — доступность.
  • Проверка на реальном устройстве обязательна: эмулятор не показывает скорость сети и поведение клавиатуры.
  • События фиксируют клик по CTA, отправку формы, шаги формы и оплату. Без события любое утверждение о конверсии — вера, а не данные.
  • Одна primary metric и один guardrail на итерацию: например, доля отправок формы растёт, а доля квалифицированных обращений не падает.
  • Скролл и время чтения — диагностика, а не доказательство успеха. Они подсказывают, где теряется внимание, но не заменяют конверсию.
  • При малом трафике классический A/B-тест ничего не докажет. Работают последовательные срезы с фиксированной датой изменения и качественный разбор обращений. Подробно — CRO.
  • Гипотеза формулируется до правки: какой фактор меняем, что должно измениться и почему. Одна итерация — один крупный фактор.
  • Rollback описывается заранее: как вернуть предыдущую версию, если метрика просела.
  • Текст страницы хранится в одном месте — в конфигурации страницы, а не размазан по разметке. Правка оффера не должна требовать поиска по десяти файлам.
  • Секция, которая появляется на второй странице, выносится в компонент или паттерн с вариантами, а не копируется. Библиотека hero, CTA, форм, отзывов, тарифов и FAQ ускоряет сборку и удерживает единые правила.
  • Новый блок добавляется в дизайн-систему, а не рядом с ней: токены, отступы, типографика и состояния берутся из проекта (UI-дизайн).
  • Платформенная реализация композиции страниц — в разделе WordPress → паттерны.
  • Визуальная приёмка идёт после сборки: контейнеры, контраст, фокус, отсутствие горизонтального скролла, мобильная ширина.
  • Названы одна роль, одна задача, источник трафика и одно целевое действие.
  • Оффер содержит результат, единицу, границы и условия.
  • Порядок секций отвечает на реальные вопросы; нестандартный порядок объяснён гипотезой.
  • Есть anti-fit и честные условия входа.
  • Output описан в проверяемых единицах, есть точки контроля.
  • Каждое доказательство подтверждает предыдущий тезис и имеет источник.
  • Ни одного числа без источника, ни одного непроверяемого превосходства.
  • Единица оплаты и состав названы; числа совпадают с офертой.
  • Возражения взяты из реальных обращений, а не придуманы.
  • Один CTA по смыслу, маршрут пройден руками до конца.
  • Форма минимальна, ошибки понятны, согласие не предвыбрано.
  • События заведены, гипотеза, метрика, guardrail и дата решения записаны.
  • Мобильная версия, контраст, фокус и скорость проверены.
  • Нет таймеров, фальшивой нехватки и перехватывающих поп-апов.