トラフィック検証：リンクが正しいドメインに誘導しているか確認する方法

正しいドメインへの遷移とは何か

トラフィックが正しいドメインに届いているとは、ユーザーがすべてのリダイレクトを経て、目的のホスト上のページを開いた状態を指します。配信の説明欄やプロフィール、広告に貼ったアドレスを確認するだけでは不十分です。リンクは短縮サービス、トラッカー、旧ドメイン、中間ランディングページ、ジオリダイレクトを経由している可能性があります。

ドメイン名だけでなく、そのバリエーションも確認してください。wwwあり・なし、HTTP・HTTPS、メインドメインとサブドメインなどです。site.example、www.site.example、promo.site.example は同じプロジェクトのものでも、ブラウザ、アナリティクス、ログにとっては別々のホストです。

オーディエンスと同じ方法でリンクを開く

実際に掲載されている場所からリンクを開いてください。配信の説明欄、プロフィール、固定メッセージ、投稿、広告などです。ページの読み込み後、アドレスバーを確認します。重要なのは、投稿に記載された元のアドレスではなく、ブラウザに残ったURLです。

• 最終ホストをランディングページのドメインと照合する。
• パスを確認する：リンクが正しいドメインでも、古いセクションに誘導している可能性がある。
• モバイルからの遷移が技術的なサブドメインに飛んでいないか確認する。
• UTMパラメータ付きとなしのリンクで結果を比較する。
• すべての遷移後もキャンペーンパラメータが保持されているか確認する。

手動確認の欠点：自分のブラウザ、デバイス、地域、Cookieのセットという1つのシナリオしか示しません。オーディエンスの一部には異なるルールが適用される可能性があります。

ブラウザとcurlでリダイレクトチェーン全体を確認する

技術的な確認には、-I と -L パラメータを付けたcurlを使用します。コマンドはレスポンスヘッダーを表示し、リダイレクトをたどります。301、302、307、308のステータスとLocationヘッダーを探してください。これらは各ステップでサーバーがユーザーをどのアドレスに誘導しているかを示します。

実際のブラウザで確認するには、開発者ツールを開き、Networkタブに移動してPreserve logを有効にします。その後、元のリンクを開きます。リクエスト一覧にはリダイレクト、最終ドキュメント、ページ読み込み後に実行されるリクエストが表示されます。

1. リダイレクト後にリストがクリアされないよう、Preserve logを有効にする。
2. 必要に応じてブラウザのキャッシュを無効にする。
3. 投稿から元のリンクを開くか、新しいタブに貼り付ける。
4. 3xxステータスのレスポンスを見つける。
5. 各ステップのRequest URLをLocationの値と照合する。
6. ステータス200の最後のドキュメントのドメインとURLを確認する。

チェーン内の旧ドメインが正常な場合とエラーの場合

チェーン内の旧ドメインは必ずしも問題を意味しません。移転後は 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の値、アドレスバーの最終文字列を比較します。これにより、どのステップでリダイレクトルールがパラメータを破棄したかを特定できます。

すべてのパラメータを検証なしで渡す欠点：余分な内部的な値が目的のドメインに到達する可能性があります。重要なリンクでは、どのパラメータ、プロモコード、アフィリエイトパラメータを保持すべきかを事前に定義しておくべきです。

アプリのアプリ内ブラウザで確認する

SNS、メッセンジャー、ストリーミングプラットフォームは、デバイスのメインブラウザではなくアプリ内ブラウザでリンクを開くことがよくあります。そのようなブラウザは異なるuser-agentを送信したり、スクリプトを制限したり、Cookieを保存しなかったり、リダイレクトを別の方法で処理したりする可能性があります。

リンクが掲載されているプラットフォームのアプリから直接リンクを開いてください。その後、「ブラウザで開く」オプションがあればそれを使ってテストを繰り返します。最終ドメイン、パス、UTMパラメータ、フォーム、決済、認証の動作を比較してください。

アプリ内ブラウザでの確認の欠点：すべてのアプリで技術的なリクエストチェーンを確認できるわけではありません。それでも重要です。モバイルオーディエンスはまさにこの方法で遷移することが多いからです。

異なる地域や条件からの遷移を比較する

