Логика создания Whitepage для Google Ads: от чистого кода до Edge-фильтрации

Время, когда для прохождения модерации в Google Ads достаточно было создать за 30 мин простой одностраничный сайт, к сожалению, давно прошло. Сейчас алгоритмы оценивают не только контет насыщение, но и всю техническую составляющую.

Фактически на текущий момент Whitepage - это одна из ключевых составляющих сетапа, от которой непосредственно зависит срок жизни аккаунта и его результативность.

Поэтому в этой статье мы постараемся детально рассказать о нашей логике работы с вайтами, отталкиваясь от положительного и негативного опыта.

CMS против чистого HTML

Выбор платформы - тема, в которой споры никогда не заканчиваются.

WordPress.

Многие склоняются к мнению, что если сайт создан на популярной CMS вроде WordPress, то в таком случае Google будет больше доверять ему.

Массово тестировали эту теорию в различных сетапах: прямой корреляции/связи между движком и сроком жизни аккаунта вовсе не заметили.

Но во время работы с WordPress могут появляться некоторые осложнения:

• Конфликты: кэширование WP и его особенности часто ломают скрипты клоакинга и кастомные in-house скрипты, что выливается в проблемы с автоматизацией и необходимости лезть в ядро WP либо ставить множество различных плагинов, тем самым раздувая код.

Чистый HTML и ИИ

Для личных целей и задач мы используем только чистый HTML.
Главная причина - уникальность и вариативность интеграций.

Вайты, которые реализованы с помощью различных шаблонов, рано или поздно начинают детектиться со стороны Google и получать баны на этапе модерации кампании. Дабы избежать данной проблемы, мы используем Claude Code -с целью верстки и реализации уникального кода на каждом вайте.

Также это позволяет нам без каких-либо проблем интегрировать любые скрипты и прочие технические решения на наши вайты.

Домены, хостинг и проверка истории

Это самые базовые составляющие, которым в первую очередь нужно уделять внимание.

Регистрация и аудит доменов.

Мы закупаем домены через Regway, но перед покупкой каждый домен проверяем через Web Archive (Wayback Machine).

Если раньше на домене находился гемблинг, серые крипто-офферы или дорвеи - пропускаем.

Любая негативная история домена сводит практически к нулю все попытки создания качественного Whitepage.

Серверы.

В качестве проверенного хостинга мы выбираем пулы от Yotta SRC. ( Адекватная цена и качество )

Cloudflare.

Присутствует множество мнений касаемо Cloudflare, но фактически это лишь часть пазла, которая как уникальная единица не имеет весомого влияния на конечную результативность.

Google отлично видит, что сайт работает через CDN, и воспринимает это как норму, а не как повод доверять вам больше.

Единственное, для чего мы используем Cloudflare, дабы скрыть реальный IP-адрес сервера и отсеять самых примитивных ботов. В том числе базовая защита от скликивания.

Используйте CDN для защиты серверов, а не с целью получить больше траста.

Релевантность: Search против Demand Gen

Релевантность вайта относительно целевого оффера один из весомых факторов, на который тоже необходимо обратить внимание в определенных типах кампаний.

Например:

• Поиск: пользователь вводит конкретный запрос, и Google хочет показать ему логичный ответ. Если в объявлении мы говорим про финансы, а на сайте история керамики, алгоритм сразу видит обман. Итог: низкий Trust Score и бан.

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

• Demand Gen: в данном случае человек не ищет ваш продукт целенаправленно, он просто потребляет контент.

Главная задача сайта - не триггерить бота. Для таких кампаний отсутствие запрещенного контента важнее идеального совпадения с креативом. Нейтральный, технически чистый сайт работает лучше, чем попытка натянуть серый оффер на релевантный ленд.

Чек-лист

В этом разделе напишем основные критерии, которых придерживаемся при создании вайтов.

• Юр.составляющая: обязательно наличие всех политик под необходимую юрисдикцию - Privacy Policy, Terms of Service, Cookie Policy, Refund Policy, Affiliate Disclosure. (В зависимости от вашего оффера могут добавляться уникальные политики)
• Доп.уникальные метатеги: title, description, OG/X, canonical, hreflanf. Штатно добавляем на уровне привычки, так сказать. Но фактически можно избегать данного пункта.

• Consent v2: сейчас это просто стандарт. Если вы собираете данные без согласия пользователя, траст сайта падает моментально. (Если нет желаения/возможности писать кастомные скрипты, можно использовать готовые решение. К примеру, Cookie Bot)
• Микроразметка Schema.org + sitemap.xml: разметка JSON-LD под тип страницы (Organization, Review, Article, FAQPage, BreadcrumbList). Помогает Google понять, что за компания перед ним, где она находится и как с ней связаться.
• Google Search Console: подключаем GSC для Search-кампаний. (Не считаем, что это значительно увеличивает траст, подключаем для дополнительной аналитики в большинстве случаев).
• Интеграция Google сервисов: Cookiesbot + Consent Mode v2, reCAPTCHA v 3 на формах, Google Analytics 4, Google Maps (реальный адрес, телефон в футере и на странице контактов)

• Рабочая форма обратной связи: форма должна фактически отправлять данные и перекидывать человека на страницу "Спасибо".
• Понятная монетизация: В обязательном порядке интегрируем понятную и прозрачную модель монетизации бизнеса, с чего зарабатывает данный сайт.

Дополнительный критерии:

• Многостраничность (от 10 страниц): Минимум 10 контентных страниц .
• Отсутствие заглушек: все ссылки в меню и соцсетях должны вести на реальные внутренние страницы («"О нас", "Вакансии") или профили.
• Скорость (Core Web Vitals): не перегружаем сайт лишними скриптами, медленная скорость загрузки сайта - плохой пользовательский опыт по мнению Google.

Возможное будущее клоакинга: Edge-фильтрация и гибридный подход

Мы придерживаемся позиции, что время классического клоакинга через тяжелые PHP-скрипты постепенно уходит.

Алгоритмы Google все лучше вычисляют задержки ответа, странные HTTP-заголовки и серверные редиректы, в том числе начинают проксировать IP юзеров через свои серверы.

Вполне возможно, что новым стандартом станет Edge-фильтрация (на уровне DNS). В этой модели фильтрация происходит на уровне CDN - максимально близко к пользователю. Запрос проверяется еще до того, как дойдет до вашего сервера.