У звітах GA4 сайту webscraft.org почали приходити сеанси з країни, де у мене майже немає читачів. частка такого трафіку — було 26%. Сеанси були короткими й дуже схожими один на одного, а GA4 вважав їх звичайними відвідувачами. Я перевірив журнал Cloudflare, і картина стала зрозумілішою. У цій статті — як боти з headless-браузерами потрапляють у GA4, за якими ознаками їх помітити і як відфільтрувати, нічого не зламавши.
⚡ Коротко: чому GA4 не бачить частину ботів
- ✅ GA4 відсікає лише відомих ботів. За довідкою Google, трафік відомих ботів і павуків виключається автоматично на основі власних досліджень Google та списку IAB. Вимкнути цей фільтр і побачити, скільки даних він відсік, не можна.
- ✅ Бот без JavaScript у GA4 не потрапляє, бот із браузером — потрапляє. Headless-браузер виконує тег, тому GA4 бачить звичайний сеанс.
- ⚠️ GA4 показує симптом, а причину видно в Cloudflare: країну мережі, ASN і кількість запитів.
- ⚠️ Фільтри даних GA4 працюють тільки вперед і не вміють відсікати країни чи ботів за поведінкою. Блокувати треба на рівні Cloudflare, обережно.
Скільки ботів у мережі загалом, залежить від методики. За звітом Imperva 2026, боти становлять понад 53% веб-трафіку, а 40% трафіку класифіковано як шкідливі боти (торік Imperva називала 51% і 37%, це дані за 2024 рік). Cloudflare рахує інакше: у червні 2026 за Cloudflare Radar боти генерували близько 56% запитів, причому ці цифри описують HTTP-запити, а не людей чи увагу. У вибірках Radar за всіма запитами (огляд Technology Checker) частка ботів помітно менша, близько 35%. Imperva є вендором захисту від ботів, тож її цифри краще читати як галузевий орієнтир. Ширше про масштаб проблеми — у моїй статті «Інтернет уже на 50% складається з ботів».
📚 Зміст статті
🧠 Як GA4 вирішує, що це людина, і що таке headless-браузер
GA4 збирає дані через JavaScript-тег на сторінці. Якщо код не виконався, подія не відправилась і відвідування у звіті немає. Тому прості скрипти, які лише завантажують HTML, GA4 не бачить.
Єдиний вбудований захист — список відомих ботів: Google використовує власні дослідження та список International Spiders and Bots List від IAB. Це перелік ботів, які чесно себе називають, тому він добре відсікає легальні краулери і слабко допомагає проти тих, хто не хоче бути впізнаним. В одному з практичних розборів це формулюють так: вбудована фільтрація прибирає лише відомих краулерів і не ловить скрапінг через headless-браузер.
Що таке headless-браузер
Це звичайний Chrome без вікна. Документація Chrome описує headless-режим як запуск браузера в автоматичному середовищі без видимого інтерфейсу; ним керують через Puppeteer, Playwright чи Selenium. Причини використання бувають різними:
- Легітимні: автоматичні тести, моніторинг доступності, SEO-краулери, збір публічних даних.
- Небажані: накрутка трафіку, скрапінг контенту, маніпуляції з рекламою.
Головне для аналітики: такий браузер виконує JavaScript, а отже, виконує й тег GA4, і відвідування з'являється у звітах. Просунуті боти вміють маскуватися під звичайних користувачів. Як саме, я описувати не буду: це інструкція для шахраїв, а не захист. Практичний висновок простий: не покладайтеся на один інструмент, поєднуйте GA4, Cloudflare і дані вашої рекламної платформи.
👻 Ghost-спам: боти, які навіть не відвідують сайт
Ghost-спам не відкриває ваші сторінки. Події надсилаються напряму на сервери аналітики через Measurement Protocol, і у звітах з'являються дивні джерела та події, яких на сайті немає. Це класична проблема Universal Analytics.
У GA4 зловмиснику складніше: для Measurement Protocol потрібен окремо створений API secret (Адміністратор → Потоки даних → Measurement Protocol), а офіційні приклади Google вимагають і measurement_id, і api_secret. Тому масового ghost-спаму, як за часів UA, очікувати не варто. Проте деякі автори описують такі хіти й у GA4. Якщо ви бачите події, яких немає у вашому коді, перевірте, чи міг api_secret потрапити у відкритий код, і за потреби створіть новий. Це моє припущення, а не підтверджена причина.
🔎 Як я визначаю ознаки ботів у GA4
Коли я аналізую трафік у GA4, то не роблю висновків на основі одного показника. Окрема аномалія ще не означає, що сайт відвідують боти. Я звертаю увагу на сукупність ознак:
- країни або міста з великою кількістю сеансів, але дуже низькою залученістю;
- сеанси тривалістю 0–1 секунду лише з одним переглядом сторінки;
- раптове зростання частки каналу Direct без очевидної причини;
- нетипові роздільні здатності екрана або мови браузера;
- значення
(not set) у звітах про цільові сторінки;
- сотні сеансів із майже ідентичною поведінкою: однаковим шляхом користувача та схожою тривалістю.
Щоб визначити, з чого почати перевірку, можна скористатися практичним гайдом з аналізу підозрілих сплесків трафіку в GA4. У ньому розглядаються, зокрема, середній час залучення, частка користувачів, що повертаються, і частка сеансів із каналу Direct. Я розглядав би ці метрики як початкові орієнтири, а не як самостійний спосіб виявлення ботів.
Водночас я враховую і зворотний ризик: реальні користувачі також можуть виглядати підозріло. Наприклад, людина може використовувати VPN, заходити через мобільну мережу або закрити сторінку за секунду. Тому я не вважаю аномалії в GA4 доказом бот-трафіку — це лише сигнал для подальшої перевірки джерел трафіку, поведінки відвідувачів і серверних логів.
🛡️ Як підтвердити підозру в Cloudflare
GA4 не показує IP-адреси і мережі (ASN), тому причину шукають там, де вони є. Що перевірити:
- Журнал подій безпеки (Security Events). За документацією Cloudflare, на безкоштовному та Pro-тарифах доступні базові метрики через Security Events, а Bot Analytics вимагає тарифу Business і вище.
- Країни та ASN. Якщо підозрілі запити йдуть із мереж дата-центрів, це сильний аргумент на користь автоматичного трафіку. Цей висновок випливає з логіки мережі, а не з документації, тому перевіряйте на своїх даних.
- Провалені перевірки браузера (challenge).
- Запити без трафіку в GA4. Порівняйте кількість запитів у Cloudflare із сеансами GA4. Якщо запитів значно більше, ймовірно, частина ботів не виконує JavaScript і до GA4 просто не доходить.
| Можливість |
GA4 |
Cloudflare |
| Бачить ботів без JavaScript |
Ні |
Так (як запити) |
| Показує IP / ASN |
Ні |
Так |
| Показує поведінку на сайті |
Так |
Ні |
| Може заблокувати трафік |
Ні |
Так |
Застереження про країни
Висока частка автоматичного трафіку з окремої країни не означає, що там живуть ботоводи. Коментуючи регіональну розбивку Cloudflare Radar, TechSpot зазначає, що у Сінгапурі та Ірані боти становлять понад три чверті запитів, але це радше відображення хостинг-інфраструктури, маршрутизації, VPN та інших чинників. Тому перш ніж щось блокувати, перевіряйте ASN, а не лише країну.
🧪 Мій кейс: Сінгапур і журнал Cloudflare
Мій блог має чотири мовні версії: українську, англійську, німецьку та іспанську. Англійською у Сінгапурі читають, тож реальні відвідувачі звідти цілком можливі. Проте в GA4 ця країна стабільно потрапляє в лідери за користувачами, а їхня поведінка відрізняється від решти. Нижче два періоди зі звіту «Демографічні дані → Країна»: літо 2026 року, коли були найсильніші сплески, і останні 28 днів.
Що я побачив у GA4: липень–серпень 2026
| Країна |
Активні користувачі |
Рівень залученості |
Середній час залучення на користувача |
| Сінгапур |
6 712 (30,16%) |
40,08% |
9 с |
| Україна |
2 622 (11,78%) |
82,32% |
1 хв 21 с |
| США |
2 412 (10,84%) |
62,43% |
1 хв 14 с |
| Німеччина |
1 646 (7,4%) |
84,17% |
1 хв 13 с |
| (not set) |
1 601 (7,2%) |
1,12% |
0 с |
| Китай |
1 262 (5,67%) |
72,19% |
28 с |
| Весь сайт |
22 251 |
61,86% |
43 с |
Що видно за цей період:
- Сінгапур на першому місці з великим відривом. Близько 30% усіх активних користувачів сайту за два місяці, у 2,5 раза більше
- Трафік приходить хвилями. У звичайні дні зі Сінгапуру десятки користувачів, а потім різкі сплески: кілька піків приблизно по 400–500 користувачів на добу наприкінці липня і на початку серпня, і максимум 14 серпня.
- Пік 14 серпня: 932 активні користувачі зі Сінгапуру за добу, при 1 142 по всьому сайту. Це понад 80% усієї аудиторії того дня.
- Майже всі користувачі нові: 6 660 нових із 6 712 активних.
- Короткий час на сайті: 9 секунд проти 1 хвилини 11 секунд .
Такі різкі сплески, як мені здається, радше нагадують автоматичні запуски, ніж органічне читання. Але це лише ознака, а не доказ.
Що я бачу зараз: останні 28 днів (18 вересня — 15 жовтня 2026)
| Країна |
Активні користувачі |
Рівень залученості |
Середній час залучення на користувача |
| Сінгапур |
1 697 (25,93%) |
19,19% |
5 с |
| Україна |
1 090 (16,65%) |
80,94% |
2 хв 11 с |
| Німеччина |
669 (10,22%) |
81,62% |
1 хв 11 с с |
| США |
646 (9,87%) |
59,04% |
1 хв 15с |
| Китай |
340 (5,19%) |
27,09% |
35 с |
| (not set) |
249 (3,8%) |
2,42% |
0 с |
| Весь сайт |
6 545 |
59,62% |
42 с |
Картина схожа, але спокійніша: Сінгапур усе ще перший (25,93% користувачів, приблизно чверть аудиторії), залученість лише 19,19% проти 80,94% в Україні, час 5 секунд, і кількість нових користувачів збігається з кількістю активних (по 1 697). Схожий профіль у Китаю(27,09%, 5 секунд) і в записів без країни (2,42%, 0 секунд).
Чому я не стверджую, що це лише боти
Улітку рівень залученості зі Сінгапуру був 40,08%, тобто вищий, ніж зараз (19,19%), а GA4 визнав залученими 2 693 сеанси. Отже, частина цього трафіку могла бути реальними читачами, наприклад англомовними чи тими, хто користується VPN, або ботами, які затрималися на сторінці. Самі показники GA4 цього не розрізняють, тому я вважаю картину підозрою, а не доказом.
Моя гіпотеза і її межі
Гіпотеза: значна частина «живих» сеансів із цієї країни приходить із мереж хмарних дата-центрів, тобто це headless-браузери. Її підтримує те, що Сінгапур, за даними Cloudflare Radar, входить до країн із дуже високою часткою автоматичного трафіку. Але це кореляція, а не доказ: Я також не можу виключити, що частина цього трафіку — справжні люди через VPN чи корпоративні мережі, тому країну повністю не блокував.
🧰 Як відфільтрувати ботів у GA4 (і чого фільтри не вміють)
Очікування тут часто завищені, тож почнімо з обмежень:
- Фільтри даних GA4 — лише двох типів: внутрішній трафік і трафік розробників. Виключити країну чи «ботів за поведінкою» ними не можна.
- Внутрішній трафік визначають за IP-адресою. Теоретично це можна використати для конкретних IP, але боти часто змінюють адреси, а помилкове правило зачепить реальних людей, тож я б не покладався на цей спосіб.
- Фільтри працюють лише вперед. Як зазначають практики, вони застосовуються від моменту створення і не змінюють історичні дані. Також нагадують, що дані, зібрані під час тестового режиму фільтра, ретроактивно не обробляються.
Що робити практично
- Аналіз у Explorations. Створіть вільну форму (Free form) із вимірами «Країна» і «Мережа/джерело», метриками «Сеанси», «Рівень залученості», «Середній час залучення». Так видно, де «живий» трафік, а де ні.
- Порівняння «до і після». Зробіть знімок показників до змін у Cloudflare і порівняйте через 1–2 тижні. Інакше ви не відрізните ефект блокування від звичайних коливань.
- Сегменти без підозрілих країн для звітів — як тимчасовий інструмент аналізу, а не як «очищення» даних.
Висновок: щоб ботів справді прибрати, а не лише приховати у звітах, потрібен захист на рівні Cloudflare.
🧱 Як блокувати ботів у Cloudflare і чого не робити
Назви функцій і тарифні обмеження Cloudflare змінюються, тож перед налаштуванням звіряйтеся з актуальною документацією.
Чому для цього не достатньо robots.txt
Перше, що спадає на думку, — заборонити підозрілих ботів у robots.txt. Але цей файл лише просить боти не заходити в певні розділи, і слухаються його тільки ті, хто сам хоче. Стандарт RFC 9309 прямо зазначає, що ці правила не є формою авторизації доступу. Боти з headless-браузерами, які імітують людей, його ігнорують, тому на них це не діє. Для чесних краулерів і керування бюджетом сканування файл корисний (я розбирав це в статті «Robots.txt: повний гайд для SEO»), а проти ботів, які вам заважають, потрібні правила на рівні Cloudflare.
| Інструмент |
Що робить |
Тариф |
| Bot Fight Mode |
Розпізнає трафік за шаблонами відомих ботів і видає обчислювальний виклик |
Free |
| Super Bot Fight Mode |
Додає білий список перевірених ботів, дії за категоріями, захист статичних ресурсів, JavaScript-детекції |
Pro, Business, Enterprise |
| Managed Challenge (правило WAF) |
Cloudflare сам вирішує, чи показувати перевірку, залежно від ризику |
Усі тарифи |
| Rate limiting |
Обмежує кількість запитів з однієї адреси за період |
Залежить від тарифу |
Як діяти по кроках
- Спочатку виняток для перевірених ботів. Cloudflare прямо радить не блокувати й не «челенджити» verified bots (Googlebot, Bingbot, сервіси моніторингу).
- Починайте з Managed Challenge, а не з блокування, і спочатку для вузької умови (підозрілі ASN, а не вся країна). Так ви побачите наслідки і зможете відкотити правило.
- Стежте за Security Events. Подивіться, скільки запитів «челенджиться» і чи не зникають звичайні відвідувачі.
- Звертайте увагу на тариф Free. За описом практиків, Bot Fight Mode на Free працює як перемикач без винятків, а гнучкіші налаштування доступні в Super Bot Fight Mode.
- Перевірте рекламу після змін. Деякі автори попереджають, що Bot Fight Mode може заважати ботам верифікації реклами. Це думка однієї публікації, тож зверніться до підтримки вашої рекламної мережі, якщо після змін бачите зниження показів.
⚠️ Чого я не рекомендую робити
Коли я працюю з проблемою підозрілого трафіку, я не раджу поспішати з блокуваннями. Неправильні правила можуть обмежити доступ реальним користувачам або створити проблеми з індексацією сайту.
- Не рекомендую блокувати Googlebot та інших перевірених пошукових краулерів. Такі обмеження можуть завадити скануванню сторінок і негативно вплинути на індексацію. Перед блокуванням підозрілого User-Agent варто перевірити, кому він справді належить.
- Не рекомендую блокувати цілу країну без попереднього аналізу. Висока частка підозрілих сеансів із певного регіону ще не означає, що весь трафік звідти є ботами. Причиною можуть бути VPN, хмарна інфраструктура або автоматизовані запити. Водночас ви ризикуєте втратити справжніх читачів, зокрема тих, хто використовує VPN або перебуває за кордоном. Наприклад, у розділі вище про Сінгапур я розглядаю, чому географія трафіку сама по собі не є достатньою підставою для блокування.
- Не рекомендую відмовлятися від GA4 лише через бот-трафік. Аналітика допомагає виявляти аномалії та оцінювати зміни в поведінці відвідувачів. Замість відмови від неї варто перевірити джерела трафіку, налаштування збору даних і можливості фільтрації. Водночас потрібно враховувати, що GA4 не виявляє та не відфільтровує автоматично весь бот-трафік.
- Не рекомендую змінювати кілька правил блокування одночасно. Якщо одночасно змінити правила Cloudflare, серверні фільтри та інші налаштування, буде складніше визначити, яке саме втручання дало результат. Я б радив змінювати правила поступово, перевіряти серверні логи й порівнювати показники до та після кожної зміни.
💸 Чому це важливо для реклами
Для видавця боти — це не лише «брудна» статистика. По-перше, вони спотворюють сеанси і метрики на кшталт RPM: чим більше порожніх сеансів, тим нижчим виглядає дохід на сеанс. По-друге, є ризик для самої реклами. За правилами Google AdSense, недійсним вважається трафік, що штучно завищує витрати рекламодавця або дохід видавця, зокрема створений автоматичними інструментами та роботами. За високого рівня такого трафіку Google може призупинити або закрити акаунт, а за неможливості перевірити якість трафіку — обмежити показ реклами. Також може виникнути різниця між попередніми й остаточними доходами. Окремо Google нагадує, що відповідальність за валідність трафіку лежить на видавцеві, навіть якщо його генерує третя сторона.
Практична порада: порівнюйте сеанси в GA4 із даними у вашому рекламному кабінеті (у мене це Mediavine). Розбіжність сама по собі нічого не доводить, бо платформи рахують трафік по-різному, але різке розходження разом з іншими ознаками з розділу вище — привід для перевірки.
Про масштаби накрутки кліків і схеми шахраїв я писав окремо: «Бот-ферми: як фейкові відгуки та click fraud вбивають чесний бізнес». Про те, як Google оцінює недійсний трафік на стороні AdSense, дивіться «Як працює антифрод Google AdSense у 2025 році та як підняти RPM без бану».
❓ Часті питання (FAQ)
Чому GA4 показує трафік із країни, де в мене немає аудиторії?
Найчастіше причина — автоматичний трафік із хмарних мереж, VPN або проксі, а іноді й справжні відвідувачі, які користуються VPN. Перевірте залученість цього трафіку в GA4, а потім ASN і кількість запитів у Cloudflare, перш ніж робити висновки.
Чи можна вимкнути або налаштувати фільтр ботів у GA4?
Ні. Google прямо зазначає, що виключення відомих ботів вимкнути не можна, як і побачити, скільки даних було відсіяно.
Чи можна відфільтрувати країну через фільтри даних GA4?
Ні. Фільтри даних GA4 охоплюють лише внутрішній трафік і трафік розробників. Для аналізу використовуйте Explorations і сегменти, а для реального блокування — Cloudflare.
Чи видаляють фільтри ботів з історичних даних?
Ні, фільтри працюють лише вперед. Старі дані не перераховуються, тому порівнюйте періоди до і після змін, а не очікуйте «очищення» історії.
Чи варто блокувати країну в Cloudflare?
Зазвичай ні. Спершу перевірте ASN і залученість. Безпечніше застосувати Managed Challenge до підозрілих мереж, ніж блокувати країну повністю.
✅ Висновки
- 🔹 GA4 відсікає лише відомих ботів зі списку, а боти з повноцінним браузером виглядають як звичайні відвідувачі.
- 🔹 Одна ознака (країна, короткий сеанс) нічого не доводить. Підозру створює збіг кількох, а підтверджують її дані Cloudflare: ASN, запити, перевірки браузера.
- 🔹 Фільтри даних GA4 охоплюють лише внутрішній трафік і трафік розробників та працюють тільки вперед. Для аналізу використовуйте Explorations.
- 🔹 Блокувати варто на рівні Cloudflare: починайте з Managed Challenge для вузької умови, не чіпайте перевірених ботів і не блокуйте країни повністю.
- 🔹 Для видавця це ще й питання ризиків для реклами: недійсний трафік може призвести до обмежень акаунта.
- 🔹 Найнадійніший підхід — поєднувати GA4, Cloudflare і дані вашої рекламної платформи та перевіряти результат після кожної зміни.
📎 Джерела
Важливо: назви функцій, тарифні обмеження Cloudflare, інтерфейс GA4 і статистика ботів змінюються. Перед налаштуванням перевіряйте актуальні правила в офіційній документації. Умови й дані в цій статті актуальні на жовтень 2026 року.
