Перевірка трафіку: як переконатися, що посилання ведуть на потрібний домен

Що вважати переходом на потрібний домен

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

Перевіряйте не лише ім'я домену, а й його варіант: 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, лендингу або правил редиректу перевіряйте і нові, і старі посилання. Старі описи стрімів, ролики та закріплені пости можуть продовжувати приводити аудиторію на застарілий маршрут.