Сплеск сесій із Китаю та Сінгапуру в GA4, найімовірніше, створили не люди: Product Expert в офіційній спільноті Google Analytics назвав цей трафік нелюдським, а вбудоване виключення GA працює лише для відомих ботів. Перевірте його за часом залученості, Search Console і серверними логами, для звітів використовуйте сегменти, а події з чужим іменем хоста відсікайте фільтром GA4, який з'явився в червні 2026 року. Країну на CDN обмежуйте лише після перевірки та з винятком для верифікованих ботів.
Що таке бот-трафік із Китаю та Сінгапуру в GA4
Бот-трафік із Китаю та Сінгапуру в GA4 — це сесії без людей: автоматичні візити, які Google Analytics записує як користувачів із цих країн.
Хвиля почалася восени 2025 року: власники сайтів почали повідомляти про різке зростання сесій із Китаю та Сінгапуру майже без залученості та конверсій. Product Expert в офіційній спільноті Analytics Help назвав цей трафік неавтентичним і нелюдським. За довідкою Google Analytics, GA автоматично виключає лише трафік відомих ботів і павуків: їх визначають за дослідженнями Google та списком IAB, вимкнути виключення не можна. Повідомлень про те, що проблему повністю вирішено, ми станом на вересень 2026 року не знайшли. Єдина помітна зміна в самому GA4 — фільтр за іменем хоста, про нього нижче.
Спочатку з'ясуйте, чи доходять ці візити до вашого сервера. Порівняйте GA4 із серверними логами або аналітикою CDN за ті самі дати. Якщо запити там є, на сайт ходять боти, і зупинити їх можна на рівні CDN. Якщо запитів немає, дані потрапили в GA4, минаючи ваш сайт, і правило на сервері чи CDN на них не вплине: потрібні сегменти та фільтри всередині аналітики.
Чим бот-трафік шкодить affiliate-сайту
Головна шкода припадає на дані. Сесії без людей потрапляють у звіти разом зі справжніми, тому середні показники залученості та географія перестають відображати реальних відвідувачів.
Для affiliate-сайту це перетворюється на конкретні помилки. Ви оцінюєте сторінки за конверсією із сесій у кліки на оффер і реєстрації. Якщо помітна частина сесій фейкова, знаменник завищений, і конверсія виглядає гіршою, ніж є насправді. Ви переписуєте вдалий огляд, прибираєте робочий брідж-лендинг або робите висновки з A/B-тесту, на який впливають боти, а не варіанти сторінки.
Є й репутаційний ризик. Якщо ви продаєте розміщення й показуєте покупцям цифри з GA4 без очищення, розмова стане неприємною, коли той попросить доступ до Search Console і побачить розбіжність. Як рекламодавці перевіряють такі цифри, ми розібрали в статті про перевірку трафіку майданчика перед купівлею статті чи банера.
Окремо стоїть GEO. За даними Міністерства внутрішніх справ Сінгапуру, онлайн-гемблінг там дозволено лише в одного ліцензованого оператора — Singapore Pools. У материковому Китаї азартні ігри суворо заборонені, виняток становлять ліцензовані державні лотереї, як зазначає юридичний довідник Chambers. Тому живих читачів казино-оглядів звідти зазвичай небагато. Якщо на сторінки про казино та беттинг із цих країн приходять десятки відсотків трафіку, це тривожний сигнал сам по собі. Перевірте під свої оффери: якщо ви працюєте за азійськими GEO, картина інша, і відсікати ці країни автоматично не можна.
Про вплив на SEO. Даних про те, що такі сесії рухають позиції в пошуку, ми не знайшли: вони псують звіти, а не видачу. Страждають рішення, які ви ухвалюєте на цих цифрах. Про реальні показники ROI в ніші читайте в розборі iGaming SEO у 2026 році.
Як відрізнити ботів від людей у GA4
Почати найпростіше зі звіту за країнами: «Звіти» → «Користувач» → «Атрибути користувача» → «Відомості про демографічні характеристики». Назви пунктів у вашому інтерфейсі можуть відрізнятися, тоді шукайте звіт «Демографічні дані». Для кожної країни дивіться частку нових користувачів і середній час взаємодії.
Як виглядають боти у звіті: приклад
Нижче звіт GA4 невеликого сайту.
Вибірка маленька, але картина показова. Три речі видають ботів одразу. Три чверті користувачів прийшли з однієї країни. Усі 44 сінгапурські користувачі нові, жоден не повернувся. А середній час взаємодії дорівнює нулю.
Пастка ховається в частці взаємодії. 52% виглядає пристойно, і за цією метрикою сінгапурський трафік навіть кращий за решту. Пояснення є у визначенні. За довідкою Google Analytics, GA4 вважає сеанс залученим, якщо він тривав понад 10 секунд, містив ключову подію або включав два перегляди сторінок і більше. За нульового часу взаємодії спрацював не перший критерій: або два перегляди, або ключова подія. Перевірте, які події у вас позначені як ключові: будь-яка з них робить сеанс залученим.
Порахуємо решту. За 30 залучених сеансів і частки 50% усього сеансів близько 60. Сінгапур дав 44 із них, решті дісталося 16, і залученими з них виявилися 7, тобто близько 44%. Середня тривалість взаємодії в 14 живих користувачів виходить близько семи хвилин: 58 користувачів на 1 хвилину 43 секунди потрібно розділити на 14 людей. Живі люди читають у рази довше, а за відсотком залученості виглядають гірше за ботів. Тому дивіться на час взаємодії та частку нових користувачів, а не на частку взаємодії.
Звірка з Search Console
За довідкою Search Console, звіт про ефективність показує кліки та покази в результатах пошуку Google, а дані можна згрупувати за країнами. Якщо в GA4 із Китаю чи Сінгапуру багато сесій, а кліків із пошуку за цими країнами в Search Console майже немає, ці візити прийшли не з пошуку Google.
Логи, CDN і трекер
Порівняйте серверні логи або аналітику CDN за дні сплеску з тим, що показує GA4. Можливі два результати. Якщо запити в логах є, на сайт реально ходять боти, і тут працює захист на рівні CDN. Якщо запитів немає, дані потрапили в GA4, минаючи ваш сервер, і вирішувати проблему потрібно всередині аналітики.
Конверсію рахуйте за даними трекера та постбеками партнерки, а не за сесіями GA4. Докладніше про контроль якості трафіку в партнерках — у гайді з affiliate-маркетингу.
Як прибрати бот-трафік із GA4: способи й план на годину
Порівняння способів
Сегменти й фільтри у звітах дані не видаляють, тому для аналізу це безпечний варіант. Наприклад, створіть у «Дослідженнях» сегмент сеансів, з якого виключено China і Singapore з тривалістю сеансу менше 10 секунд. Поріг тут — приклад, підлаштуйте його під свій сайт.
З червня 2026 року в GA4 є жорсткіший інструмент: фільтр за іменем хоста. Він розташований у розділі «Адміністратор» → «Збір і редагування даних» → «Фільтри даних» (назви в українському інтерфейсі можуть відрізнятися), а створити його може користувач із роллю «Редактор» і вище. Спочатку відкрийте вимір «Ім'я хоста» і подивіться, що стоїть у сесій із Китаю та Сінгапуру. Якщо хост не ваш, додайте його у фільтр. Якщо хост збігається з вашим, фільтр за хостом не допоможе.
У фільтра є обмеження. Він виключає події, зіставляє хост лише за точним збігом або за входженням рядка й діє лише на нові дані, а виключені події в GA4 не обробляються. Google передбачив режим Testing: у ньому події, що збіглися, позначаються виміром «Test data filter name», і ви перевіряєте фільтр до вмикання. Почніть із нього й подивіться, чи не потрапили під фільтр живі відвідувачі. Якщо у вас кілька доменів або піддоменів, заздалегідь випишіть усі легітимні хости.
Правило Cloudflare для трафіку зі Сінгапуру та Китаю без блокування Googlebot
Якщо сайт стоїть за Cloudflare, ботів, які реально відкривають сторінки, можна зупинити правилом WAF. Ось варіант, який допоміг на практиці:
(ip.geoip.country eq "SG" and not cf.client.bot)Читається так: запит зі Сінгапуру (код країни SG) і водночас не від верифікованого бота. Умова not cf.client.bot не дає правилу зачепити Googlebot, Bingbot та інші верифіковані краулери. Той самий прийом Cloudflare описує в прикладі про пропуск пошукових ботів: запити зі списку країн проходять перевірку, а пошукові й інші верифіковані боти пропускаються.
Щоб охопити й Китай, додайте код CN:
(ip.src.country in {"SG" "CN"} and not cf.client.bot)У документації Cloudflare трапляються обидва поля: ip.src.country в актуальних прикладах і ip.geoip.country у ранніх.
Як створити правило. У панелі Cloudflare відкрийте користувацькі правила WAF (Custom rules), натисніть «Create rule», перемкніться на редактор виразів і вставте формулу. Як дію почніть із Managed Challenge: так зроблено в прикладі Cloudflare. Дію Block вмикайте лише тоді, коли впевнені, що справжніх відвідувачів із цих країн у вас немає.
Далі перевірте два моменти.
- Через добу-дві порівняйте сесії зі Сінгапуру в GA4 до і після. Якщо вони помітно впали, ви мали справу з ботами, які відкривають сторінки. Якщо майже не змінилися, ці дані йдуть у GA4, минаючи Cloudflare, і потрібні сегменти в «Дослідженнях» та фільтр за іменем хоста.
- Відкрийте звіт про статистику сканування в Search Console і переконайтеся, що Googlebot, як і раніше, проходить без помилок.
Правило за країною зачепить і живих людей із цих країн, наприклад користувачів із VPN. Якщо ви працюєте за азійськими GEO, обмежте його потрібними адресами або ASN замість усієї країни.
План на одну годину
- Подивіться частку Китаю та Сінгапуру в GA4 за останні 90 днів і порівняйте з періодом до осені 2025 року. Відзначте середній час взаємодії та частку нових користувачів за країнами.
- Відкрийте «Дослідження» й створіть сегмент без цих країн для аналізу.
- Звірте дані з Search Console за країнами та з логами за дні сплеску. З'ясуйте, чи доходять ці візити до вашого сервера.
- Відкрийте вимір «Ім'я хоста» у цих сесій. Якщо хост чужий, створіть фільтр за іменем хоста в режимі Testing.
- Якщо запити в логах реальні, увімкніть на CDN правило з Managed Challenge та винятком для верифікованих ботів (приклад для Cloudflare вище). Жорсткий Block для країни залиште на крайній випадок.
- Після правил відкрийте звіт про статистику сканування в Search Console і переконайтеся, що Googlebot проходить без помилок. Якщо потрібно перевірити індексацію у великому обсязі, стане в пригоді масова перевірка індексації.
- Рахуйте конверсію та залученість за очищеним сегментом і за даними трекера. Рішення щодо лендингів ухвалюйте за ними, а не за загальними цифрами GA4.
- Запишіть дату початку сплеску й поверніться до перевірки за місяць. Google поки не оголошував про повне вирішення, тому сегмент і фільтр доведеться підлаштовувати.
Часті помилки
Увімкнути фільтр за іменем хоста одразу в режимі Active. Він не діє на минулі дані, а виключені події не обробляються, тому спочатку використовуйте режим Testing.
Заблокувати країну на CDN і вважати проблему закритою. Якщо дані йдуть у GA4, минаючи сервер, блокування на них не впливає.
Обмежити країну без винятку для верифікованих ботів. У прикладі Cloudflare умова not cf.client.bot стоїть саме для того, щоб правило не зачепило пошукових краулерів.
Орієнтуватися на частку взаємодії. Як видно з прикладу вище, у ботів вона може бути вищою, ніж у людей.
Сприйняти сплеск за ріст аудиторії й показати його партнерам або в медіакіт. Розбіжність виявиться під час першої ж перевірки через Search Console.
Часті запитання
Підсумок
Почніть із години роботи: звірка GA4, Search Console і логів покаже, скільки у вашому трафіку людей і чи доходять боти до сервера. Далі сегмент для аналітики, за потреби фільтр за іменем хоста та правило на CDN з винятком для верифікованих ботів. Країну повністю блокуйте, лише якщо після перевірки це виправдано. Якщо ви ведете affiliate-сайт, перерахуйте конверсії за очищеними даними, перш ніж міняти сторінки. Загальний контекст щодо органіки в ніші є в гайді з SEO для affiliate.
