Як працює система перевірки сайтів у Google Ads

AI Google не стоїть на місці, і ми помітили нову проблему, через яку багато хто почав вилітати.

Коли ви запускаєте рекламу в Google Ads, система автоматично запускає багаторівневу перевірку посадкової сторінки (Landing Page), використовуючи такі модулі, як:

• Crawler (боти Google)
• Policy Risk Engine + Gemini (рушій правил)
  раніше SpamBrain + MUM, зараз Gemini
• Rendering System (виконання JS та емуляція поведінки юзера)

Крок 1. Crawler заходить на сайт

Бот з IP із Google-пулу робить HTTP-запит:

• Заголовки: стандартні (User-Agent: Googlebot, іноді маскування під Chrome)
• Локація: часто — США
• Без кукі, без JS-інжектів, чисто як звичайний юзер

Що аналізується:

• Структура HTML-документа
• Meta-теги (description, title)
• Зовнішні посилання, редиректи
• Наявність obfuscated або suspicious JS (тут більше інфо, що це за код і чому його не любить Гугл)

Важливий момент для тих, хто хоче детектити реального Googlebot

Googlebot верифікується не лише за User-Agent рядком, а через reverse DNS lookup. Тобто справжній Googlebot перевіряється так:

IP → hostname (має містити googlebot.com) → назад IP

Якщо не збігається — це не Googlebot.

Це означає, що детектити бота тільки через navigator.userAgent.includes(“Googlebot”) вже давно безглуздо. Google це бачить моментально, і саме так позначає спробу клоакінгу.

Крок 2. Policy Risk Engine + Gemini

Це головний механізм, який визначає:

“Чи відповідає сайт політиці Google?”

Раніше тут рулювали SpamBrain і MUM. Зараз картина інша. З 2025 року основним інструментом перевірки став Gemini та його моделі оцінки намірів.

Google офіційно заявив, що Gemini заблокував понад 99% рекламних оголошень, які порушують правила, ще до їх показу.

Це вже не пошук заборонених слів по лендингу, а аналіз наміру всього, що ви робите:

• акаунт
• домен
• патерни запуску
• історія IP

SpamBrain продовжує працювати, але насамперед по SEO-спаму в органіці. В Ads Enforcement головний суддя зараз — Gemini.

Він аналізує:

• Видимість і читабельність контенту
• Обманні елементи: кнопки, таймери, фейкові відгуки
• Fingerprint-логіку в JS
• Підозрілу поведінку: редиректи, різні домени, підміну контенту
• Історію акаунта, вік, патерни запуску кампаній

Якщо знайдено підозрілий JS — запускається повторний рендер із увімкненим JS.

Крок 3. Повний JS-рендер (як звичайний користувач)

Google не просто читає HTML — він реально виконує JavaScript, як звичайний браузер. Вмикається Web Rendering Service, аналог Chrome.

Google емуляє:

• поведінку звичайного користувача;
• відмальовування сторінки;
• кліки, скроли, навіть затримки;
• аналізує: чи є редиректи через 2–3 сек.

Внутрішні сигнали:

Крок 4. Порівняння «що бачить бот» і «що бачить людина»

Google порівнює:

• Версію сторінки, отриману без виконання JS (як бот)
• Версію після повного рендера з JS (як користувач)

Якщо контент відрізняється — це:

• або клоакінг,
• або підміна даних,
• або обман системи.

Це веде до блокування акаунта, домену і часто — ланцюжка пов’язаних акаунтів.

Що змінилося з приходом Gemini

Старі системи шукали ключові слова, дивилися редиректи та звіряли HTML. Gemini працює інакше.

Він оцінює намір усього, що відбувається:

• чому цей акаунт створений саме зараз;
• чому саме такий патерн запуску;
• чому домен зареєстрований 3 дні тому;
• чому платіжка з однієї країни, а проксі — з іншої.

Це важливо зрозуміти, тому що старі методи “зроби красивий вайт і буде ок” вже не такі надійні. Gemini бачить намір навіть тоді, коли лендинг технічно чистий.

За офіційними даними Google за 2025 рік:

• понад 8.3 мільярда оголошень заблоковано або видалено;
• 24.9 мільйона акаунтів призупинено;
• при цьому некоректні бани легітимних рекламодавців знизилися на 80%.

Тобто система стала точнішою. Випадково не відлітають. Якщо відлетів — причина є, і Google її знайшов.

