За последний год у трёх моих клиентов на Тильде количество заявок в форме выросло в 5-10 раз без роста трафика и продаж. Все письма оказались одним и тем же спамом: реклама SEO-продвижения, крипто-проекты, попытки подбора пароля к почте менеджера через поле комментария. Защита форм Тильды от спама - тема, с которой сталкивается почти любой проект с открытой формой заявки, потому что боты сканируют список публичных лендингов и заливают запросы напрямую, минуя браузер и интерфейс сайта. Разберу, какие способы реально работают на Tilda, а какие только создают видимость защиты и мешают живым клиентам.
Откуда на самом деле берется спам в формах Тильды
Форма на Тильде отправляет данные на внешний адрес forms.tildaapi.com методом POST с идентификатором формы (formid) и идентификатором проекта. Проблема в том, что для отправки не обязательно открывать саму страницу: запрос уходит на публичный адрес API, и его легко повторить из скрипта, зная только formid. Часть спам-ботов вообще не заходит на сайт - они берут списки id форм с популярных площадок (в том числе и с Тильды) и веерно рассылают POST-запросы с мусорными данными.
На практике я делю спам на два типа:
- Простые боты - скрипты на Python или Node, которые подставляют случайный текст в известные поля формы (имя, телефон, email, комментарий) и стреляют по formid без открытия страницы. На такие запросы приходится 70-80% всего спама, который я вижу в проектах.
- Боты с браузерным движком - headless Chrome или Playwright, которые действительно открывают страницу, ждут загрузку скриптов Тильды и заполняют форму как человек. Их меньше, но именно они проходят обычную reCAPTCHA v2 и элементарные проверки на JS.
Смысл в том, что защита должна закрывать оба сценария, а не один. Если настроить только капчу, которая рисуется в браузере, боты первого типа спокойно проходят мимо неё, потому что вообще не рендерят страницу.
Honeypot-ловушки для простых ботов
Самый дешёвый и при этом рабочий приём - невидимое поле-приманка. Через блок с кастомным HTML (Zero Block или встроенный HTML-код) добавляется дополнительное поле формы с обычным именем вроде “company” или “middle_name”, которое визуально скрыто от человека (например, вынесено за пределы экрана через позиционирование, а не через display:none, потому что часть ботов проверяет именно это CSS-свойство). Реальный посетитель это поле не видит и не заполняет, а скрипт, который парсит все input формы и вставляет туда текст, попадается.
Проверка честно работает только если её делать не в браузере, а на приёме данных: Тильда отправляет вебхук с данными формы на внешний адрес, и уже там (в n8n, серверном обработчике или простом скрипте на Python) вы смотрите, пусто ли поле-приманка. Если там что-то есть, заявка помечается как спам и не попадает в CRM или Telegram менеджера.
document.addEventListener('submit', function (e) {
var form = e.target;
if (!form.classList.contains('t-form')) return;
var honeypot = form.querySelector('[name="company_hp"]');
var loadedAt = Number(form.dataset.loadedAt || 0);
var elapsed = Date.now() - loadedAt;
if (honeypot && honeypot.value) {
e.preventDefault();
return;
}
if (elapsed < 2500) {
e.preventDefault();
}
}, true);
Второй кусок в этом же скрипте, время между загрузкой страницы и отправкой формы, тоже честно фильтрует ботов. Человек тратит на заполнение формы из трёх-четырёх полей минимум 5-7 секунд, скрипт делает это за доли секунды. Я обычно ставлю порог в 2-3 секунды: ниже него отправку блокирую на стороне клиента, а заодно дублирую ту же проверку в обработчике вебхука, потому что JS на странице боты первого типа просто не выполняют.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Лимиты запросов и защита от флуда
У Тильды нет встроенного rate limit на количество отправок формы с одного IP или email. Если бот бьёт по formid раз в секунду, конструктор примет все запросы и передаст их дальше. Лимит приходится строить на промежуточном слое: у формы в настройках включается отправка данных на внешний адрес (вебхук), и туда уже прилетает сырой JSON на каждую заявку.
В n8n я обычно собираю сценарий из трёх шагов: приём вебхука, проверка через ноду с запросом к базе (Redis или обычная таблица) на количество заявок с этого email или телефона за последний час, и ветвление - чистые заявки уходят в CRM или в Telegram-бота на aiogram, подозрительные складываются в отдельный лог для ручной проверки. Порог обычно ставлю на уровне 3 заявок в час с одного контакта - больше на реальном сайте с одной формой заказа не бывает, разве что человек трижды поправляет опечатку в номере.
| Способ защиты | Что останавливает | Сложность внедрения | Влияние на конверсию |
|---|---|---|---|
| Honeypot-поле | Простых ботов, заполняющих все поля | Низкая | Нет |
| Проверка времени заполнения | Скрипты с мгновенной отправкой | Низкая | Нет |
| Лимит по IP/email через вебхук | Флуд и повторные атаки | Средняя, нужен внешний обработчик | Нет |
| Фильтр по содержимому заявки | Ссылки, стоп-слова, мусорные тексты | Средняя | Минимальное |
| reCAPTCHA v2 (чекбокс) | Часть ботов с браузерным движком | Низкая, есть в настройках Тильды | Заметное, до 10-15% отказов |
| reCAPTCHA v3 / Turnstile | Большинство автоматических отправок | Высокая, нужен кастомный код | Минимальное |
Фильтрация содержимого заявки
Даже если бот прошёл honeypot и лимиты, его выдаёт содержимое полей. В обработчике вебхука я обычно добавляю простые проверки: поле телефона должно соответствовать маске из цифр нужной длины, в поле имени не должно быть ссылок и HTML-тегов, в комментарии - стоп-слов вроде “casino”, “crypto”, “seo продвижение”, “заработок” и прямых ссылок на сторонние сайты. Заявки, где комментарий длиннее 500 символов и целиком состоит из ссылок, в 99% случаев спам, и такую проверку можно повесить отдельной нодой прямо в n8n-сценарии перед отправкой в CRM.
Отдельно проверяю совпадение имени и телефона с уже отклонёнными ранее заявками - если один и тот же номер за сутки прислал десяток заявок с разными именами, это тоже флудер, а не клиент, который просто передумал. Такую логику под конкретный проект я собираю как кастомную доработку формы с фильтрацией и интеграцией в CRM, потому что готового универсального решения под каждый набор полей на Тильде не существует - у всех разные формы и разные CRM на другом конце.
reCAPTCHA и её альтернативы на Тильде
В настройках формы у Тильды есть встроенная защита от спам-ботов на основе Google reCAPTCHA - это чекбокс v2, который включается парой кликов без кода. Работает он неплохо против ботов с браузерным движком, но на реальных проектах я вижу просадку конверсии на 10-15%: часть пользователей с мобильного интернета или в режиме экономии трафика чекбокс просто не проходит с первого раза и закрывает форму.
Более гладкий вариант - невидимая reCAPTCHA v3, которая не показывает чекбокс, а считает поведенческий скор в фоне и передаёт его вместе с заявкой. На Тильде она не встроена в интерфейс, её приходится подключать через кастомный код в Zero Block: скрипт Google подгружается на страницу, токен добавляется скрытым полем формы, а порог скора (обычно 0.5) проверяется уже на приёме данных в вебхуке. Из более лёгких альтернатив смотрю в сторону Cloudflare Turnstile - она меньше весит и не требует показывать пользователю картинки с автобусами, но точно так же встраивается только через кастомный код, а не через настройки конструктора.
Мониторинг и обработка подозрительных заявок
Фильтры никогда не работают на 100%, и часть спама всё равно проскакивает, а часть живых заявок иногда попадает под подозрение из-за странного имени или короткого комментария. Поэтому вместо жёсткого блокирования всего подозрительного я обычно делаю два потока: чистые заявки сразу летят в CRM и дублируются менеджеру в Telegram через бота на aiogram, а подозрительные (сработал один из фильтров, но не все сразу) падают в отдельный чат на модерацию, откуда их за пару секунд можно вручную одобрить или отклонить.
Тут же стоит учесть требование 152-ФЗ о локализации персональных данных: если через вебхук заявки с телефонами и именами складываются в таблицу или базу, она должна стоять на сервере в России, а не в Google Sheets или Airtable, куда данные российских клиентов по закону лучше не отправлять вообще. При настройке n8n-сценария это просто вопрос выбора хостинга для базы, а не переделки логики фильтрации.
Когда стандартных блоков не хватает
Кастомный скрипт
от 3 000 ₽
Подробнее →Частые вопросы
Помогает ли встроенная reCAPTCHA на Тильде на 100%?
Нет. Она отсекает часть автоматических отправок с браузерным движком, но простые скрипты, которые бьют напрямую по formid без загрузки страницы, капчу вообще не видят и проходят мимо неё. Для полного покрытия нужна связка из honeypot-поля, проверки времени заполнения и фильтрации на приёме данных.
Можно ли ограничить количество отправок формы прямо в настройках Тильды?
Встроенного лимита на частоту отправок с одного IP или email в конструкторе нет. Такую логику приходится выносить во внешний обработчик вебхука - я обычно собираю это в n8n или отдельном серверном скрипте, который считает заявки по контакту за период и блокирует повторные всплески.
Как отличить настоящую заявку от спама, если обе выглядят похоже?
Смотрю на совокупность признаков, а не на один. Валидный формат телефона и email, отсутствие ссылок в комментарии, разумное время заполнения формы и отсутствие повторных отправок с того же контакта за короткий срок вместе дают достаточно уверенный сигнал. Одиночный подозрительный признак я обычно отправляю на ручную модерацию, а не в автоматический бан.
Сколько стоит настроить защиту от спама на форме Тильды?
Точечная доработка вроде honeypot-поля и проверки времени заполнения обходится от 3 000 ₽. Комплексная защита с внешним обработчиком вебхука, лимитами по контактам, фильтрацией содержимого и интеграцией с CRM или Telegram-ботом - это уже отдельный сценарий автоматизации, и такие проекты у меня стартуют от 40 000 ₽ в зависимости от количества полей и систем, с которыми форма должна быть связана.