Как защитить формы на Тильде от фрода: создаём скрытое поле правильно

Как работает скрытое поле honeypot

Чтобы правильно создать ловушку, сначала нужно задать себе вопрос:

У бота нет глаз в человеческом понимании. Обычно он анализирует HTML-код страницы, ищет формы, а внутри них — элементы для ввода данных.

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

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

• <input> — обычное поле в одну строку: имя, телефон, почта или адрес сайта;
• <textarea> — многострочное поле: комментарий, сообщение или описание.

В Тильде нам будет достаточно обычного поля для ввода в одну строку. Наша задача — добавить настоящее текстовое поле, оставить его внутри формы, но визуально убрать со страницы при помощи CSS.

Почему встроенное «Скрытое поле» Тильды нам не подходит

Здесь часто возникает путаница и многие ошибаются при создании honeypot-поля. В Тильде уже есть тип поля, который так и называется: «Скрытое поле». Кажется логичным использовать именно его, но для нашей ловушки это не лучший вариант.

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

Такое поле не предназначено для заполнения посетителем. Обычно в нём заранее указывается статическое значение либо оно заполняется дополнительным скриптом. Именно так работает встроенное скрытое поле по официальной документации Тильды.

Почему не стоит называть ловушку Email

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

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

Браузер может распознать название вроде email и самостоятельно подставить в невидимое поле адрес настоящего пользователя. В результате нормальная заявка будет ошибочно отмечена как спам. Кроме того, отдельный тип поля Email в Тильде автоматически проверяет формат адреса. Для скрытого поля такая проверка нам с вами совсем не нужна.

Не стоит использовать и слишком очевидные названия:

honeypot
bot_field
spam
trap
antibot

Более умная программа может понять, зачем создано такое поле.

Лучше выбрать правдоподобное, но не слишком распространённое имя:

website
company_website
contact_url
website_url
url_site

Подбирайте название с учётом конкретного сайта.

url_site

Создаём поле в форме Тильды

1. Откройте нужную форму и перейдите в её настройки.
2. Добавьте новое поле типа «Поле для ввода в одну строку».
3. Впишите имя переменной url_site.
4. Оставьте пустыми заголовок, подзаголовок, подсказку и значение по умолчанию.
5. Убедитесь, что поле не является обязательным.

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

Скрываем поле при помощи CSS

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

В открывшееся поле добавляем следующий код. Замените url_site на имя переменной вашего honeypot-поля:

.t-input-group[data-field-name="url_site"] {
  position: absolute !important;
  left: -9999px !important;
  top: auto !important;
  width: 1px !important;
  height: 1px !important;
  overflow: hidden !important;
  opacity: 0 !important;
  pointer-events: none !important;
  margin: 0 !important;
  padding: 0 !important;
}

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

Например, если поле называется:

company_website

то CSS-селектор должен выглядеть так:

.t-input-group[data-field-name="company_website"]

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

Как проверить, что всё работает

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

Поля url_site видно быть не должно.

Но на этом проверку лучше не заканчивать.

Откройте инструменты разработчика:

• Windows и Linux: F12 или Ctrl+Shift+J;
• macOS: Cmd+Option+J.

Найдите форму в HTML-коде и убедитесь, что внутри неё действительно существует элемент:

<input name="url_site">

После этого отправьте обычную тестовую заявку и проверьте:

1. форма успешно отправилась;
2. данные пришли в Тильду или CRM;
3. поле url_site присутствует в заявке;
4. его значение осталось пустым.

Затем можно временно отключить скрывающий CSS в инструментах разработчика, заполнить url_site тестовым значением и повторно отправить форму.

Во второй заявке поле уже должно прийти заполненным. Так мы получим два понятных примера:

Что можно сделать дальше

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

• не отправлять заявку в CRM, если honeypot-поле заполнено;
• показывать боту обычное сообщение об успешной отправке, но не создавать сделку;
• передавать срабатывание в Яндекс Метрику отдельной целью;
• сравнивать источники нормальных и подозрительных заявок;
• не использовать спам-цель для обучения рекламных кампаний.

Чего не умеет простое скрытое поле

Важно понимать ограничения этой механики. Honeypot ловит только тех ботов, которые нашли поле и решили его заполнить.

Он не поймает:

• бота, который умеет определять скрытые элементы;
• бота, заполняющего только имя и телефон;
• программу, отправляющую данные напрямую на обработчик формы;
• человека, намеренно оставляющего фальшивые заявки;
• пользователя, который ввёл в обычные поля бессмысленный текст;
• заявку, отправленную подозрительно быстро, если honeypot остался пустым.

Например, человек или более умный бот может не трогать url_site, но написать в поле имени «ываыва», указать набор одинаковых цифр вместо телефона и отправить форму за 1–3 секунды.

Дополнительно можно анализировать:

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

Над таким решением я работаю с марта 2026 года.

В одной из следующих статей покажу простой скрипт, который сможет запрещать отправку заявки при заполненном honeypot-поле, передавать попытку в Метрику отдельной целью и не создавать такую заявку в CRM.

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

Всем желаю всего самого наилучшего и как можно реже сталкиваться с фродом!