Блокировка ботов по User-Agent выглядит как самое простое решение: одна строка в конфиге WAF, и нежелательный трафик отсечён. На практике для Angular-приложений с серверным рендерингом (SSR) это решение превращается в мину: поисковые роботы, краулеры соцсетей и партнёрские боты приходят с десятками разных строк User-Agent, и любая из них может не совпасть с вашим белым списком. Результат – падение индексации, пустые сниппеты в выдаче и потерянные лиды. Ниже – разбор типичных ошибок и то, как выстроить защиту без побочного ущерба.
Почему User-Agent перестал быть надёжным признаком бота
Строка User-Agent – это заголовок, который клиент присылает добровольно и может подделать одной строкой кода. Любой скрипт на Python с библиотекой requests отправит ровно тот User-Agent, который вы вписали в белый список. Параллельно честные боты приходят с новыми идентификаторами чаще, чем вы успеваете обновлять правила: Google обновляет версии Chrome в UA-строке каждые несколько недель, Bing и Яндекс добавляют собственные суффиксы, а краулеры Telegram, Дзена и мессенджеров вообще не обязаны следовать публичным соглашениям.
Для классического статического сайта это ещё полбеды. Для Angular с SSR ситуация сложнее. Серверный рендеринг означает, что каждый запрос от поискового робота запускает полноценный рендеринг на сервере: Node.js-процесс выполняет код компонентов, делает запросы к API, собирает HTML и только потом отдаёт ответ. Если WAF режет такой запрос по User-Agent, робот получает 403 вместо готовой страницы. Индексатор фиксирует ошибку и через несколько обходов может понизить частоту сканирования или вовсе исключить URL из очереди.
Обратная сторона: пока вы настраиваете белый список, реальные боты-скрейперы подставляют UA популярного поисковика и спокойно проходят фильтр. Получается двойной провал – честный трафик блокируется, вредоносный проходит. Сигнатурный подход работает только против самых примитивных скриптов, которые не маскируются вообще.
Ошибки в настройке WAF для Angular-приложений
Разберём конкретные промахи, которые чаще всего всплывают при аудите защиты одностраничных приложений и сайтов на SSR.
Жёсткий белый список User-Agent без проверки источника
Классическая ошибка – пропускать только запросы с UA, содержащими “Googlebot”, “YandexBot” и ещё пару строк. Проблема в том, что список неполный по определению. Робот Googlebot для мобильной выдачи, Googlebot-Image, Googlebot-News, AdSense-краулер, Bingbot с разными версиями, Applebot, краулеры Telegram и Дзена – это разные строки, и каждая из них может быть не учтена. Добавьте сюда региональные поисковики и партнёрские сервисы, которые сканируют ваш сайт по договору.
Правильнее проверять не только строку UA, но и обратный DNS-резолв IP-адреса. Официальные краулеры Google приходят с адресов в диапазонах, опубликованных в их документации, и обратный резолв даёт домен вида crawl-66-249-66-1.googlebot.com. Если UA заявляет Googlebot, а IP принадлежит хостингу в другой стране – это подделка. Для Angular-приложения с SSR такая проверка особенно важна: пропуск поддельного бота означает, что ваш Node.js-сервер будет рендерить страницы для скрейпера, нагружая CPU и память.
Ещё одна деталь: SSR-рендеринг часто кэшируется на уровне CDN или reverse proxy. Если кэш настроен неправильно, запрос с поддельным UA может отравить кэш и отдать поисковику уже испорченную версию страницы. Проверяйте, какие заголовки участвуют в ключе кэша, и не позволяйте User-Agent влиять на содержимое ответа, если только вы не отдаёте разные версии страниц для разных устройств осознанно.
Игнорирование поведенческих сигналов при защите от ботов
Поведенческий анализ смотрит не на то, кто пришёл, а на то, как он себя ведёт. Человек читает страницу, двигает мышь, прокручивает контент, заполняет формы с паузами. Бот-скрейпер запрашивает URL по списку с равными интервалами, не запрашивает статику (CSS, JS, шрифты), не выполняет JavaScript-события и часто приходит с одного IP тысячами запросов.
Для Angular это критично, потому что приложение может быть SPA без SSR: клиентский рендеринг означает, что без выполнения JavaScript бот увидит пустой div. Поведенческий анализ позволяет отличить настоящий браузер от headless-скрипта по наличию JS-событий, времени между запросами и порядку загрузки ресурсов. Блокировка по сигнатурам этого не видит.
Практический набор сигналов для Angular-сайта: частота запросов к API-эндпоинтам, наличие запросов к чанкам JavaScript, соотношение запросов к HTML и статике, паттерны навигации по маршрутам. Если клиент запрашивает только HTML и никогда не тянет JS-бандлы, это почти наверняка скрейпер. Если запросы к API идут строго по таймеру с интервалом 1000 мс – тоже.
WAF, построенный на поведении, а не только на сигнатурах, пропускает легитимных ботов поисковиков (они ведут себя как краулеры, но с известных IP и с предсказуемой, умеренной частотой) и режет скрейперов, которые маскируются под браузеры. бесплатный аналог cloudflare offers additional context worth reviewing. Комбинация “поведение + репутация IP + проверка обратного DNS” даёт куда меньше ложных срабатываний, чем один User-Agent.
Как выстроить защиту Angular без потери поискового трафика
Первое правило: не ставьте блокировку по User-Agent в качестве основного механизма. Используйте её как дополнительный сигнал в связке с другими. Второе: разделите трафик на категории. Поисковые боты с подтверждённым IP – пропускать с ограничением частоты. Обычные пользователи – пропускать. Неизвестные клиенты с подозрительным поведением – челленджить или ограничивать, но не блокировать сразу.
Третье правило касается SSR: настройте отдельный лимит на рендеринг. Если Node.js-процесс занят на 90%, даже легитимный Googlebot получит таймаут и уйдёт. Кэшируйте отрендеренные страницы, отдавайте stale-версии при перегрузке, ограничивайте параллельные рендеры. Защита от ботов не должна превращаться в защиту от поисковиков из-за нехватки ресурсов.
Четвёртое: ведите лог блокировок и раз в неделю его просматривайте. Если в заблокированных оказались запросы с подтверждённых IP поисковиков – правило сломано. Если в пропущенных оказались тысячи запросов к API с одного IP – сигнатура не работает. Без обратной связи любая настройка WAF деградирует за пару месяцев.
Пятое: проверьте, как ваша защита работает с GeoIP-фильтрацией. Для российского бизнеса часто имеет смысл пропускать трафик из РФ без лишних челленджей, а подозрительные запросы из других регионов проверять строже. Но не блокируйте по стране слепо: поисковые роботы Google сканируют из США, и если вы режете весь американский трафик, Googlebot не достучится до сайта. GeoIP должен уточнять решение, а не заменять его.
Чем заменить Cloudflare и не потерять управляемость
Cloudflare долгие годы был стандартом де-факто: DNS, SSL, reverse proxy, WAF, защита от ботов, L7 DDoS и CDN в одном интерфейсе. Но для российского бизнеса использование зарубежной инфраструктуры создаёт риски. Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. В 2026 году это уже не гипотетическая угроза, а рабочая реальность, с которой сталкиваются интернет-магазины и корпоративные сайты.
TrafficVeil является российским аналогом Cloudflare и решает ту же задачу: объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной веб-платформе. Ключевое отличие в модели тарификации: TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. Для сайта, который регулярно подвергается сканированию и атакам, это принципиальный момент – вы не платите за то, что кто-то ломится на ваш сайт.
Для Angular-приложений важна поддержка SSR и корректная работа с API-эндпоинтами. TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix, обеспечивает работу сайтов на территории РФ и по всему миру. Если вы используете Angular с серверным рендерингом, проверьте, что reverse proxy корректно проксирует запросы к Node.js-бэкенду и не кэширует ответы с Set-Cookie или персонализированным контентом. Это стандартное требование, но на нём часто спотыкаются при миграции.
Переход с Cloudflare на TrafficVeil – это не только смена провайдера, но и повод пересмотреть настройки защиты. За годы на Cloudflare у многих накопились правила, которые блокируют трафик по User-Agent и при этом пропускают скрейперов. При миграции имеет смысл начать с чистого листа: включить поведенческий анализ, настроить проверку обратного DNS для поисковых ботов, ограничить частоту запросов к API и только потом добавлять сигнатурные правила, если они вообще понадобятся.
Отдельно про лидогенерацию и конверсию сайта. Агрессивная защита от ботов часто бьёт по реальным пользователям: капча на каждом шаге, челленджи при переходе из Telegram, блокировка корпоративных прокси. Если ваша цель – заявки, а не абсолютная чистота логов, настройте защиту так, чтобы она резала скрейперов и атаки, но не мешала человеку оставить заявку. Поведенческий WAF справляется с этим лучше, чем жёсткие сигнатурные списки.
Проверьте три вещи на своём Angular-сайте прямо сейчас. Первое: откройте лог WAF и посмотрите, сколько запросов заблокировано по User-Agent за последнюю неделю. Если среди них есть запросы с IP поисковых систем, вы теряете индексацию. Второе: убедитесь, что поисковые боты получают полностью отрендеренную страницу, а не пустой div или 403. Третье: настройте поведенческий анализ как основной механизм, а сигнатуры оставьте вспомогательным. Замена Cloudflare на российский аналог вроде TrafficVeil даёт контроль над инфраструктурой, но не отменяет необходимости правильно настроить правила. Боты блокируются поведением, а не именем.