Проверка трафика: как убедиться, что ссылки ведут на нужный домен

Что считать переходом на нужный домен

Трафик приходит на нужный домен, когда пользователь после всех перенаправлений открывает страницу на целевом хосте. Недостаточно проверить адрес, вставленный в описание стрима, профиль или рекламу: ссылка может пройти через сокращатель, трекер, старый домен, промежуточный лендинг или георедирект.

Проверяйте не только имя домена, но и его вариант: www и без www, HTTP и HTTPS, основной домен и поддомен. Адреса site.example, www.site.example и promo.site.example могут относиться к одному проекту, но для браузера, аналитики и логов это разные хосты.

Откройте ссылку так, как её открывает аудитория

Переходите по ссылке из реального места размещения: из описания трансляции, профиля, закреплённого сообщения, поста или объявления. После загрузки страницы проверьте адресную строку. Важен URL, который остался в браузере, а не исходный адрес из публикации.

• Сверьте конечный хост с доменом посадочной страницы.
• Проверьте путь: ссылка может вести на правильный домен, но на устаревший раздел.
• Убедитесь, что мобильный переход не уходит на технический поддомен.
• Сравните результат для ссылки с UTM-метками и без них.
• Проверьте, сохранились ли параметры кампании после всех переходов.

Недостаток ручной проверки: она показывает один сценарий — ваш браузер, устройство, регион и набор cookies. Для части аудитории правила могут работать иначе.

Проверьте всю цепочку редиректов в браузере и через curl

Для технической проверки используйте curl с параметрами -I и -L: команда покажет заголовки ответов и пройдёт по перенаправлениям. Ищите статусы 301, 302, 307, 308 и заголовки Location. Они показывают, на какой адрес сервер направляет пользователя на каждом шаге.

Для проверки в реальном браузере откройте инструменты разработчика, перейдите во вкладку Network и включите Preserve log. Затем откройте исходную ссылку. В списке запросов видны редиректы, конечный документ и запросы, которые выполняются уже после загрузки страницы.

1. Включите Preserve log, чтобы список не очистился после перенаправления.
2. При необходимости отключите кэш браузера.
3. Откройте исходную ссылку из публикации или вставьте её в новую вкладку.
4. Найдите ответы со статусами 3xx.
5. Сверьте Request URL каждого шага со значением Location.
6. Проверьте домен и URL последнего документа со статусом 200.

Когда старый домен в цепочке нормален, а когда это ошибка

Старый домен в цепочке не всегда означает проблему. После переезда нормален маршрут вида old-site.example/stream → site.example/stream: старый адрес принимает запрос и постоянно перенаправляет пользователя на эквивалентную страницу нового сайта. Конечный домен правильный, путь сохранён, а UTM-метки не исчезли.

Баг — ситуация, когда old-site.example/stream ведёт на главную нового сайта, на другой лендинг или оставляет пользователя на старом домене. Отдельная проблема возникает, если после редиректа пропадает строка после знака вопроса: пользователь попадает на нужную страницу, но аналитика теряет utm_source, utm_medium и utm_campaign.

Проверяйте не только последний домен, но и путь с параметрами. Переход на site.example без нужной страницы или меток может исказить данные кампании так же сильно, как переход на чужой хост.

Учитывайте JavaScript-редиректы и параметры ссылки

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

В Network проверьте не только основной документ, но и момент изменения адреса после его загрузки. Если UTM-метки пропали, сравните исходный URL, значение Location и конечную строку в адресной строке. Так можно понять, на каком шаге правило редиректа отбросило параметры.

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

Проверьте встроенные браузеры приложений

Соцсети, мессенджеры и стриминговые площадки часто открывают ссылку не в основном браузере устройства, а во встроенном. Такой браузер может передавать другой user-agent, ограничивать скрипты, не сохранять cookies или иначе обрабатывать редиректы.

Откройте ссылку прямо из приложения площадки, где она размещена. Затем повторите тест через пункт «Открыть в браузере», если он доступен. Сравните конечный домен, путь, UTM-метки и поведение формы, оплаты или авторизации.

Недостаток проверки во встроенном браузере: не все приложения позволяют посмотреть техническую цепочку запросов. Она всё равно важна, потому что именно так часто переходит мобильная аудитория.

Сравните переходы из разных регионов и условий

Если сайт использует георедиректы, CDN или разные версии лендингов, повторите проверку через VPN, прокси или удалённое устройство в нужном регионе. Сравнивайте конечный домен, путь, параметры URL и содержимое посадочной страницы.

Проверяйте не только страну, но и язык браузера, авторизацию, cookies и тип устройства. Эти условия могут влиять на маршрут: например, пользователя из одного региона отправляют на локальный поддомен, а посетителя без cookies — на общий лендинг.

Недостаток VPN и прокси: они не всегда полностью воспроизводят условия реального зрителя. Геолокацию могут определять по нескольким сигналам, поэтому такой тест подтверждает возможную проблему, но не покрывает всю аудиторию.

Подтвердите домен в Яндекс Метрике и GA4

В Яндекс Метрике смотрите отчёты по страницам входа и URL страниц. Отфильтруйте данные по полному адресу или нужному домену, затем добавьте сегмент по UTM-метке, источнику или кампании. Так можно увидеть, на каком хосте начались визиты после конкретного размещения.

В GA4 для такой проверки используйте измерение Hostname вместе с посадочной страницей, источником сеанса и кампанией. Сравните, сколько сессий пришло на основной домен, старый адрес и важные поддомены. Если тег установлен на нескольких хостах, отчёт быстро показывает смешение трафика.

Недостаток аналитики: счётчики не фиксируют часть визитов из-за блокировщиков, отключённого JavaScript или закрытия страницы до загрузки тега. Также данные не помогут по домену, где счётчик вообще не установлен.

Проверьте обращения в серверных логах

Серверные логи подтверждают, какие запросы реально дошли до инфраструктуры сайта. Для проверки нужны поля с временем, Host, URL, кодом ответа, user-agent и referer, если он передаётся. Ищите обращения в период запуска ссылки и отдельно смотрите запросы к старому и целевому доменам.

Ответы 301, 302, 307 и 308 покажут, что сервер перенаправил пользователя. Запросы со статусом 200 к целевому хосту подтвердят, что страница была отдана с нужного домена. Если в логах есть переходы на старый хост, но нет запросов к новому, проверяйте правила редиректа и возможные ошибки соединения.

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

Разделите основной домен и поддомены в отчётах

Лендинг, личный кабинет, оплата и база знаний могут находиться на разных поддоменах. Если собирать их в одном отчёте без сегментов, можно не заметить, что ссылка из стрима ведёт на promo.site.example вместо основного сайта или на checkout.site.example до знакомства с предложением.

Создайте отдельный сегмент для целевого хоста и оставьте общий отчёт по всем доменам проекта. Первый поможет контролировать посадочный трафик, второй — видеть путь пользователя между лендингом, оплатой и личным кабинетом.

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

Чек-лист проверки ссылки перед размещением

• Открыть ссылку из места, где её увидит аудитория.
• Проверить конечный домен, путь и параметры в адресной строке.
• Посмотреть цепочку 3xx и заголовки Location через curl или Network.
• Убедиться, что старый домен сохраняет путь и UTM-метки при редиректе.
• Повторить переход во встроенном браузере приложения.
• Проверить другой регион, если используются геоправила.
• Сверить Hostname и посадочные страницы в аналитике после запуска.
• Подтвердить обращения к нужному хосту по серверным логам.

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