Приклад, як Google палить клоаку

Headless Chrome detection

Коли твій сервер або клоакер запускає прихований браузер, щоб прогріти сторінку або перевірити, що бачить бот, Google бачить це через кілька сигналів:

// Google перевіряє ці значення в headless-середовищі:

• navigator.webdriver // true у headless, undefined у реального юзера
• navigator.plugins.length // 0 у headless
• navigator.languages // часто порожній масив

Плюс WebGL і Canvas-рендеринг у headless-середовищі дає інший fingerprint, ніж у реальному Chrome.

Google накопичив величезну базу “нормальних” fingerprint-патернів, і аномалія детектиться автоматично.

React SPA, яке показує різний контент для бота і юзера, теж під прицілом. Якщо після повного JS-рендера контент відрізняється від того, що було в HTML при першому запиті — це флаг.

Крок 5. Поведінковий та історичний аналіз

Google Ads пов’язує:

• Раніше використані домени
• Пов’язані акаунти, платіжки, пристрої
• Час життя акаунта, патерни запуску

Якщо ти лив з одного шаблону/білда на різні акаунти — ти під ковпаком.

Що нового у 2026

Додався triple GEO-match: система звіряє GEO платіжної картки + GEO fingerprint браузера + GEO проксі.

Якщо ти підключаєш німецьку картку з профілем під США через азійський проксі — це автоматична позначка:

“potential payment fraud”

Акаунт не обов’язково одразу відлітає, але траст падає до нуля, і вже наступна підозріла активність дає suspend.

MCC contamination — окрема історія, про яку багато хто не знає

З середини 2025 року, якщо Manager Account (MCC) порушує third-party policy, усі пов’язані з ним акаунти можуть бути призупинені.

Тобто якщо ти орендуєш акаунт через агентство, яке потрапило під обмеження — ти теж падаєш.

Завжди перевіряй історію MCC, під яким працюєш.

Якщо ти працюєш із gambling/нутрою через орендовані акаунти

Важливо знати, що з березня 2026 року посилилися правила щодо gambling-сертифікації.

Акаунти з gambling-історією, які пов’язані з іншими акаунтами через платіжки або IP, повністю відсторонюються.

Що тригерить бан?

Який висновок робить Policy Risk Engine?

Якщо:

• сайт змінює поведінку залежно від IP/UA;
• є редиректи тільки для людини;
• JS-код підозрілий та обфускований;

Виноситься вердикт:

Cloaking Detected → Ad Account Suspended

Тепер бонус для тих, хто дочитав до кінця — через що перевіряти сам сайт

1. PageSpeed Insights

PageSpeed Insights

Що перевіряє: як сайт завантажується з точки зору Google, включно з JS.

Навіщо: показує, як бот бачить сторінку, особливо якщо white порожній або лендинг вантажиться через JS.

Важливо: PSI використовує Lighthouse і WRS для оцінки продуктивності, але це не той самий стек, що в Ads Policy Engine.

Тобто “зелений PSI” не гарантує, що ти пройдеш модерацію.

Використовуй його як один із сигналів, а не як фінальну перевірку.

2. URL Inspection Tool — це важливіше за PSI для наших задач

URL Inspection Tool

Це вже напряму показує, як Googlebot відрендерив сторінку.

Заходиш у Search Console, вставляєш URL, натискаєш:

“Test Live URL”— і бачиш скріншот того, що побачив бот + HTML після рендера.

Це точніше і чесніше, ніж PSI, для перевірки клоаки.

3. WHOIS-перевірка

DomainTools WHOIS

Що робить: показує вік домену, хостинг, конфігурації.

Навіщо: молоді домени + Cloudflare + no WHOIS = високий ризик.

5. Search Console + живі сигнали

Додай домен у Google Search Console з того ж Google-акаунта, з якого будеш запускати рекламу.

Це сигнал, що домен реальний і пов’язаний із живим акаунтом, у якого є історія.

Далі мінімально прогрій поведінкові фактори:

• кілька реальних сесій;
• прокрутка сторінки;
• час на сайті.

Не треба нічого накручувати. Достатньо, щоб не було абсолютного нуля.

Посилання на соцмережі на вайті обов’язково. Telegram, Instagram, будь-які — головне, щоб були клікабельні та вели на живі сторінки.

1–2 тематичні зворотні посилання на домен теж не зайві, підвищують траст. Тільки купуй тематичні, а не з загальних бірж.