---
title: "Защита от ботов, которая выгоняет живых: как фильтры режут реальных клиентов"
description: "Жёсткая защита от ботов часто блокирует реальных клиентов из-за медленного интернета или нестандартных браузеров. Разбираем, как найти эти ошибки до запуска сайта и почему синтетические тесты не видят проблему."
date: 2026-11-14T20:22:39.681Z
lang: ru
url: https://xab.info/posts/zashchita-ot-botov-kotoraya-rezet-zhivyh-klientov
tags: [web-development, seo, traffic, bot-protection, web-analytics, user-experience]
author: "Александр Буран"
publisher: "XAB.info"
---

# Защита от ботов, которая выгоняет живых: как фильтры режут реальных клиентов

![Коллаж из шести изображений: дорога, старый ключ, ворота в тумане, ножницы, силуэт человека на фоне света и цепь.](https://xab.info/media/2026/11/14/zashchita-ot-botov-kotoraya-rezet-zhivyh-klientov/zashchita-ot-botov-kotoraya-rezet-zhivyh-klientov-1.webp)

## Ключевые тезисы

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

Ситуация знакомая любому, кто запускал сайт с формами, корзинами или личными кабинетами. Разработчик делает всё по инструкции: капча на форму, фильтр по частоте запросов, блокировка подозрительных стран. Сайт защищён, боты не проходят. А через неделю владелец открывает обратную связь и видит: «Не могу оформить заказ», «Капча не грузится», «Сайт не работает, хотя интернет есть».

Проблема в том, что защиту тестируют обычно один человек, в одном браузере, из одного города, на одном устройстве. Для него всё работает. А клиент из другого региона, на другом телефоне, с другим браузером — не проходит. И не потому, что он бот. А потому что защита, настроенная на жёсткость, не различает «странный, но живой» запрос и «странный, потому что автоматический». Она просто режет. И режет тех, кто пришёл купить.

### Как выглядит защита, которая режет живых

[

](/images/zashchita-ot-botov-kotoraya-rezet-zhivyh-klientov-4)

Самый частый сценарий — капча, которую невозможно решить. Не потому, что она сломана в целом, а потому что для конкретного пользователя она не грузится, грузится криво, или просто не распознаётся. Человек трижды вводит символы, трижды получает «неверно», и уходит. Для владельца сайта это выглядит как один отказ. Для рынка — как потерянный заказ. А если таких людей десять в день, то за месяц это уже ощутимая дыра в выручке, которую никто не замечает, потому что в статистике просто «низкая конверсия».

Второй сценарий — жёсткий фильтр по частоте запросов. Сайт считает, что если с одного адреса за минуту пришло больше пяти запросов, это бот. Но живой человек на медленном мобильном интернете открывает страницу, та не грузится, он обновляет. Ещё раз. Ещё. Через минуту у него уже семь запросов, и сайт его блокирует. Человек видит пустую страницу или сообщение «слишком много попыток». Он не бот. Он просто на плохом покрытии. Но защита не знает об этом.

Третий — блокировка по странам. Разработчик смотрит на статистику атак, видит, что половина запросов с определённых территорий, и ставит запрет. А потом выясняется, что в этих странах живые клиенты, которые заказывали раньше. Или что у человека роуминг, и он физически в одной стране, а его запрос идёт через другую. Защита не разбирает контекст. Она видит страну и решает.

Четвёртый, менее очевидный: скрипт, который проверяет «живость» браузера. Он проверяет наличие определённых параметров, версию движка, набор функций. И если браузер не соответствует — страница не рендерится. Человек видит пустой экран или половину вёрстки. Для него сайт «сломался». Для разработчика — «браузер не поддерживается». Но это не про поддержку. Это про то, что проверка живости написана так, что она не проходит на нормальных, но нестандартных конфигурациях.

### Почему «на глаз» не проверить

[

](/images/zashchita-ot-botov-kotoraya-rezet-zhivyh-klientov-5)

Главная ловушка: разработчик и владелец сайта видят всё нормально. Они открывают сайт в Chrome на десктопе, в своей стране, на хорошем интернете. Всё грузится, капча решается, форма отправляется. Тест пройден. Сайт запущен. А потом приходят клиенты — с Android на слабом покрытии, с Safari на iPhone, с Firefox на ноутбуке, из другой страны, с расширением, которое меняет заголовок браузера. И для них сайт другой. Не потому, что он сломан. А потому, что они не те, кто его проверял.

Синтетические тесты нагрузки, которые часто используют для проверки сервера, тут не помогают. Они шлют запросы на сервер и смотрят, как сервер отвечает. Но они не исполняют JavaScript, не грузят страницу целиком, не рендерят вёрстку, не решают капчу. Для них страница — это набор байтов. А для живого человека — это то, что он видит на экране. И если JavaScript не отработал, если шрифт не подгрузился, если форма не инициализировалась — сервер при этом может отвечать «200 OK» и считать, что всё в порядке. А человек видит кривую страницу и уходит.

Ещё один момент: защита часто включается не сразу. Первые запросы проходят нормально, а потом, когда счётчик запросов с одного адреса превышает порог, включается блокировка. Тестировщик делает пять запросов, всё работает, он закрывает браузер. А клиент делает пятнадцать — и получает стену. Тест не воспроизводит реальное поведение пользователя, потому что тестировщик не пользователь. Он проверяет функцию, а не сценарий.

### Что именно ломается и как это заметить

[

](/images/zashchita-ot-botov-kotoraya-rezet-zhivyh-klientov-6)

Список того, что может сломаться из-за слишком жёсткой защиты, невелик, но каждый пункт бьёт по деньгам. Вёрстка: страница не рендерится полностью, блоки не встают на место, кнопки не кликаются. Счётчики: скрипт аналитики не может отправить данные, потому что запрос заблокирован фильтром, и владелец видит в статистике дыры — не потому, что людей нет, а потому, что их посещений не записали. Формы: отправка не проходит, потому что запрос с формой выглядит как «подозрительный» для фильтра. Корзины: сессия обрывается, потому что проверка «живости» не прошла на втором шаге. Личные кабинеты: вход не работает, потому что авторизация требует определённых параметров, а защита их не пропускает.

Как понять, что проблема именно в защите, а не в сайте? Простой тест: отключить защиту на десять минут и посмотреть, что происходит. Если формы снова работают, если вёрстка встала, если счётчики пошли — значит, дело было в фильтре. Но это тест «после», когда уже что-то сломалось. А нужно понимать заранее, до запуска или до изменения настроек. И для этого нужен не один браузер в одном городе, а много браузеров в разных точках.

### Прогнать сайт реальными браузерами: идея

Идея простая и, если честно, немного ироничная: тот же инструмент, которым накручивают трафик, здесь работает во благо. Напомню, что накрутка — это когда сайт открывают автоматические программы, чтобы статистика выглядела лучше. А тут то же самое, только наоборот: сайт открывают автоматические программы, чтобы проверить, не душит ли защита нормальных посетителей. Разница в цели. Механизм один и тот же: настоящий браузерный движок открывает страницу, выдерживает заданное время, прокручивает, кликает, заполняет поля. И если на каком-то шаге страница не грузится, форма не работает, капча не появляется — это видно. Не в логах сервера, а на экране. Как видит человек.

Почему это лучше, чем синтетический тест нагрузки? Потому что просмотрщик грузит страницу целиком. Он исполняет JavaScript, рендерит вёрстку, загружает шрифты, картинки, скрипты. Он ведёт себя как обычный посетитель, только без сознания. И если защита его душит — значит, она душит и живых. Если нет — значит, живые проходят. Это не гарантия, что каждый конкретный пользователь пройдёт, но это гораздо ближе к реальности, чем «сервер ответил 200».

Где взять такой трафик для теста? Источник, который для этого подходит, — [9Hits](https://9hits.com/?ref=276016). Это биржа обмена трафиком, которая работает с 2010-х годов. Участник ставит программу-просмотрщик, и она сама, без человека, открывает сайты в настоящем браузерном движке, выдерживает заданное время и идёт дальше. За это начисляются поинты. А поинты тратят на свою кампанию: адрес сайта, время на странице, частота, страны. Сайт открывается в просмотрщиках других участников по всему миру. Есть макросы — сценарии действий на странице: прокрутка, клики, заполнение полей. Для теста защиты это ровно то, что нужно: можно задать, чтобы на странице была прокрутка, клик по кнопке формы, ввод в поле. И посмотреть, что происходит.

### Поинты для разового теста: копить не обязательно

[

](/images/zashchita-ot-botov-kotoraya-rezet-zhivyh-klientov-2)

Единственное, что может отпугнуть: «мне нужно сначала копить поинты, чтобы потом тратить». Для регулярной работы — да, участник копит, пока его просмотрщик открывает чужие сайты. Но для разового теста, который нужен один раз — перед запуском или перед изменением настроек защиты, — копить не обязательно. Есть вариант взять [готовые поинты](https://9hitshub.com/). Это не подписка, не абонемент, не «закажите пакет». Это просто количество, которое можно взять на один прогон. Запустил кампанию на свой сайт, посмотрел, что происходит в разных странах и на разных сценариях, закрыл. Поинты потрачены, тест сделан.

Важно понимать, что это автоматический трафик программ, не живые люди. Никто не сидит и не кликает. Это движок браузера, который открывает страницу и выполняет заданные действия. Для теста защиты это не недостаток, а достоинство: он не устанет, не забудет нажать кнопку, не закроет вкладку через три секунды. Он будет делать ровно то, что задано в макросе. И если на третьем шаге страница не загрузилась — это будет видно в отчёте. Не «по ощущениям», а конкретно: страница X, время Y, статус Z.

### Что именно проверять после прогона

[

](/images/zashchita-ot-botov-kotoraya-rezet-zhivyh-klientov-3)

Чек-лист невелик, но каждый пункт стоит пройти. Первое: вёрстка. Открывается ли страница целиком? Не обрывается ли на полпути? Не «прыгает» ли контент? Если на каком-то сценарии страница грузится наполовину — это проблема. Не обязательно в защите, но проверить стоит.

Второе: формы. Заполняются ли поля? Отправляется ли форма? Появляется ли сообщение об успехе или об ошибке? Если форма не отправляется — это либо защита, либо баг. Но если она не отправляется только в определённых странах или на определённых сценариях — это почти наверняка защита.

Третье: капча. Появляется ли она? Решается ли? Если на одном сценарии капча есть, а на другом — нет, или она грузится, но не отображается — это проблема. Живой человек в такой ситуации уйдёт.

Четвёртое: счётчики. Если после прогона в аналитике нет данных — значит, скрипт аналитики не смог отправить запрос. И живые посетители тоже не будут записаны. Статистика будет врать: людей нет, хотя они были.

Пятое: скорость. Не обязательно, чтобы страница грузилась за 0,3 секунды. Но если на одном сценарии она грузится за две секунды, а на другом — за восемь, и на восьмисекундном она не догружается — это проблема. Живой человек на медленном интернете не будет ждать восемь секунд. Он обновит. А обновление — это ещё один запрос. А ещё один запрос — это ещё один шаг к блокировке.

Шестое: сессии. Если пользователь «проходит» форму на первом шаге, а на втором сессия обрывается — это проблема. Живой человек заполнит имя, перейдёт к следующему полю, и его сессия закончится. Он увидит пустую страницу или сообщение «сессия истекла». И уйдёт.

### Как не перемудрить с защитой

Защита нужна. Боты есть, и они режут репутацию, спамят формы, грузят сервер. Но защита, которая не различает бота и живого человека на плохом интернете, — это не защита. Это фильтр, который режет всех подряд. И главный принцип: защита должна пропускать живых. Не «в основном пропускать», не «большинство проходят», а пропускать. Если живой человек не может пройти — это не его проблема. Это проблема настройки.

Практический вывод из всего вышесказанного: перед запуском сайта или перед изменением настроек защиты прогнать его реальными браузерами из разных стран. Не одним браузером в одном городе. Не синтетическим тестом, который смотрит только на сервер. А полноценным прогон, где страница грузится целиком, JavaScript исполняется, формы заполняются, прокрутка работает. И посмотреть, что происходит. Если на каком-то сценарии живые не проходят — это видно. Не через неделю, когда уже ушли клиенты, а до. Пока можно поправить.

И последнее. Защита — это не «поставил и забыл». Браузеры обновляются, движки меняются, новые расширения появляются, новые страны подключаются. То, что работало три месяца назад, может не работать сегодня. Не потому, что сайт сломался. А потому, что мир изменился. И проверка, которую один раз сделали перед запуском, через полгода уже не актуальна. Это не приговор. Это просто значит, что защита — не разовая настройка, а процесс. И чем раньше видно, что она режет живых, тем меньше теряется. Не в статистике. В деньгах.

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

### А если на сайте только статьи и нет форм — мне это не грозит?

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

### Можно ли просто выключить капчу или фильтр, чтобы перестать блокировать клиентов?

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

### Сколько поинтов нужно для одного прогона?

Точной цифры нет — она зависит от параметров кампании: сколько стран, какое время на странице и какая частота. Для разового теста достаточно взять количество на один прогон, это не подписка и не накопление.

### Клиенты уже жалуются, что не могут оформить заказ. Что делать прямо сейчас?

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

### Мобильные устройства — это отдельный сценарий или достаточно десктопа?

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

### Нужно ли повторять прогон после каждого обновления сайта?

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