Многошаговые формы: как я поднял конверсию заявок с 0,9% до 3,4% — практический гайд

В феврале 2026 года я разбирал аналитику сайта сервисной компании на WordPress: 4 200 уникальных посетителей в месяц, форма «Заказать расчёт» из девяти полей на одном экране — и 38 заявок. Конверсия 0,9%. Через шесть недель на том же трафике та же услуга давала 143 заявки в месяц — 3,4%. Мы не трогали ни рекламу, ни посадочную страницу, ни цены. Поменялась только форма: она стала многошаговой, научилась валидировать поля на лету и перестала пугать посетителя на первом же экране. Разбираю, как это повторить.

Почему длинная форма проигрывает ещё до первого поля

Посмотрите, как реальный человек встречает форму. Он не начинает заполнять первое поле — он сначала сканирует экран и молча считает: девять полей, два обязательных селекта, звёздочки, капча. Решение «уйти» принимается за 2–3 секунды, до первого клика. По моим замерам на Яндекс.Метрике (вебвизор + аналитика форм) на пяти клиентских проектах за последний год, 60–70% отказов от формы происходят именно на этапе «посмотрел и ушёл», а не на середине заполнения.

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

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

Анатомия многошаговой формы, которая работает

За три года я собрал таких форм больше десятка — на WordPress, на Битриксе и на самописных лендингах. Рабочая схема стабильно одна и та же:

• Три-четыре шага, не больше. Два шага выглядят как недоделанная одношаговая форма, пять — как бюрократия. Три шага по 2–4 поля — золотая середина почти для любой заявки.
• Лёгкие вопросы первыми. Первый шаг — выбор из готовых вариантов: тип услуги, примерный бюджет, сроки. Никаких «ваше имя» и «телефон» на старте — контакты это самое «дорогое» поле, и его место в конце.
• Видимый прогресс. Полоса прогресса или «Шаг 2 из 3» снижают тревожность: человек понимает, сколько осталось. Без индикатора каждый следующий шаг воспринимается как «опять что-то новое».
• Кнопка «Назад» без потери данных. Если при возврате на шаг поля очищаются — вы потеряли человека. Все введённые значения живут в состоянии формы до самой отправки.
• Финальный шаг — только контакты и кнопка. Телефон или email, согласие на обработку, отправить. К этому моменту посетитель уже вложил минуту времени и хочет завершить.

Разметка и логика на чистом JavaScript

Плагинов для многошаговых форм хватает (Fluent Forms, Gravity Forms с их step-аддонами), но на клиентских проектах я чаще пишу форму руками: 40 строк разметки и 60 строк JS без единой зависимости. Это быстрее грузится, проще стилизуется под дизайн и не тащит за собой очередной плагин с его обновлениями и уязвимостями. Вот скелет, с которого начинается каждая моя форма:

<form class="lead-form" id="leadForm" novalidate>
  <div class="lead-form__progress">
    <span class="lead-form__bar" style="width: 33%"></span>
  </div>

  <fieldset class="step is-active" data-step="1">
    <legend>Что нужно сделать?</legend>
    <label>Тип работ
      <select name="service" required>
        <option value="">Выберите…</option>
        <option value="repair">Ремонт</option>
        <option value="install">Монтаж</option>
      </select>
    </label>
    <label>Примерный бюджет, ₽
      <input type="text" name="budget" inputmode="numeric">
    </label>
    <button type="button" class="step-next">Далее</button>
  </fieldset>

  <fieldset class="step" data-step="2">…</fieldset>
  <fieldset class="step" data-step="3">
    <label>Телефон
      <input type="tel" name="phone" required autocomplete="tel">
    </label>
    <button type="submit">Получить расчёт</button>
  </fieldset>
</form>

Переключение шагов — это смена класса у fieldset, а не перезагрузка и не роутинг:

const form = document.getElementById('leadForm');

form.addEventListener('click', (e) => {
  const btn = e.target.closest('.step-next, .step-back');
  if (!btn) return;
  const current = btn.closest('.step');
  if (btn.classList.contains('step-next') && !validateStep(current)) return;

  const target = btn.classList.contains('step-next')
    ? current.nextElementSibling
    : current.previousElementSibling;
  if (!target) return;

  current.classList.remove('is-active');
  target.classList.add('is-active');
  updateProgress(target.dataset.step);
  target.querySelector('input, select')?.focus();

  // событие для аналитики — считаем дошедших до каждого шага
  window.dataLayer?.push({ event: 'form_step', step: target.dataset.step });
});

Обратите внимание на три детали, которые часто упускают. Во-первых, novalidate на форме и своя функция validateStep(): нативный браузерный алерт «Заполните это поле» невозможно стилизовать, и на мобильном он выглядит инородно. Во-вторых, ?focus() на первом поле нового шага — без этого пользователи клавиатуры и скринридеров теряют контекст. В-третьих, событие в dataLayer на каждый шаг: без пошаговой аналитики вы никогда не узнаете, где именно форма теряет людей.

