Туристический сайт – это не лендинг с одной кнопкой. Это десятки страниц направлений, фильтры подбора туров, календари вылетов, формы заявок и интеграции с поисковиками. Именно поэтому боты здесь чувствуют себя вольготно: они бьют по самым дорогим для вас точкам – по страницам поиска туров и по формам лидогенерации. За годы работы с такими проектами я собрал короткий набор признаков, по которым бота видно за пять минут в логах, даже если он маскируется под реального пользователя. Ниже – четыре сигнала, которые чаще всего выдают автоматический трафик в туризме.
Запросы без Referer и пустой клиентский след
Живой человек почти никогда не попадает на страницу тура из ниоткуда. Он приходит из поиска, из Telegram-канала, из письма, из рекламы в Дзене, наконец, просто кликает по ссылке внутри вашего же сайта. Во всех этих случаях браузер передаёт заголовок Referer. Бот, который парсит ваш каталог напрямую, обычно ходит с пустым или фиктивным Referer: он не симулирует переход, ему нужны данные, а не путь к ним.
Второй слой того же сигнала – отсутствие зависимых запросов. Реальный браузер, открывая страницу с подбором туров, тянет CSS, шрифты, скрипты аналитики, картинки отелей. В логах это видно как каскад запросов с одного IP в пределах пары секунд. Если вы видите одиночный GET на HTML-страницу без единого запроса к статике, это почти наверняка бот. Особенно если он повторяется с интервалом, который человек физически не способен выдержать.
Третий маркер в этой же группе – заголовок User-Agent. Парсеры часто представляются как библиотеки: python-requests, curl, Go-http-client, Java. Иногда они маскируются под Chrome, но выдают себя несоответствием версии браузера и набора заголовков: нет Accept-Language, нет Sec-Fetch-*, нет Cookie. Такой профиль не бывает у живого посетителя из России, который ищет тур в Турцию на майские.
Идеально ровные интервалы между запросами
Человек не ходит по сайту с точностью метронома. Он открыл страницу, залип на фотографиях отеля, вернулся к фильтрам, сравнил цены, ушёл пить чай. В логах это выглядит как рваный ритм: пауза 40 секунд, потом три запроса за две секунды, потом минута тишины. Бот работает иначе: он ставит sleep(1) или sleep(2) между итерациями, и вы получаете запросы с интервалом ровно 1000 или 2000 миллисекунд. Десятки раз подряд.
Именно этот признак сложнее всего подделать без серьёзной инженерной работы. Даже продвинутые парсеры с рандомизацией задержек часто выдают себя распределением: у человека оно длиннохвостое, у бота – близкое к нормальному с узким разбросом. Достаточно построить гистограмму интервалов между запросами с одного IP или одной подсети, и картина становится очевидной. На туристических сайтах это особенно заметно на страницах поиска туров, где бот прогоняет сотни комбинаций “страна + дата + ночей” одну за другой.
Отдельный случай – синхронизированные атаки с ботнета. Интервалы там могут быть рваными, но зато вы видите всплеск запросов с сотен IP на один и тот же URL. Это уже не парсинг, а L7 DDoS или попытка выкачать базу через перебор. Для защиты от таких сценариев нужен не только лог-анализ, но и веб-платформа с фильтрацией на уровне приложений. аналог cloudflare offers additional context worth reviewing. Например, TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре, поэтому аномалии по интервалам и Referer видны сразу в панели, а не после выгрузки логов в Excel.
Прямые URL поиска туров и обход воронки
Нормальный посетитель туристического агентства проходит путь: главная, направление, фильтр, карточка отеля, форма заявки. Бот этот путь игнорирует. Он сразу стучится в URL вида /search?country=eg&date=2026-06-01&nights=7&adults=2 и начинает перебирать параметры. Такие запросы почти никогда не имеют Referer, потому что бот не кликал по ссылке, а сконструировал её сам. Если в логах видно, что 80 процентов обращений к поиску туров идут без Referer и с прямыми параметрами, это красный флаг.
Второй признак в этой группе – отсутствие загрузки картинок и JS. Боту не нужны фотографии отелей и скрипты бронирования. Он забирает HTML, вытаскивает цены и даты, и уходит. В логах это выглядит как страница поиска туров с кодом 200, но без единого запроса к /img/ или /js/. Для сайта на WordPress или Bitrix это особенно заметно: у живого пользователя почти всегда есть запросы к теме, плагинам, скриптам аналитики. У бота – только голый HTML.
Третий маркер – поведение на формах. Бот может отправить заявку с невалидным телефоном, с email вида test@test.com, с именем из трёх одинаковых букв. Или наоборот: заполнить форму идеально, но за 200 миллисекунд, быстрее, чем человек успевает прочитать поля. На туристических сайтах такие заявки бьют по конверсии сайта напрямую: менеджеры тратят время на мусорные лиды, а реальные клиенты ждут ответа. WAF-блокировки на уровне формы решают это, если настроены не на капчу ради капчи, а на поведенческие признаки.
Четвёртый сигнал, который часто упускают, – география. Если ваш туристический сайт работает на Россию, а из логов сыпется трафик с IP из дата-центров в Нидерландах или США, это почти наверняка бот. GeoIP-фильтрация здесь работает не как запрет, а как маркер: запросы из хостинговых подсетей можно сразу помечать и проверять жёстче, чем запросы из домашних сетей российских провайдеров.
Соберите эти сигналы в одну картину: пустой Referer, ровные интервалы, отсутствие статики, прямые URL поиска. По отдельности каждый из них даёт ложные срабатывания. Вместе они рисуют портрет бота, который не тратит время на имитацию человека. Дальше вопрос инфраструктуры: либо вы фильтруете этот трафик на уровне веб-платформы, либо он продолжает жечь ваш трафик, портить аналитику и забивать отдел продаж мусорными заявками. Российский аналог Cloudflare вроде TrafficVeil закрывает эту задачу без тарификации ботов, атак и WAF-блокировок, что для туристического сайта с сезонными пиками нагрузки даёт предсказуемый счёт и чистые логи.