パスとUTMを保持してドメインを転送する方法

パスとクエリ文字列を保持してドメインを転送するには、ホスト名だけでなくリクエストURI全体を新しいドメインへ渡す必要があります。たとえば、次のようなURLです。

old-brand.com/pricing?plan=pro&utm_source=email

これは次のURLに到達するべきです。

new-brand.com/pricing?plan=pro&utm_source=email

転送設定がルートドメインだけを新しいトップページへ送る場合、ユーザーが開こうとしたパスやUTMが失われます。結果として、広告キャンペーン、商品ページ、ディープリンク、ドキュメントURLが壊れ、移行で守りたかった検索流入まで失いやすくなります。

大きなサイト移行の一部として進める場合は、まずサイト移行前のリダイレクトチェックリストでURL棚卸しと検証手順を固めてから、この実装に戻ると安全です。

「パスとクエリ文字列を保持する」の実際の意味

ドメイン転送が必要だとチームが言うとき、その意味は大きく異なる場合があります。

基本的なホストオンリー転送

すべてのリクエストは 1 つの新しいホームページに送信されます。

old-brand.com/* -> new-brand.com/

これは単純ですが、コンテキストを無視します。

パス維持転送

ドメイン名を変えても、後続パスをそのまま引き継ぎます。

old-brand.com/blog/post-1 -> new-brand.com/blog/post-1

これは、ほとんどのサイト移行で実際に必要なものです。

クエリ保持転送

キャンペーンと追跡パラメーターはそのまま残ります。

old-brand.com/pricing?utm_source=x -> new-brand.com/pricing?utm_source=x

これがないと、キャンペーン分析とアトリビューションが信頼できなくなることがよくあります。

キャンペーンパラメーターが重要であることがすでにわかっている場合は、直前の QA ノートではなく、リダイレクト仕様の一部にします。

DNS だけでは不十分な理由

これは、最もよく混乱する点の 1 つです。

DNS レコード (CNAME レコードや A レコードなど) は、インターネット トラフィックの送信先を伝えます。これらは、それ自体ではブラウザーに対して HTTP 301 または 302 リダイレクトを発行しません。

ユーザーとクローラが別の URL に到達できるようにしたい場合は、以下を返す HTTP リダイレクトレイヤーが必要です。

正しいステータスコード
正しい宛先
オプションのパス転送
オプションのクエリパラメータ処理

だからこそ、ドメイン転送は単なる DNS タスクではありません。ルーティングのタスクです。

変更が永続的であるか一時的であるかをまだ判断していない場合は、ルールを有効に設定する前に、301 vs 302 vs 307 vs 308 リダイレクトをお読みください。

実際のドメイン移行の最も安全なパターン

ほとんどの移行では、最適なベースラインは次のとおりです。

最終的な正規ホスト名を選択します
HTTPSを強制する
すべての意味のある古いパスを新しい同等のパスに転送します
重要なクエリパラメータを保持します
ホップ数を 1 に保ちます

例:

http://old-brand.com/docs/api?ref=partner
  -> https://new-brand.com/docs/api?ref=partner

これは以下よりもはるかに優れています。

http://old-brand.com/docs/api
  -> https://old-brand.com/docs/api
  -> https://www.new-brand.com/docs/api
  -> https://new-brand.com/docs/api

パスの保存が最も重要な場合

サイトの移行

新しいドメインに移動する場合、またはサイトのプラットフォームを再構築する場合、パス構造を保持すると、古いバックリンクとインデックス付き URL が役に立ちます。

ドキュメントとナレッジベース

Docs ユーザーが最初にホームページにアクセスすることはほとんどありません。彼らは特定の記事にたどり着きます。 / ですべてのリクエストをドロップすると、そのエクスペリエンスが破壊されます。

有料キャンペーン

ユーザーが 5 つのトラッキングパラメータを含む広告をクリックし、リダイレクトによってそれらのパラメータが削除された場合、レポートの信頼性は直ちに低下します。

ソーシャルバイオと短いリンク

ブランドリンクの多くは、実際には小さなルーティングルールです。ターゲットパスが失われると、リンク戦略の明確性も失われます。

クリーンなワイルドカード転送モデル

最も単純なメンタルモデルは次のとおりです。

source:      old-brand.com/*
destination: new-brand.com/$1

つまり、次のようになります。

スラッシュの後のすべてを取得します
宛先パスに挿入します。
リクエストの形を維持します

例:

リクエスト	目的地
`/about`	`/about`
`/blog/post-1`	`/blog/post-1`
`/pricing/enterprise`	`/pricing/enterprise`

クエリ文字列も保持する場合は、次のようになります。

/pricing/enterprise?utm_source=partner

次のまま残ります:

/pricing/enterprise?utm_source=partner

現在の転送プランで最終ページの前に 2 つまたは 3 つのホップが生成されている場合は、公開前に修正してください。リダイレクトチェーンとループのガイドで確認ポイントを整理しています。

ほとんどの転送ミスを防ぐ 4 つのチェック

1. 最初に宛先ホスト名を確認します。

最後のホストを 1 つ選択します。

new-brand.com
または www.new-brand.com

移行の途中でそれを理解しようとしないでください。そうやって連鎖が起こるのです。

2. ステータスコードを決定する

移動が永続的な場合は、301 などの永続的なコードを使用します。

一時的な場合は、302 などの一時的なコードを使用します。

復習が必要な場合は、301 vs 302 vs 307 vs 308 リダイレクトを参照してください。

3. クエリ処理について明示的にする

すべてのプロバイダーがクエリ文字列を自動的に保持すると想定しないでください。テストしてみましょう。

実際の例を使用します。

curl -I 'https://old-brand.com/pricing?plan=pro&utm_source=email'

次に、Location ヘッダーに予想されるパスとパラメーターが含まれていることを確認します。

4. ルート URL とディープ URL の両方をテストする

多くのリダイレクトは / では機能しますが、次のようなより深いページでは失敗します。

/docs/api
/blog/post-slug
/pricing/enterprise
/old-category/product-123

HTTPS と SSL はリダイレクトの一部です

最悪の移行結果の 1 つは次のとおりです。

リダイレクトは技術的に正しいです
ただし、古いドメインは HTTPS を適切に終了しません
リダイレクトが発生する前に、ユーザーには依然として証明書またはセキュリティの問題が表示されます。

だからこそ、自動化された SSL が重要なのです。リダイレクトフローは、ルーティングロジックが実行する完全な機会をすでに得た後ではなく、最初のリクエストから始まります。

管理オプションが必要な場合、UrlEdge 無料URL転送には、自動 HTTPS およびワイルドカード転送のサポートが含まれています。

よくある転送の間違い

ホームページのみをリダイレクトする

これは典型的な「ホームページで動作します」という起動ミスです。実際のユーザーは / だけを訪問するわけではありません。

非 www およびルートドメインの動作を忘れる

次のことをよく考える必要があります。

old-brand.com
www.old-brand.com
スコープ内にある場合はサブドメイン

キャンペーンパラメータの削除

SEO が問題なくても、アトリビューションデータは一夜にして信頼できなくなる可能性があります。

複数のホップの作成

リクエストが最初に 2 つまたは 3 つの中間ホストを経由してバウンスされる場合、パス転送は多くの価値を失います。

HTTP ルールと HTTPS ルールを不用意に混合する

古いホストが HTTPS を正しく処理できない場合、ユーザーは宛先を表示する前にセキュリティエラーに遭遇する可能性があります。

実践的な UrlEdge セットアップパターン

一般的な永続的な移行の場合:

古いドメインに接続する
HTTPSを有効にする
ワイルドカードリダイレクトルールを作成する
パスを保持する
必要なクエリパラメータを保持する
リダイレクトチェッカーでトップページをテストする

これは、Nginx、Apache、またはアプリミドルウェア内のルーティングロジックを再構築せずに、ノーコードまたはローコードの移行パスが必要な場合に特に便利です。

よくある質問

ネイキッドドメインをリダイレクトしてパスを維持できますか?

はい、リダイレクトレイヤーがルートドメイン転送とパス保持をサポートしている限り可能です。これは非常に一般的な移行セットアップです。

クエリ文字列は常に保持する必要がありますか?

常にではありませんが、意図的に判断する必要があります。重要なトラッキング、キャンペーン、機能パラメータは保持します。不要なパラメータは、役に立たないと確信できる場合にのみ削除してください。

ワイルドカード転送はすべての移行に十分ですか?

いいえ。一部の移行では、名前を変更したパスに対して 1 対 1 のマッピングが必要です。ワイルドカードは、パス構造がほとんど変更されていない場合に最適です。

全員の DNS を変更する前にこれをテストできますか?

はい。最初にステージングホストまたは制御されたホストでテストしてから、完全なカットオーバーの前にパスの実際のサンプルを検証する必要があります。

無料で構築を開始

ドキュメント