サイトがジオリダイレクト、CDN、異なるバージョンのランディングページを使用している場合は、VPN、プロキシ、または対象地域のリモートデバイスを使って確認を繰り返してください。最終ドメイン、パス、URLパラメータ、ランディングページの内容を比較します。

国だけでなく、ブラウザの言語、認証状態、Cookie、デバイスタイプも確認してください。これらの条件がルートに影響する可能性があります。たとえば、ある地域のユーザーはローカルサブドメインに送られ、Cookieのない訪問者は共通のランディングページに送られる場合があります。

VPNとプロキシの欠点：実際の視聴者の条件を完全に再現できるわけではありません。地理位置情報は複数のシグナルで判定されることがあるため、このテストは問題の可能性を確認できますが、オーディエンス全体をカバーするものではありません。

Yandex MetricaとGA4でドメインを確認する

Yandex Metricaでは、入口ページとページURLのレポートを確認します。完全なアドレスまたは目的のドメインでデータをフィルタリングし、UTMパラメータ、ソース、キャンペーンでセグメントを追加します。これにより、特定の掲載後にどのホストでビジットが始まったかを確認できます。

GA4では、この確認にHostnameディメンションをランディングページ、セッションソース、キャンペーンと組み合わせて使用します。メインドメイン、旧アドレス、重要なサブドメインにそれぞれ何セッション届いたかを比較します。タグが複数のホストに設置されている場合、レポートはトラフィックの混在をすぐに示します。

アナリティクスの欠点：ブロッカー、JavaScriptの無効化、タグ読み込み前のページ閉鎖により、一部のビジットはカウントされません。また、カウンターがまったく設置されていないドメインについてはデータが役に立ちません。

サーバーログのリクエストを確認する

サーバーログは、どのリクエストが実際にサイトのインフラに到達したかを確認できます。確認には、時刻、Host、URL、レスポンスコード、user-agent、送信される場合はrefererのフィールドが必要です。リンクの起動期間中のリクエストを探し、旧ドメインと目的のドメインへのリクエストを別々に確認します。

301、302、307、308のレスポンスは、サーバーがユーザーをリダイレクトしたことを示します。目的のホストへのステータス200のリクエストは、ページが正しいドメインから配信されたことを確認します。ログに旧ホストへの遷移があるのに新しいホストへのリクエストがない場合は、リダイレクトルールと接続エラーの可能性を確認してください。

ログの欠点：ボット、スキャナー、技術的なリクエストも含まれます。アプリやメッセンジャーからの遷移ではrefererが欠けていることが多く、特定のビジットのソースを常に復元できるわけではありません。

レポートでメインドメインとサブドメインを分ける

ランディングページ、マイページ、決済、ナレッジベースは異なるサブドメインにある場合があります。セグメントなしで1つのレポートにまとめると、配信からのリンクがメインサイトではなく promo.site.example に誘導していることや、オファーを見る前に checkout.site.example に誘導していることに気づかない可能性があります。

目的のホスト用の個別セグメントを作成し、プロジェクトの全ドメインの総合レポートも残しておきます。前者はランディングトラフィックの管理に、後者はランディングページ、決済、マイページ間のユーザーの経路を把握するのに役立ちます。

厳しすぎるフィルタリングの欠点：サブドメイン間の正常な遷移がレポートから消え、ファネルが途切れて見える可能性があります。

掲載前のリンク確認チェックリスト

• オーディエンスが見る場所からリンクを開く。
• アドレスバーの最終ドメイン、パス、パラメータを確認する。
• curlまたはNetworkで3xxチェーンとLocationヘッダーを確認する。
• 旧ドメインがリダイレクト時にパスとUTMパラメータを保持していることを確認する。
• アプリのアプリ内ブラウザで遷移を繰り返す。
• ジオルールを使用している場合は別の地域で確認する。
• 起動後にアナリティクスのHostnameとランディングページを照合する。
• サーバーログで目的のホストへのリクエストを確認する。

ドメイン、CDN、ランディングページ、リダイレクトルールを変更した後は、新しいリンクと古いリンクの両方を確認してください。 古い配信の説明欄、動画、固定投稿は、引き続きオーディエンスを古いルートに誘導している可能性があります。