Історія про те, як маркетолог без прав адміністратора побудував автоматичний моніторинг ботів, який щодня аналізує сотні тисяч запитів, пише готові інструкції для адмінів і сам перевіряє, чи подіяли зміни.
Хто ми і чому нам це болить
Платформа Barb.ua — український маркетплейс б’юті-послуг: тисячі анкет майстрів і салонів, лістинги послуг по містах, блог, медичний та освітній розділи. Для платформи такого типу трафік — це все: люди шукають майстра манікюру в Ужгороді чи салон у Вінниці, порівнюють, записуються.
Моя роль на платформі — маркетинг, SEO і з недавніх пір AI-видимість. Я не адміністратор і не пишу конфіги руками. Це важлива деталь сюжету: рішення, про яке піде мова, будувала людина, яка бачить проблему з боку бізнесу й аналітики, а не з боку серверної консолі.
А проблема ось у чому. У 2026 році трафік сайту — це вже давно не лише люди й Googlebot. До нас щодня приходять AI-краулери — GPTBot, ClaudeBot, PerplexityBot, боти Meta й Apple — і це повноцінний канал видимості: коли користувач питає ChatGPT «де зробити нарощування вій в Одесі», відповідь може містити посилання на Barb.ua. Реальний трафік із AI-асистентів у нас уже вимірюється тисячами візитів на тиждень і зростає. Водночас поруч із корисними ботами ходять парсери, сканери вразливостей і розподілені ботнети — і зовні вони інколи майже не відрізняються. Заблокуєш зайве — втратиш канал. Пропустиш зайве — отримаєш навантаження на сервер і зіпсовану аналітику.
Проблема: моніторинг був, але «на людях»
Парсери турбували нас завжди. Захист від парсингу контактів анкет у нас стоїть давно і працює — тому головним болем були не витоки даних, а дві інші речі:
- Сплески «лівого» direct-трафіку в Google Analytics з жахливими поведінковими показниками — bounce під 100%, нульова тривалість сесії. Такі сплески спотворюють усю аналітику: реальні метрики сайту тонуть у смітті.
- Навантаження на сервер. Агресивний скрапер, який за добу робить десятки тисяч запитів, — це цілком відчутні витрати ресурсів.
Система реагування в нас існувала близько чотирьох років і постійно вдосконалювалася: Telegram-сповіщення про підозрілу активність → адміністратор вручну дивиться логи й аналітику → вносить зміни у WAF-правила Cloudflare. Схема чесно працювала, але мала три системні болі:
- Не завжди встигали вчасно. Сповіщення прилітали вночі або у вихідний, аналіз відбувався тоді, коли в адміна доходили руки. Ботнет за цей час встигав зробити своє.
- Адміни розходилися в оцінках. Один вважав, що агента треба блокувати, інший — що це може бути щось корисне і краще почекати. За фінальним рішенням ішли до мене. А я, нагадаю, не адмін — і опинялася в ролі арбітра в суперечці, для якої мені бракувало технічного контексту.
- Кілька разів помилково блокували корисних ботів. Включно з AI-краулерами — а це прямий удар по каналу видимості, який ми самі ж розвиваємо.
Висновок, до якого ми прийшли: проблема була не в інструментах. Cloudflare чудово ловить і логує. Проблема була у вузькому місці — експертному аналізі, який треба робити щодня, швидко і з однаковою якістю. Саме цю ланку ми й вирішили автоматизувати.
Telegram-канал, до речі, живий і досі — але тепер це просто додатковий канал сповіщення, а не тригер ручної роботи.
Рішення: Claude як щоденний аналітик бот-трафіку
Архітектура вийшла така:
Claude (планові задачі) → Cloudflare GraphQL Analytics (read-only) → Google Analytics через власний конектор → звіти у Slack.
Claude запускається за розкладом кілька разів на день, через MCP-конектор читає аналітику firewall-подій і HTTP-запитів Cloudflare, аналізує період від попереднього запуску, веде журнал і надсилає звіт у робочий Slack-канал. Раз на тиждень окремі задачі роблять зріз AI-видимості й реального трафіку з AI-асистентів.
Кастомний конектор через Cloudflare Worker
З Cloudflare все було просто — офіційний MCP-конектор до GraphQL-аналітики існує з коробки. А от готового конектора до Google Analytics під наші потреби не знайшлося. Тому ми зробили власний — невеликий Cloudflare Worker, який виступає MCP-сервером: приймає запити від Claude, ходить у Google Analytics Data API від імені сервісного акаунта і повертає дані у зрозумілому форматі.
Чому саме Worker? Це виявився найкоротший шлях «подружити» Claude з API Google: не треба піднімати й обслуговувати окремий сервер, деплой — одна команда, авторизація сервісного акаунта живе в секретах воркера, а сам конектор доступний за HTTPS-адресою, яку просто додаєш у налаштування Claude. Кілька десятків рядків коду — і Claude бачить наші GA4-звіти так само природно, як дані Cloudflare.
Логіка, закладена в промпт
Найцінніше в цій системі — не «підключили ШІ», а дисципліна, зашита в інструкції. Промпт щоденного аудиту пройшов кілька версій, і ось його ключові принципи:
Read-only + людина в контурі. Claude нічого не змінює в Cloudflare. Взагалі нічого. Він аналізує і формує рекомендації; зміни вносить адміністратор руками. Це не тимчасова милиця «поки не довіряємо», а свідомий дизайн: ціна помилкового блокування зависока.
Журнал як пам’ять. Кожен запуск дописує запис у markdown-журнал, а наступний запуск починає з його читання. Так система «пам’ятає» акторів між запусками: знає, що конкретний скрапер не з’являвся вже 24 запуски поспіль, що частка обходу челенджів у певної мережі зросла з 13% до 18%, що рекомендація тижневої давнини була впроваджена і подіяла. Часова мітка останнього запису слугує курсором — початком наступного вікна аналізу.
Інвентаризація правил на старті кожного запуску. Перший крок будь-якого аудиту — переписати всі активні WAF-правила за подіями спрацювань: скільки їх, які дії, які обсяги. На нашому тарифі є ліміт кількості кастомних правил. Тому діє принцип економії: дописувати умову в наявне правило, а не створювати нове. Claude сам обирає правило-приймач за збігом дії та близькістю змісту.
Жорсткий список недоторканних. У промпті — явний перелік ботів, яких ніколи не можна рекомендувати блокувати: пошукові системи, AI-краулери, боти прев’ю посилань для месенджерів і соцмереж. Окремо — механізм перевірки на фейків: якщо агент видає себе за відомого бота, але приходить не з інфраструктури власника — це самозванець, і його якраз можна блокувати.
Крос-перевірка помилок. Один із найважливіших уроків: код відповіді 403 сам по собі не означає «Cloudflare заблокував». Це може бути відповідь самого сервера — наприклад, на спробу зайти в приватний розділ. Тому кожен 403 у корисного бота звіряється з firewall-подіями: блокуванням вважається лише той, за яким стоїть реальна подія challenge або block. Без цієї перевірки система панікувала б на рівному місці.
Формат рекомендацій. Кожна рекомендація — це готова до виконання інструкція фіксованого формату: що робити, в яке правило, повний фінальний вираз для копіювання, яка дія, де правило має стояти відносно інших, і — обов’язково — як наступний запуск перевірить, що зміна подіяла. Рекомендації поділені за терміновістю: «потребує дії зараз» / «опційно, на розсуд» / «спостерігаємо». Адмін за п’ять секунд розуміє, що треба зробити сьогодні, а що — просто до відома.
Верифікаційна петля. Це, мабуть, найкрасивіша частина. Рекомендація → впровадження людиною → наступний запуск сам перевіряє за подіями, чи актор тепер перехоплюється, і чесно пише в звіт: «правило тримає, витоку немає» або «рекомендація не подіяла, ось ймовірна причина». Цикл замикається без жодної ручної перевірки.
Процес налаштування
Технічно все живе в проєкті Claude: файли з промптами задач, інструкції проєкту з контекстом інфраструктури, журнали. Планувальник запускає щоденний аудит двічі на день і дві тижневі задачі — зріз AI-цитувань і звіт про реальний LLM-трафік. Кожна задача пише у свій журнал і у свій Slack-канал: технічний моніторинг — в один, звіти про AI-трафік — в інший, який читають колеги з маркетингу.
З чим зіштовхнулися і як лікували
Було б нечесно вдавати, що все запрацювало з першої спроби. Ось реальні граблі.
Нечіткі рекомендації на старті. Перші версії видавали щось на кшталт «рекомендую заблокувати цього бота». Без виразу, без дії, без розміщення. Адмінам доводилося додумувати — і ми поверталися до тієї самої проблеми розбіжних інтерпретацій, з якої починали. Лікувалося ітераціями промпта: тепер формат інструкції жорстко зафіксований, і рекомендація без повного виразу для copy-paste просто не вважається рекомендацією.
Аналітика ≠ конфігурація. GraphQL-API Cloudflare віддає лише події спрацювань — але не текст самих правил. На початку Claude реконструював вирази правил за тим, кого вони ловлять, і подавав це як факт. Одного разу реконструйований вираз розійшовся з реальним — і якби адмін дописував умову «наосліп», правило могло б зламатися. З того часу залізна норма: будь-яке твердження про зміст правила позначається як припущення, а перед редагуванням адмін обов’язково звіряє реальний вираз у дашборді.
Невидимі розподілені мережі. Найпідступніша знахідка. Ботнет на резидентних IP-адресах «розсипається» по десятках країн і провайдерів — і коли аналітика групує трафік одночасно за агентом, мережею і країною, кожен шматочок окремо виглядає мізерним і не потрапляє в топи. Одна така мережа — близько 78 тисяч запитів на добу під виглядом звичайного браузера — довго лишалася непоміченою саме через це. Рішення: окремий запит з агрегацією лише за user-agent, без розбивки за географією. У такому розрізі мережа зібралася в одну велику цифру — і була заблокована. Тепер цей запит — обов’язковий крок кожного аудиту, разом із трьома евристиками розпізнавання: застаріла версія браузера, аномальна частка обходу челенджів, нетипова для нашої аудиторії географія.
Зависання планових задач. Інфраструктурна проблема, яка коштувала нам нервів: сесії планових задач інколи «залипали» в циклі й не завершувалися. З’ясували дві речі. Перша — паралельні запити до MCP-конектора провокували помилки з’єднання і перезапуски агента, тому в промпті тепер жорстка вимога строго послідовного виконання запитів. Друга — частину проблем зняла зміна моделі й режиму підтвердження дій, а решту ми ескалювали в підтримку платформи. Важливий нюанс, який ми зрозуміли дорогою: поставити задачу на паузу і зупинити вже запущену сесію — це дві різні дії.
Ліміти безкоштовної аналітики. На нашому тарифі Cloudflare дані аналітики живуть кілька діб, а одне вікно запиту обмежене добою. Тижневу історію з API просто не дістати. Саме тому журнал перетворився з «приємного бонуса» на критичний компонент: це єдине місце, де накопичується довга історія.
Бонус-знахідка, яка окупила все. Нещодавно система впіймала легітимного AI-пошукового бота великого вендора, який через нестандартний формат user-agent потрапляв під наше challenge-правило для аномальних агентів — і не отримував контент. Людина в потоці щоденних логів цього б не помітила: бот новий, обсяг на фоні загального трафіку скромний. Claude помітив, крос-перевірив походження (справжня інфраструктура вендора, не фейк), і видав готову інструкцію для розблокування. Тобто система захищає не лише нас від ботів, а й корисних ботів від нас самих — а це прямий захист каналу AI-видимості.
Що отримали в цифрах
Кілька фактів із реальних звітів останніх тижнів:
- Щоденні звіти без участі людини. «Чистий» день — один рядок у Slack: «підозрілої активності немає». Проблемний день — повний звіт із готовим планом дій.
- Фейковий «Googlebot» — до 85 тисяч запитів на добу, 100% заблоковано. Мережа, що прикидається пошуковиком Google, але приходить зовсім не з його інфраструктури, стабільно б’ється об блокувальне правило: жодного запиту повз, і система перевіряє це кожен запуск.
- Розподілена резидентна мережа — близько 28 тисяч запитів на добу, 100% перехоплення тим самим правилом, яке колись з’явилося завдяки агрегації за user-agent.
- Корисні боти — 0% блокувань, і це не разова перевірка, а метрика кожного запуску з крос-перевіркою кодів відповіді проти firewall-подій.
- Один надоїдливий зниклий скрапер система відстежує вже 24 запуски поспіль — якщо повернеться, ми дізнаємось того ж дня.
- Суперечки адмінів зникли. Тепер є єдиний аргументований аналіз із цифрами, і питання «блокувати чи ні» більше не вирішується голосуванням у чаті.
- Побічний ефект: паралельний моніторинг показує, що реальний трафік із AI-асистентів виріс до ~1,6–1,7% усіх відвідувачів сайту і заходить переважно на анкети майстрів, салонів і лістинги послуг — що прямо визначило наші пріоритети в роботі зі структурованими даними.
Висновки й поради тим, хто захоче повторити
І останнє. У цій статті свідомо немає виразів правил, ідентифікаторів, конкретних сигнатур, порогів спрацювання і деталей нашої мережевої конфігурації. Ми розповіли як побудована система — але не що саме вона перевіряє. Читачі, які будують власний захист, зрозуміють чому.
Питання про досвід чи технічні деталі архітектури — пишіть, радо поділимося тим, чим можемо.
Джерело: www.ukrinform.ua