На чём создать лендинг: конструктор, CMS, код

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

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

Когда хватает одной страницы

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

Матрица выбора платформы

Ситуация                                      | Конструктор | CMS на своём хостинге | Свой код
----------------------------------------------|-------------|------------------------|---------
Контент готов, логика стандартная             | Да          | Избыточно              | Нет
Заказчик сам правит блоки каждую неделю       | Да          | Да                     | Редко
Лендинг станет разделом большого сайта        | Временно    | Да                     | Иногда
Нужны нестандартная форма и события           | Ограничено  | Плагины/доработки      | Да
Важен полный контроль хостинга и кода         | Нет         | Частично               | Да
Уже есть внешняя форма записи                 | Ссылка      | Ссылка/виджет          | Ссылка/API
Мало времени до теста рекламы                 | Да          | Медленнее              | Медленнее
Команда готова держать обновления и бэкапы    | Платформа   | Нужен владелец         | Нужен владелец

Короткое правило:
- стандарт и самостоятельные правки → конструктор (например Tilda)
- будущий раздел сайта → CMS
- нестандартная логика или жёсткий контроль инфраструктуры → код
- внешняя форма уже есть → сначала обычная ссылка, API только если ссылки мало

SaaS-конструктор собирает страницу из блоков. На Tilda помогают Zero Block, HTML, формы, CRM-связи и webhook, но сложный сценарий всё равно может потребовать разработчика. До старта проверьте тариф и лимиты нужных интеграций.

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

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

Каркас блоков страницы

До дизайна соберите содержание по блокам. Пустые «красивые» секции потом дорого переписывать под рекламу.

1. Первый экран
   что продаём, для кого, одно главное действие

2. Боль и контекст
   какая задача у посетителя сейчас

3. Состав услуги и результат
   что входит, чего ждать на выходе

4. Для кого / не для кого
   чтобы отсечь заведомо неподходящие заявки

5. Цена или способ расчёта
   сумма, вилка, выезд, от чего зависит смета

6. Порядок работы и срок
   шаги от заявки до результата

7. Доказательства
   факты, фото, кейсы; без выдуманных отзывов и цифр

8. Возражения / FAQ
   то, что останавливает перед кнопкой

9. Повтор CTA
   та же цель, что на первом экране

10. Контакты и юридические ссылки
    телефон, мессенджер, политика, реквизиты при необходимости

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

Приёмка до рекламы: QA

Не включайте платный трафик, пока не закрыт список. Иначе вы оплачиваете дыры в форме и аналитике.

• Первый экран понятен без текста объявления.
• Оффер на странице совпадает с оффером в объявлении.
• Текст, кнопки и форма читаются и нажимаются на телефоне одной рукой.
• Форма показывает ошибку валидации и не теряет уже введённые поля.
• Успешная отправка показывает подтверждение один раз.
• Тестовая заявка реально приходит в согласованный канал: почта, CRM, мессенджер.
• Повторный клик не плодит неконтролируемые дубли.
• Источник, кампания и посадочная доходят до записи заявки.
• Цели в аналитике: успех формы, телефон, каждый мессенджер отдельно; цель не горит на пустой отправке.
• HTTPS, понятный title, корректный robots, если страницу индексируют.
• Политика и основание обработки данных соответствуют реальной форме, а не шаблону «для галочки».
• Если согласие используется, с 1 сентября 2025 года его оформляют отдельно от других документов, которые пользователь подтверждает.

Title, description, индексируемая разметка и sitemap помогают технически. Сами по себе они не дают позиции и трафик. Одних политики и чекбокса недостаточно для 152-ФЗ: нужны оператор, цели, состав данных, получатели, сроки, меры защиты, локализация и проверка трансграничной передачи.

Считать заявки, не только клики

• Визиты или пользователи
• Клики по основной кнопке и начало формы
• Успешно отправленные и доставленные заявки
• Валидные и квалифицированные заявки
• Стоимость валидной заявки: расход кампании / валидные заявки кампании
• Ошибки формы и недоставленные заявки

Переход во внешнюю форму ещё не завершённая запись. Если внешняя система не возвращает событие, на лендинге подтверждают только уход. Завершение проверяют в системе записи или CRM. Телефон и email в веб-аналитику не отправляют. Связку с CRM держат по техническому идентификатору с ограниченным сроком хранения.

Срок и стоимость

Цена зависит не только от числа экранов. Влияют готовность текста, платформа, формы, интеграции, аналитика, юридические требования и объём проверки. Сначала зафиксируйте сценарий и границы работы, потом сравнивайте сметы. Актуальные ориентиры DevLab есть на странице разработки сайта.

Частые вопросы