Ми в ButikSEO Послуг спроєктували й впровадили «безболісну» для індексації пастку Honeypot анти-скрапінгу на сайті-оглядачі казино. Ключові вимоги клієнта:
- зменшити навантаження від парсерів;
- не чіпати verified-ботів (Googlebot, Bingbot, Applebot тощо);
- мати вимірюваний ефект без фальшивих спрацьовувань.
Результат: навантаження на сервер суттєво зменшилося, «погані» боти автоматично потрапляють у “корзину” і баняться, Googlebot не обмежується і в бан не потрапляє.
ТЗ і стартові умови (суть Honeypot)
- Сайт за Cloudflare (проксі увімкнено).
- Логи містять User-Agent, Referer і заголовки CF (CF-Connecting-IP, CF-Ray, CF-IPCountry).
- У футері кожної сторінки – невидимий лінк-пастка:
- У robots.txt – Disallow: /__trap.
- Початково в Cloudflare було: Skip для verified-ботів на /__trap; Managed Challenge для всіх інших на /__trap.
- Бекенд мав віддавати на /__trap 410 Gone + X-Robots-Tag: noindex, nofollow, і логувати CF-заголовки.
- На сервері – Apache (не Nginx).
Діагностика сайту (до змін)
В піковий проміжок (~2 год 48 хв) зафіксовано 39 524 запити від 293 IP. Основна частка навантаження – «веєр» з айпішниками (Google Cloud) з піками до ~1000 req/min на IP, плюс «важкий» IP (IONOS). Verified-ботів у трафіку ~0,14%, тобто саме маскувальні скрапери створювали навантаження.
Архітектура рішення пастки для ботів Ханіпот
1) Honeypot як датчик, а не «бар’єр»
Мета пастки – детектувати та атрибутувати скраперів, а санкції застосовувати вже для всього сайту. Ми підняли окремий лог для /__trap із CF-атрибутами.
Відповідь бекенда – 410 Gone + X-Robots-Tag: noindex, nofollow (чіткий пер-URL сигнал «ресурс видалений назавжди»).
2) Cloudflare (edge)
Під час відладки 410 перекривався челленджем (403). Тому ми підняли Skip на /__trap вище за всі правила, щоб запит доходив до origin і логувався.
Фінальна логіка бот-ловушки Honeypot:
Verified-боти:
(http.request.uri.path eq “/__trap” and cf.client.bot) → Skip (WAF/RL/SBFM/Security Level).
Усі інші на /__trap:
(http.request.uri.path eq “/__trap”) → Skip (ті самі компоненти).
У всіх інших правилах WAF/Rate Limiting додано виняток:
and http.request.uri.path ne “/__trap” – щоб пастка залишалась чистим датчиком.
Паралельно для реального трафіку:
Загальний rate-limit: 300 req/60s/IP (без урахування статики). Для хмарних ASN (GCP 15169, IONOS 8560): 120 req/60s/IP.
Дія: Managed Challenge.
Verified-боти і тут виключені (cf.client.bot).
3) Apache (origin)
Увімкнули mod_remoteip і довіру до IP-пулів Cloudflare (список підмереж) → у логах бачимо реальний IP клієнта з CF-Connecting-IP. Налаштували окремий формат логів для /__trap: IP, CF-Ray, UA, країна, позначка honeypot. Відповідь на /__trap: 410 Gone + X-Robots-Tag.
Також виправили використання RemoteIPTrustedProxy (краще за InternalProxy для публічних підмереж CF).
4) Автоматичні санкції
Усі хіти на /__trap йдуть у “корзину” кандидатів.
Далі автоматично:
- або fail2ban читає лог /__trap → додає Block у Cloudflare API (edge-бан на весь сайт) на 1–24 год;
- або автоматика за Cloudflare Firewall Events/Logpush робить те саме.
Googlebot/Verified-боти завжди виключені (через cf.client.bot і фільтри на стороні сервера).
Чому саме 410 Gone на прихованій пастці Honeypot?
Це правильна семантика для конкретного URL: «ресурс видалено назавжди» → чемні краулери перестають його перевіряти й не засмічують crawl-статистику.
На відміну від 403 (доступ заборонено) і 404 (може з’явитись пізніше), 410 – передбачуваний «тупик» саме для /__trap. Водночас санкція по всьому сайту вмикається нашою автоматикою – код відповіді лише маркер, а не інструмент блокування.
Тест-план і валідація
У DOM кожної сторінки присутній невидимий лінк /__trap. У Cloudflare Skip-правило на /__trap стоїть вище за всі інші; verified-боти завжди Skip.
curl -I https://site.com/__trap → 410 + X-Robots-Tag; в Events – Action: skip.
У логах Apache для /__trap видно CF-Ray, CF-Connecting-IP, UA. У GSC через 48–72 год – без росту crawl-errors, нормальна динаміка Crawl Stats.
За метриками – спад піків req/min і CPU; у «чорних списках» домінують GCP/IONOS та інші проксі-ASN; verified-боти не зачіпаються.
Що дало бізнесу
- Зниження навантаження на origin без шкоди для індексації.
- Керована безпека: маскувальні боти детектуються пасткою і автоматично блокуються на весь сайт.
- Прозора вимірюваність: у логах є все для доказів і коригування правил; CF-Events – для швидкого розслідування.
Чек-лист для тиражування
- Пастка у футері (off-screen, без подій аналітики).
- robots.txt: Disallow /__trap.
- У Cloudflare: Skip на /__trap (і окремий Skip для cf.client.bot), у решті правил – виняток ne “/__trap”.
- На сервері: /__trap → 410 Gone + X-Robots-Tag; окремий лог із CF-Connecting-IP та CF-Ray.
- Rate-limit: 300/60s/IP (база), 120/60s/IP для хмарних ASN; статику не рахувати.
- Автобан: fail2ban → Cloudflare API (або автоматика по CF Events).
- Моніторинг: CF Events, серверні логи, GSC; регулярний перегляд порогів/білих списків.
Висновок
Методика ButikSEO Послуг поєднує honeypot як датчик + санкції на краю (через Cloudflare) і м’які ліміти для всіх інших запитів. Це дозволяє реально зменшити скрапінг і навантаження, при цьому жодним чином не обмежуючи Googlebot/Bingbot та інші verified-краулери.