-
Запрос
Серверная проверка полей
-
Фильтр
Частота и признаки автоматизации
-
Сохранение
Принятая заявка или карантин
-
Контроль
Ложные блокировки и доставка
Защита формы от спама должна проверять запрос на сервере, ограничивать злоупотребления и сохранять нормальные обращения. CAPTCHA сама по себе не закрывает все способы отправки. Начните с разделения ошибок: автоматический мусор, повтор одной заявки, рекламные предложения и настоящий клиент с необычным сообщением требуют разных правил обработки.
Выясните, откуда приходит мусор
Сравните время, форму, источник и технический результат отправки. Не нужно выгружать весь текст заявок в общедоступную таблицу. Для анализа обычно достаточно внутреннего идентификатора обращения, маршрута формы, решения фильтра и обезличенных признаков. Сырые контакты оставляют в системе с ограниченными правами. Сбор лишних данных не делает защиту точнее.
Если одинаковое обращение появляется дважды после одного нажатия, это может быть ошибка интеграции, а не бот. Проверьте обработчик формы, повтор сетевого запроса и доставку в CRM. Если мусор приходит только на email, выясните, создаётся ли он через сайт или отправляется напрямую на опубликованный адрес. Защита формы не остановит письмо, которое прошло мимо неё.
Проверьте серверный вход
Браузерная проверка обязательного телефона помогает человеку, но не мешает скрипту отправить запрос напрямую. Сервер должен самостоятельно проверять типы полей, длину текста, допустимый формат контакта и размер тела запроса. Поля, которых нет в форме, не должны позволять менять получателя письма или ответственного в CRM. Эти значения задаются доверенной конфигурацией.
Проверка телефона отвечает на вопрос о допустимом формате, а не о существовании владельца. Не блокируйте иностранный номер, если компания работает с зарубежными клиентами. Не пытайтесь восстановить недостающие цифры. Покажите ошибку рядом с полем и дайте исправить значение, сохранив остальную введённую информацию. Повторный ввод длинного сообщения увеличивает вероятность ухода.
Для текста установите разумный предел и безопасный способ отображения в письме, CRM и панели оператора. HTML из сообщения не должен исполняться. При этом слово «купить», ссылка на собственный сайт или короткое описание задачи не доказывают спам. Чёрный список отдельных слов быстро начинает отсекать реальные коммерческие запросы.
Ограничивайте частоту с учётом сценария
Лимит отправок защищает от массовой нагрузки. Его выбирают по данным формы и особенностям аудитории, а не по универсальному числу из чужого проекта. Несколько сотрудников одной компании могут выходить с общего IP. Слишком строгий запрет на весь адрес закроет доступ сразу всем, хотя нарушение совершил один посетитель.
Разделите кратковременный всплеск и длительную серию запросов. Для тяжёлых операций полезен отдельный предел параллельных задач. При превышении лимита возвращайте понятный отказ с возможностью повторить позже. Нельзя показывать «заявка отправлена», если сервер её не принял. Это скрывает проблему от посетителя и делает отчёт по конверсии недостоверным.
Используйте CAPTCHA как дополнительную проверку
Если форма получает токен CAPTCHA, сервер проверяет его у поставщика и учитывает результат. Сам факт наличия строки token в запросе ничего не доказывает. Для используемой версии проверяют предусмотренные атрибуты, срок действия и соответствие сценарию. Тест с отключённой браузерной проверкой обязателен: напрямую отправленный запрос не должен обходить защиту.
Посмотрите, что происходит при недоступности сервиса проверки. Бесконечный индикатор загрузки и потерянный текст — плохой запасной сценарий. Покажите сообщение о проблеме, сохраните введённые поля на экране и предложите прямой способ связи. Если предусмотрен приём в карантин, отделите его от подтверждённой доставки менеджеру и защитите от переполнения.
Скрытое поле-ловушка и время заполнения могут давать дополнительные сигналы. Не делайте их единственным основанием отказа без тестов: менеджеры паролей заполняют поля автоматически, а человек иногда вставляет заранее подготовленный текст. Проверяйте форму с клавиатуры, на телефоне и с привычным автозаполнением браузера.
Отделите карантин от удаления
Подозрительные обращения удобно направлять в отдельную очередь с причиной решения. У неё должны быть срок хранения, ответственный и ограничение размера. Бесконечно складывать туда весь поток опасно для базы и бесполезно для команды. Статистику фильтра можно сохранять дольше, чем тексты и контакты, если это соответствует принятому порядку обработки данных.
Учебный пример: форма получила короткое сообщение со ссылкой и корректным телефоном. Правило считает комбинацию подозрительной, но не находит признаков массовой отправки. Вместо безвозвратного удаления обращение попадает на ручную проверку. Менеджер видит основание и может восстановить обычный маршрут. Дальше команда уточняет правило по конкретным ошибкам, а не усиливает фильтр наугад.
Измеряйте ложные блокировки
Одного уменьшения числа заявок недостаточно, чтобы признать защиту успешной. Сравните принятые обращения, отклонения, технические ошибки и решения после ручной проверки. Посмотрите, не выросла ли доля отказов у мобильных посетителей, зарубежных номеров или определённого браузера. Без такого разреза сокращение мусора легко спутать с поломанной формой.
Цель аналитики должна срабатывать после принятия заявки, а не по клику на кнопку. В CRM и на почту передают уже сохранённое обращение. Сбой одного канала не должен удалять запись или мешать другому. Порядок независимой доставки разобран в статье о заявках в Битрикс24 и на email.
Набор тестов перед публикацией
- Пустой обязательный контакт: понятная ошибка, нет новой заявки.
- Нормальное обращение: одна сохранённая запись и подтверждение посетителю.
- Двойное нажатие и повтор запроса: нет второй сделки из-за технического повтора.
- Серия автоматических запросов: ограничение срабатывает, сайт остаётся доступен.
- Недоступная CAPTCHA: форма не зависает, доступен согласованный запасной путь.
- Автозаполнение и мобильный браузер: реальные данные не теряются.
Все проверки выполняют тестовыми контактами с согласованным получателем. Нагрузочный сценарий сначала запускают на стенде, а не на рабочем сайте. Зафиксируйте ожидаемые ответы, ограничение частоты и план отключения нового правила. После релиза просмотрите первые обращения и причины отказов; при росте ложных срабатываний откатывают конкретный фильтр, не всю защиту.
Если заявки проходят фильтр, но теряются дальше, потребуется разбор всей цепочки: сайт, очередь, почта, CRM и действия менеджера. Для постановки задачи полезна карта полей и тестов интеграции. Так команда исправит источник проблемы и сможет доказать результат повторяемой проверкой.
