Клоакинг в широком смысле — это фильтрация трафика: автоматическим краулерам и ботам отдаётся одна версия страницы, живым пользователям — другая. На практике большинство проблем не в самом инструменте, а в конфигурации. Разберём пять типичных ошибок настройки, из-за которых фильтрация работает не так, как ожидается, — и как их избежать.

Если коротко

Чаще всего страдают две вещи: качество и релевантность открытой (white) страницы — рекламные площадки требуют, чтобы посадочная соответствовала объявлению, — и точность фильтра: настройка по одному сигналу даёт ложные срабатывания. Дальше идут чисто технические косяки: TTL, edge-кэш и слишком грубая сегментация по гео.

Ошибка 1. White-страница не соответствует требованиям площадки

Рекламные площадки (Google, Meta, TikTok) предъявляют требования к качеству и релевантности посадочных страниц: страница должна соответствовать объявлению и нести реальную ценность для пользователя. Если объявление про фитнес ведёт на абстрактную страницу «ни о чём», это нарушает их правила к качеству лендинга — и площадка вправе отклонить рекламу.

Как правильно: делайте открытую страницу настоящей тематической страницей, релевантной объявлению. Если креатив про фитнес — страница должна быть про здоровый образ жизни: советы по питанию, разбор тренировок, интервью с экспертом. Полноценный контент проходит ревью гораздо лучше, чем пустые «заглушки».

Что мы наблюдаем

Команды, которые делают открытую страницу длиной 800–1500 слов с парой изображений, проходят ревью площадок в 3–4 раза чаще, чем те, у кого там «Hello world». Автоматические и ручные проверки оценивают, что на странице по факту.

Ошибка 2. Фильтрация по одному сигналу даёт ложные срабатывания

Частая настройка — «показывать основную страницу только если реферер пустой». Проблема в том, что у значительной части пользователей iOS 17+ реферер пустой по умолчанию (Apple Tracking Prevention). В итоге часть живого трафика видит открытую страницу вместо целевой — конверсия проседает на ровном месте.

Зеркальная ошибка — слишком жёстко резать по user-agent: легитимные превью-боты мессенджеров и почтовых клиентов попадают под фильтр вместе с поисковыми краулерами, и ссылки в превью выглядят сломанными.

Правильно: фильтровать не по одному критерию, а по совокупности сигналов. У нас, например, fingerprint, поведение и характеристики сети дают общий score, и решение принимается по score, а не по единственному признаку — так меньше ложных срабатываний в обе стороны.

Ошибка 3. CDN кэширует и отдаёт всем одно и то же

Классика. Ставите Cloudflare с proxied = true, не настраиваете cache rules — и через 5 минут любой посетитель получает ту версию, которую Cloudflare закэшировал первой. Фильтрация при этом фактически отключается: все видят одну и ту же страницу независимо от того, бот это или человек.

Что делать: либо отключать proxied на доменах с активной фильтрацией, либо явно ставить cache rule «не кэшировать этот path», либо использовать Vary: User-Agent и Cache-Control: private. Любой из вариантов работает, главное проверить курлом: 

curl -I -A "facebookexternalhit/1.1" https://your-domain.com/lp
curl -I -A "Mozilla/5.0 (iPhone; ..." https://your-domain.com/lp

Если в обоих случаях Cloudflare отвечает cf-cache-status: HIT с одинаковым ETag — ответ закэширован, и фильтрация по факту не работает.

Ошибка 4. Слишком грубая гео-фильтрация

«Показываем основную страницу только из США» — звучит логично, но бьёт по живым пользователям. Реальные посетители и ревьюеры площадок находятся в разных регионах: Дублин, Манила, Хайдарабад. Если фильтр отрезает всё, кроме одного гео, часть легитимной аудитории видит не ту страницу — а площадка фиксирует несоответствие между объявлением и тем, что реально показывается.

Правильно: фильтровать в две стадии. Первая — явные дата-центры, VPN и Tor режем сразу. Вторая — для региона, не подходящего под оффер, показываем мягкую открытую страницу (нормальный тематический контент, а не пустышку). Так любой реальный посетитель из любого гео видит осмысленную релевантную страницу.

Ошибка 5. Слишком длинный TTL на DNS

Этот пункт технический, но видим его постоянно. Купили домен, поставили A-запись с TTL 86400, начали работать — всё ок. Через две недели хотите подменить инфраструктуру (переехать на другой edge, поменять балансировщик) — и понимаете, что TTL у домена сутки. То есть DNS-провайдеры по всему миру могут ещё 24 часа отдавать старую запись.

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

Правильно: с самого начала ставить TTL = 60–300 секунд на рабочих доменах. Cloudflare и Namecheap позволяют это в один клик. На корпоративном сайте, конечно, ставьте обычный TTL — там короткий не нужен, но для рабочих доменов это базовое правило.

Бонусом: что не ошибки, но многие думают, что да

  • «Менять IP домена каждый день — помогает». Нет, площадки это не отслеживают. Качество и релевантность контента важнее, чем сетевая инфраструктура.
  • «Если креатив одобрили — значит, всё ок навсегда». Не обязательно: алгоритмы пересматривают рекламу спустя несколько дней после запуска, и оценка качества может измениться.
  • «CDN с большим числом IP защитит от проблем». Нет: оценка привязана к домену и контенту, а не к IP.

Что мы делаем в TDS

В TDS.SO фильтрация учитывает все пять пунктов: решение по совокупности сигналов (score), динамический контент открытой страницы, мягкая гео-фильтрация с фоллбэком на нейтральный контент. Цель — отсеивать ботов и нерелевантный трафик с минимумом ложных срабатываний по живым пользователям.

Универсальной настройки «включил и забыл» в этой нише не бывает: у каждого источника своя специфика, а требования площадок периодически меняются. Если хотите разобрать конкретный кейс конфигурации — напишите нам в live-чат, поможем настроить.