Настройка спам-фильтра Тильды: как отсечь ботов без потери заявок

Спам в форме на Тильде выглядит одинаково почти у всех: за ночь прилетает 30-50 заявок с текстом «продвижение сайта в топ», ссылками на сомнительные ресурсы или вовсе пустыми полями, а между ними теряются два-три настоящих клиента. Я разгребал такие формы на десятке проектов клиентов и в итоге собрал рабочую связку способов, которая режет ботов, но не режет живых людей. Ниже настройка спам фильтра Тильды по шагам: от встроенных инструментов конструктора до кастомного скрипта и фильтрации на стороне CRM.

Откуда в формах Тильды берётся спам

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

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

Что даёт встроенная защита форм в Тильде

В настройках формы у блока есть переключатель защиты от роботов, который подключает Google reCAPTCHA v3. Он работает в фоне и не показывает пользователю картинки с светофорами, вместо этого считает поведенческий скор и присваивает заявке отметку, похожа она на бота или нет.

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

Второе ограничение в том, что часть скриптов-спамеров отправляет данные напрямую на URL вебхука формы, минуя саму страницу и JavaScript Тильды. В этом случае reCAPTCHA вообще не срабатывает, потому что она завязана на рендер формы в браузере, а не на приём данных на сервере.

Настройка спам фильтра через невидимую проверку

Если защита ещё не включена, это первый шаг и он занимает пару минут. В редакторе Тильды нужно открыть настройки сайта, раздел «Формы», и включить пункт защиты от спама и ботов. После включения Тильда сама подключает reCAPTCHA v3 ко всем формам на сайте без правки кода.

Дальше стоит проверить два момента. Во-первых, куда именно уходят заявки: если это почта, полезно посмотреть письма несколько дней и прикинуть, сколько в потоке реального спама после включения защиты. Во-вторых, если формы ведут в CRM через вебхук, скор antispam из reCAPTCHA нужно явно вытаскивать из тела запроса и фильтровать по порогу на приёмной стороне, потому что сама Тильда решения не отправлять не принимает.

На практике reCAPTCHA v3 отсекает до 60-70% автоматического спама почти без усилий, но не трогает ручной спам и ботов, которые бьют прямо в вебхук.

Кастомный скрипт-фильтр на стороне формы

К встроенной защите я добавляю два простых приёма прямо в код страницы через Zero Block. Оба ловят именно то, что пропускает reCAPTCHA, и вместе с ней закрывают почти весь автоматический спам.

Honeypot-поле

Идея старая, но рабочая: в форму добавляется скрытое поле, которое не видно человеку, но которое находят и заполняют скрипты, читающие HTML напрямую. Если поле заполнено при отправке, значит форму дёргал бот, и заявку можно смело отбрасывать до попадания в CRM.

<style>
  .hp-field { position: absolute; left: -9999px; top: -9999px; }
</style>
<script>
document.addEventListener('submit', function (e) {
  var form = e.target;
  var honeypot = form.querySelector('input[name="website"]');
  if (honeypot && honeypot.value.trim() !== '') {
    e.preventDefault();
    e.stopPropagation();
  }
}, true);
</script>

Поле с именем website добавляется в саму форму как текстовое, а классом hp-field прячется от людей, но остаётся доступным для парсеров разметки. Имя поля стоит менять раз в несколько месяцев, потому что спам-скрипты умеют запоминать типовые ловушки по названию.

Тайм-трап на скорость заполнения

Живой человек тратит на заполнение формы из трёх-четырёх полей минимум 5-7 секунд, а скрипт делает это за десятые доли секунды сразу после загрузки страницы. Засекаю время между появлением формы в DOM и моментом отправки, и если оно меньше 2 секунд, считаю заявку подозрительной и добавляю к ней скрытую метку.

var formLoadedAt = Date.now();
document.addEventListener('submit', function (e) {
  var elapsed = Date.now() - formLoadedAt;
  if (elapsed < 2000) {
    var flag = document.createElement('input');
    flag.type = 'hidden';
    flag.name = 'suspicious';
    flag.value = 'fast_submit';
    e.target.appendChild(flag);
  }
}, true);

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

Добавление обоих приёмов в форму Тильды через Zero Block занимает 15-20 минут, если код уже готов, и это как раз тот объём работы, который я закрываю как простую доработку от 3 000 ₽. Если нужна более глубокая связка с проверкой полей, защитой от дублей заявок и отдельной логикой на нескольких формах сайта, это уже комплексная интеграция от 40 000 ₽. Готовые фрагменты для похожих задач на Тильде я собираю в библиотеке скриптов, откуда их можно взять и адаптировать под свою форму.

Фильтрация заявок после отправки: CRM, Telegram и n8n

Даже с honeypot и тайм-трапом часть спама всё равно доходит до вебхука, потому что не все боты рендерят JavaScript страницы. Здесь фильтрацию переношу на приёмную сторону, туда, где заявка уже стала обычным HTTP-запросом с данными.

Если заявки падают в Telegram через бота на aiogram, проверку делаю прямо в обработчике вебхука: сверяю телефон на соответствие маске, отбрасываю заявки с пустым или одинаковым текстом комментария, ограничиваю число заявок с одного IP за короткий промежуток. Ботов, которые дёргают форму раз в секунду с одного адреса, такая проверка отсекает почти полностью. Разработка такого Telegram-бота с фильтром на входе стоит от 30 000 ₽.

Если между Тильдой и CRM или Telegram стоит n8n, фильтр выносится в отдельный узел до того, как заявка уйдёт дальше по цепочке. В функции на JavaScript внутри Function-ноды проверяю поле antispam_score из reCAPTCHA, поле suspicious из тайм-трапа и наличие ссылок в текстовых полях, а заявки, не прошедшие проверку, увожу в отдельный лог вместо основного потока лидов. Такая автоматизация в n8n стоит от 25 000 ₽ и её удобно донастраивать без правок кода на самом сайте, меняя логику только в сценарии.

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

Сравнение способов защиты форм

На практике связка из всех четырёх уровней закрывает 90-95% спама, а оставшаяся часть требует ручного разбора раз в неделю. Убрать спам полностью без единого ложного срабатывания не получится ни на одной платформе, вопрос только в том, сколько мусора остаётся терпимым для конкретного бизнеса.

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

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

Можно ли обойтись только встроенной reCAPTCHA Тильды?

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

Не потеряю ли я реальные заявки из-за фильтра?

Риск есть у любого фильтра, но он управляется жёсткостью правил. Honeypot и reCAPTCHA v3 почти никогда не задевают живых людей, а вот жёсткий тайм-трап без запаса по времени иногда режет заявки от людей с автозаполнением браузера. Я закладываю порог не меньше 2 секунд и смотрю статистику отсева первую неделю после запуска.

Спам всё равно проходит через все фильтры, что делать?

Обычно это значит, что заявки идут напрямую на URL вебхука, не загружая страницу с формой в браузере, тогда клиентская защита в принципе не может сработать. В этом случае фильтрацию переношу на сторону приёма данных: в n8n или в обработчик Telegram-бота, где можно проверять формат полей, скорость повторных обращений и содержимое текста уже после получения запроса.

Стоит ли ставить капчу с картинками вместо невидимой reCAPTCHA?

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