Коротко — есть много уровней защиты. Нельзя полностью «выключить» всех ботов без риска отсеять нормальных пользователей и поисковики, но можно сильно уменьшить вредные автоматические заходы с минимальным ущербом для UX и SEO. Ниже — практическое руководство с приемами, их плюсами/минусами и конкретными шагами.
1) Сначала — собрать данные и понять проблему
- Проанализируйте логи (nginx/apache), подключите access_log с форматом, где есть IP, UA, URL, referrer, время ответа, size.
- Выделите паттерны: одни и те же IP/ASN, много запросов с 0s/без JS, много запросов на статические файлы, бот‑сканеры по всем страницам и т. п.
- Проверьте, какие боты должны остаться: Googlebot, YandexBot и т.д. — их лучше явно вайтлистить (см. проверку через reverse DNS + ptr).
2) Быстрые и простые фильтры (минимум усилий)
- robots.txt — указывает «вежливым» краулерам, но многие боты его игнорируют.
- Блокировка по User‑Agent — легко реализуется, но UA легко подделать; полезно как первый шаг.
- Блокировка по IP/ASN — работает против большого числа вредителей; добавляйте в firewall (iptables/nftables) или .htaccess/nginx. Минус — динамические/прокси/большие пуллы IP, возможны ложные срабатывания.
3) Ограничение скорости и защита от сканирования
- nginx limit_req / limit_conn или аналог в приложениях: ограничивает количество запросов в секунду с одного IP. Очень эффективно для «скриптов‑бурстов». Пример:
- limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
- server { location / { limit_req zone=one burst=5 nodelay; } }
- fail2ban по логам — блокирует IP, которые слишком часто получают 4xx/5xx или делают много запросов.
4) Серверная проверка «живого» клиента — JavaScript challenge / interstitial
- Схема: если посетитель новый/подозрителен — показываете промежуточную страницу с простым JS, который ставит cookie/token и перенаправляет. Большинство ботов не выполняют JS и не пройдут. Это то, что вы видели («выбери картинку/цвет»).
- Пример: при отсутствии cookie отдаёте страницу с <script>document.cookie="bot=1;path=/";location.reload()</script>. Сервер дальше допускает только при наличии валидного cookie.
- Плюсы: минимум UX‑ущерба при хорошей реализации. Минусы: более продвинутые headless‑браузеры/боты выполняют JS, можно мешать SEO, если не вайтлистить поисковики правильно.
5) CAPTCHA / интерактивные проверки
- Применять для форм, регистрации, важных переходов или для подозрительных сессий. reCAPTCHA v3/hCaptcha или собственные простые тесты. Эффективно, но ухудшает UX, применять дозированно.
6) WAF / Bot Management / CDN
- Полноценные сервисы (Cloudflare, Sucuri, Imperva и т.п.) умеют отличать ботов по поведенческим моделям, fingerprinting, репутации IP, JS испытаниям и т. д. Минус — стоимость, latency, и в РФ действительно бывают проблемы с доставкой/latency у некоторых глобальных провайдеров.
- Альтернатива для РУ‑аудитории: используйте CDN/WAF с хорошим покрытием в РФ (Яндекс.Cloud CDN или локальные провайдеры), либо DDoS/GW провайдеров, которые имеют удобную доставку в РФ. Выбор зависит от бюджета и требований к приватности/законодательству.
7) Поведенческая фильтрация и fingerprinting
- Собирайте дополнительные сигналы: заголовки Accept, порядок заголовков, поддержка cookies, WebGL/fingerprints, время между кликами, глубина страниц. На их основе можно настраивать подозрительность и применять challenge только для сомнительных визитов. Это требует разработки, но даёт низкий уровень ложных срабатываний.
8) Honeypots и ловушки
- Публикуйте «скрытые» ссылки (hidden via CSS) или фальш‑эндпойнты. Боты их почищают — по IP/UA данных можно блокировать. Простая и эффективная тактика.
9) Блокировки по гео
- Если аудитория — только Россия, можно блокировать трафик/ограничивать доступ из других стран посредством GeoIP. Минус — пользователи через VPN/прокси или зарубежные CDN могут потерять доступ; будьте осторожны.
10) Черные/белые списки и репутации
- Источники: AbuseIPDB, Project Honey Pot, Spamhaus, коммерческие репутации. Можно автоматизировать импорт и блокировку.
11) Настройка аналитики и SEO‑учёт
- В Yandex.Metrika и Google Analytics включите/настройте фильтры и сегменты: отсекайте визиты с временем 0, переходы без JS‑событий, подозрительные реферы. В Метрике можно создать сегмент «Время на сайте > 0 OR Кол‑во просмотров >1» чтобы анализировать «живых» посетителей.
- Не блокируйте Google/Yandex по ошибке — whitelist их ботов, проверяя reverse DNS (например, googlebot.com / yandex.ru) и затем делая обратную проверку PTR → проверку имени → снова IP. По‑бавьте правило, позволяющее проверенным поисковикам доступ без challenge.
Практический чек‑лист (пошагово)
1. Анализ логов: собрать и сегментировать трафик, составить список подозрительных IP/UA/ASN.
2. Наложить простые фильтры: nginx limit_req + блокировка очевидных UA и IP.
3. Ввести JS‑challenge для новых/подозрительных сессий. Реализовать короткую interstitial page.
4. Подключить fail2ban/Firewall для автоматического блокирования повторяющихся злоупотребителей.
5. Для форм — CAPTCHA. Для массовых атак — рассмотреть WAF/CDN.
6. Настроить фильтры в Yandex.Metrika/GA, в ручном режиме очищать данные и отслеживать эффект.
7. Постоянный мониторинг и корректировки — боты меняются.
Пример простого JS‑challenge (схематично)
- Сервер: если нет cookie bot_ok → отдать простую страницу:
<html><body><script>
document.cookie="bot_ok=1;path=/;max-age=3600";
location.replace(location.pathname + location.search);
</script><noscript>Включите JS</noscript></body></html>
- Сервер дальше пропускает только при наличии cookie bot_ok. (Не забудьте вайтлистить поисковики и учитывать, что некоторые пользователи с отключённым JS будут блокированы.)
Замечания по SEO и безопасности
- Обязательно не препятствуйте доступу Google/Yandex. Используйте проверку reverse DNS для вайтлиста.
- Не блокируйте по‑умолчанию поисковых бот‑UA — проверяйте IP.
- Внедряя JS‑challenge, убедитесь, что поисковые боты проходят (если сомневаетесь, добавьте мета‑теги/каноникал и sitemap).
- Любые автоматические блокировки держите под контролем: логируйте и имейте механизм отката при ошибочных блоках.
Если хотите, могу:
- Посмотреть пример ваших логов (анонимизированных) и подсказать конкретные правила для nginx/fail2ban;
- Прислать готовую interstitial‑страницу и nginx‑правила для её применения;
- Подготовить список IP/ASN/UA, которые чаще всего встречаются в РФ, и скрипт для автоматической блокировки по порогу запросов.
Скажете, хотите начать с анализа логов или сразу с реализации JS‑challenge/limit_req?