Google Ads 2026: Policy Risk Engine, причини банів і як не злити акаунт на старті

25.03.2026

Google Ads стає жорсткіше щороку — і 2026-й не виняток. Платформа передала модерацію AI, ручний рев’ю став рідкістю, а швидкість блокувань зросла кратно. Розбираємо, що відбувається всередині системи, які причини банів зустрічаються найчастіше і як правильно готувати інфраструктуру під запуск.

Цифри, які важливо знати

За Google Ads Safety Report за 2024 рік (опублікований навесні 2025) платформа видалила 5.1 млрд оголошень і заблокувала 39.2 млн рекламних акаунтів — утричі більше, ніж роком раніше. Додатково обмежено 9.1 млрд оголошень за розміщенням. Звіт за 2025 рік вийде в квітні–травні 2026, і за динамікою останніх років на пом’якшення чекати не варто.

За цим зростанням стоїть конкретна причина: Google впровадив понад 50 LLM-покращень у систему модерації, і тепер переважна більшість акаунтів блокується ще до того, як вони встигають відкрутити хоч один показ. Спеціалізована команда з AI-фроду окремо відключила понад 700 000 акаунтів за місрепрезентацію — це дало зниження скарг на deepfake-рекламу на 90%.

У 2025 році Google запустив AI Max for Search — набір AI-функцій, який змінює логіку таргетингу в пошукових кампаніях. Система розширює охоплення за межі буквальних ключів, автогенерить ассети з посадкової, підтягує аудиторні сигнали. Для білих схем це плюс. Для сірих — додатковий ризик: AI Max детально сканує контент лендингу і бачить розбіжність між оголошенням і тим, що на сайті.

Policy Risk Engine: чому акаунт горить без попередження

Policy Risk Engine — загальна назва автоматичних систем оцінки ризику акаунту в Google. Система аналізує все: домени, IP, історію платежів, поведінку на акаунті, зв’язки між акаунтами, патерни запуску кампаній.

Близько 90% блокувань відбувається автоматично — без живого модератора. Апеляція з реальним спеціалістом — рідкість, яка залежить від категорії порушення, суми історичних витрат і наявності Advertiser Verification.

Акаунти з історією витрат від 10 000 до 100 000+ за досвідом арбітражників мають трохи більше шансів потрапити на ручний рев’ю — але це не правило і не гарантія. Розраховувати на це як на стратегію не варто.

Причини блокувань: що реально летить

Suspicious Payments

Одна з найчастіших причин заморозки одразу після поповнення. Тригери:

віртуальні картки з нестандартними BIN
картки, які вже фігурували в заблокованих акаунтах
поповнення понад 500 одиниць з нового методу оплати без історії
невідповідність білінг-адреси і гео акаунту
часті чарджбеки з даної картки в екосистемі Google (Ads, YouTube, Cloud)

Антидетект браузери, проксі-сервіси — самі по собі не причина бану. Причина в тому, як ти їх використовуєш і наскільки чистий fingerprint оточення в момент поповнення.

Unpaid Balance

Борг перед Google — це не просто мінус на балансі. Це маркер, який прилипає до платіжного методу, домену і MCC. Запускати новий акаунт з тим самим платіжним методом або під тим самим MCC, де висить борг — прямий шлях до миттєвого бану.

Circumventing Systems

Одна з двох виняткових категорій — блокування без попередження. Сюди потрапляє:

клоакінг: показуєш Google одну сторінку, користувачу — іншу
мультиакаунтинг для обходу існуючих блоків
маніпуляції з NS, Cloudflare, підміна контенту через HTML-ін’єкції
IPv6-ротація і нестандартні схеми fingerprint для обходу детекції
редиректи, які змінюють гео або контент залежно від джерела трафіку

Keitaro і Binom — легітимні трекери, які Google знає і вміє обходити. Якщо трекер ховає UTM-параметри від Google або підставляє різні лендинги — це обхід системи. Якщо налаштований чесно — ні.

Unacceptable Business Practices (UBP)

Друга виняткова категорія. Сюди летить все, що пов’язане з обманом користувача: фейкові дедлайни, неіснуючі знижки, фальшиві відгуки, невідповідність між оголошенням і реальним офером.

Найчастіші тригери для арбітражників:

лендинг не відповідає тому, що написано в оголошенні
немає реального продукту або послуги — тільки редирект
відсутність умов повернення, контактів, політики конфіденційності
домени в зоні .eu, .com, .net без реальної прив’язки до бізнесу

Malicious Software і Compromised Site

Malicious Software часто прилітає не тому, що арбітражник спеціально заливає шкідливий код, а тому що сайт або CMS заражені — і він про це не знає. Тригери: сторонні JS-скрипти з підозрілою поведінкою, застаріла CMS із вразливостями, редиректи, які спрацьовують тільки для певних IP або user-agent, відсутність SSL.

Compromised Site — окрема історія. Google бачить зламаний сайт через сканування, Cloudflare Beacon Analytics або сторонні бази. Якщо домен засвічений у VirusTotal або Archive.org як скомпрометований — запускати на ньому кампанії марно, блокування буде автоматичним.