Валидация: на лету, а не после отправки

Самый губительный паттерн, который я встречаю на чужих сайтах, — валидация только по сабмиту. Человек заполнил девять полей, нажал «Отправить», получил красную простыню ошибок сверху и половину очищенных полей. Доля повторных попыток после такого сценария, по моим логам, — меньше 30%. То есть каждая ошибка после сабмита стоит вам 70% заявки.

Правильная схема — трёхуровневая. Первый уровень: подсказки до ошибки — inputmode="numeric" у бюджета, type="tel" и маска у телефона, autocomplete у контактов. Второй уровень: проверка поля при потере фокуса (событие blur), а не при каждом нажатии клавиши — валидировать на input значит ругать человека за незаконченный email. Третий уровень: финальная проверка шага перед переходом дальше.

И отдельное правило, которое я считаю обязательным: клиентская валидация — это про удобство, а не про безопасность. Всё, что пришло на сервер, проверяется заново. Минимальный серверный обработчик на WordPress выглядит так:

add_action('admin_post_nopriv_lead_form', 'handle_lead_form');

function handle_lead_form() {
    $phone = preg_replace('/\D+/', '', $_POST['phone'] ?? '');
    if (strlen($phone)  'phone', 'message' => 'Проверьте номер телефона'],
            422
        );
    }

    $service = sanitize_text_field($_POST['service'] ?? '');
    if (!in_array($service, ['repair', 'install'], true)) {
        wp_send_json_error(['field' => 'service'], 422);
    }

    // сохранение лида, отправка письма, webhook в CRM…
    wp_send_json_success();
}

Ключевой момент — ответ с кодом 422 и указанием поля. Фронт получает его и подсвечивает конкретный инпут, а не показывает абстрактное «произошла ошибка».

Спам, доставка и то, что происходит после кнопки

Как только форма начинает приносить заявки, на неё приходят боты. Классическое решение — прикрутить капчу, и я считаю это ошибкой: капча снижает конверсию живых людей заметнее, чем отсекает спам. В статье почему я против CAPTCHA я подробно разбирал альтернативы; здесь коротко: honeypot-поле (скрытый инпут, который заполняют только боты) плюс проверка времени заполнения формы на сервере отсекают 95–98% мусора, не трогая людей. В многошаговой форме есть бонус: бот, отправивший все три шага за 400 миллисекунд, распознаётся тривиально.

Второй момент, о котором забывают: отправка формы — это только начало пути заявки. Если лид падает в почтовый ящик, который менеджер проверяет раз в день, вся работа над конверсией теряет смысл. Способы доставки заявок в CRM — вебхуки, опрос API, очереди — я сравнивал в отдельном разборе про лиды с сайта в CRM, и для форм с трафиком от пары заявок в день мой выбор однозначен: webhook с ретраем при недоступности CRM.

Доступность — это тоже конверсия

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

• у каждого поля настоящий <label>, а не placeholder вместо подписи — placeholder исчезает при вводе и не читается нормально скринридерами;
• ошибки полей объявляются через aria-live="polite", чтобы скринридер озвучил их без смены фокуса;
• видимый :focus-visible у инпутов и кнопок — пользователь Tab-навигации должен видеть, где он;
• переход между шагами по Enter, возврат — по Shift+Tab до кнопки «Назад», а не только мышью.

Развёрнутый чек-лист по WCAG 2.2 и требованиям European Accessibility Act, актуальным с 2025 года, я выкладывал в статье про доступность сайтов в 2026 году — формам там посвящён отдельный раздел.

Что измерять после запуска

Многошаговая форма без пошаговой аналитики — это чёрный ящик. Минимальный набор метрик, который я завожу в Метрике или GA4 в первый же день:

• Доходимость по шагам. Сколько процентов начавших доходит до шага 2, до шага 3, до отправки. В кейсе из начала статьи узким местом оказался второй шаг с вопросом про адрес объекта — перенесли его на третий шаг после контактов, и доходимость выросла с 54% до 71%.
• Время заполнения. Здоровая медиана для трёхшаговой формы — 40–80 секунд. Две минуты и больше значат, что какой-то вопрос люди не понимают.
• Доля вернувшихся после ошибки. Если после серверной 422 до отправки доходит меньше половины — у вас проблема с текстами ошибок.
• Конверсия посетитель → заявка как контрольная точка. Именно она, а не «количество лидов», — метрика формы: лиды может дать и прилив рекламного трафика.

По этим четырём числам через две недели после запуска видно, куда крутить форму дальше. В кейсе сервисной компании итоговая цепочка выглядела так: 0,9% → 1,8% после перехода на три шага → 2,6% после инлайн-валидации и маски телефона → 3,4% после перестановки вопроса про адрес и отказа от капчи. Ни одно изменение по отдельности не дало бы такого эффекта — сработала связка.

А как устроены формы на ваших проектах — одна длинная анкета или мастер по шагам? С какой конверсией живёте и что реально сдвинуло цифру, когда вы её поднимали? Интересно сравнить опыт в комментариях.