Чек перед запуском: WHOIS, VirusTotal, Archive.org — обов’язковий крок для кожного нового домену. На сервері: ufw + fail2ban + SSL через certbot, актуальні версії CMS і плагінів.

Інфраструктура: що реально впливає на виживання акаунту

Домен і хостинг:

Реєстрація через Namecheap, GoDaddy, Domenest — нейтральна репутація, робочі варіанти
VPS замість шаред-хостингу — стабільніше, немає “сусідів” з поганою історією
Cloudflare підключений, Email Obfuscation і Beacon Analytics вимкнені — вони створюють зайві сигнали при скануванні
Ping від Cloudflare до сервера менше 0.5 с — базовий тест якості ноди

Сервер:

nginx + php-curl як стек
fail2ban + ufw + certbot (SSL)
HTTP → HTTPS редирект, заголовки Permissions-Policy і X-Frame-Options прописані
index-файл без сторонніх скриптів

Перевірка перед запуском:

FV.PRO і Pixelscan — fingerprint оточення
IPQS + WebRTC-тест — витоки IP
Google My Activity — що Google знає про акаунт
MaxMind або Bulk Check Page Authority — репутація домену
VirusTotal — домен і сервер

MCC: ізоляція, а не просто структура

MCC за замовчуванням створює видимий зв’язок між акаунтами всередині нього. Додати скомпрометований акаунт у робочий MCC — означає створити цей зв’язок. Тому ізоляція будується не на рівні “додати чи ні”, а на рівні повного розділення інфраструктури.

Що працює на практиці:

Акаунти з різними доменами і оферами не шарять один платіжний метод
Кожен акаунт ізольований за платіжкою, IP і оточенням
Один fingerprint, IP або billing-адреса на кілька акаунтів — це слід мультиакаунтингу, Google його бачить
Advertiser Verification у 2026 році обов’язкова для ніш: фінанси, нутра, крипта та ряд інших — без неї кампанії не пройдуть рев’ю

Що змінилось у 2025–2026

AI Max for Search активно просувається Google як основний формат для пошукових кампаній. Система сама розширює ключі, генерить ассети, шукає аудиторію за межами явного таргетингу. Лендинг сканується детальніше — розбіжність між посадковою і офером тепер бачить машина, а не тільки модератор.

Апеляція жива, але це вже не «чарівна кнопка». Google очікує, що ти спочатку прибереш усе, що ламає політику, а у формі коротко розпишеш, що саме виправив, і докладеш пруфи — скріни, оновлені ленди, політики, технічні звіти. Case ID — це просто трекінг: більшість заявок спочатку розгрібає машина, а до людини долітають тільки складні історії. Тому ставка — на інфраструктуру, зібрану «по білому» ще до запуску, а апеляцію варто сприймати як спосіб зафіксувати відповідність, а не вибити собі виняток.

Advertiser Verification розширюється. Google поетапно вводить верифікацію для нових регіонів і категорій. Стеж за оновленнями політик — від цього залежить, пройде акаунт рев’ю без додаткових перевірок чи ні.

Чек-лист перед запуском

Домен і сайт:

Домен перевірений через VirusTotal, WHOIS, Archive.org — немає історії порушень
SSL встановлений, HTTP редиректить на HTTPS
Політика конфіденційності, контакти та умови повернення на сайті є
Лендинг відповідає оферу: немає фейкових дедлайнів, фальшивих знижок, чужих відгуків
Cloudflare підключений, Email Obfuscation і Beacon Analytics вимкнені
CMS оновлена, сторонні плагіни перевірені, зайві видалені
index-файл чистий, немає сторонніх JS-скриптів із зовнішніх доменів

Сервер:

nginx налаштований, PHP актуальної версії
fail2ban + ufw встановлені та активні
SSL-сертифікат через certbot, валідний
Заголовки Permissions-Policy і X-Frame-Options прописані
Ping до сервера через Cloudflare менше 0.5 с

Акаунт і оточення:

Fingerprint перевірений через FV.PRO і Pixelscan
IP перевірений через IPQS, WebRTC-витоків немає
Картка не засвічена в раніше заблокованих акаунтах
BIN картки робочий для даного гео
Billing-адреса збігається з гео входу
Google My Activity чиста
Advertiser Verification пройдена, якщо офер із регульованої ніші
Акаунт не пов’язаний з іншими через спільний платіжний метод, IP або fingerprint

Google Ads у 2026 році — середовище, де більшість рішень приймає машина. Апеляція працює рідко, приводів для флага у системи стало більше, а AI Max додав ще один шар сканування лендингу. Єдине, що реально знижує ризики — інфраструктура, зібрана за правилами, і розуміння того, що саме тригерить блокування на кожному етапі: від реєстрації акаунту до першого відкруту.В нашому боті @banana_traffbot ще більше безкоштовних мануалів по Google Ads і актуальна вітрину трастових акаунтів під різні ніші.