ウェブサイト移行のリダイレクトとは#
ウェブサイト移行のリダイレクトは、旧 URL へのリクエストを、その代わりとなるページへ送ります。サイトが新しいドメインに移っても、旧アドレスは消えません。他サイトからのリンク、ブックマーク、メール、印刷物、検索結果は、引き続き旧アドレスを指しています。
リダイレクトがなければ、旧サーバーを停止した時点でこれらのリクエストは失敗します。リダイレクトがあれば、各旧 URL が新しい場所を返し、訪問者は正しいページにたどり着きます。
ドメイン変更時の 301 リダイレクト#
恒久的な移転には 301 リダイレクトを使います。ページが恒久的に移動したことと、その移動先をブラウザと検索エンジンに伝えます。一時的なリダイレクト（302 や 307）は元に戻す予定の移動のためのもので、移行では誤ったシグナルになります。
リダイレクトが機能するのは、旧ドメインに応答するものがある間だけです。旧サーバーを稼働させ続ける代わりに旧ドメインの DNS をリダイレクトサービスに向ければ、旧 URL を HTTPS で応答させたまま、そのサーバーを停止できます。
パスが同じ移行と、URL が変わる移行#
移行には 2 つの形があります。
- 同じパス。 新サイトは URL 構造を維持し、ドメインだけが変わります。ドメイン全体のリダイレクトがすべてのパスとクエリ文字列を引き継ぐため、旧ドメインの /blog/launch は新ドメインの /blog/launch に届きます。
- 変更する URL。 ページの名前変更、統合、再編成があった場合です。各ページについて、旧 URL とそれを置き換える新 URL を、リダイレクトマップに 1 行ずつ記載します。
各ホスト名がどちらに当たるかがわかれば、リダイレクトマップの規模もわかります。
リダイレクトマッピングと移行計画#
リダイレクトマップは、旧 URL とその転送先を 1 行ずつ記載したスプレッドシートです。移行作業の大部分はこのマップ作りです。
- 引き続き機能させる必要がある旧 URL を一覧にします。サイトマップ、アクセス解析、被リンクのレポートに加え、印刷物やメールで配布した URL も確認しましょう。
- それぞれについて、新サイトで最も近い同等のページを選びます。
- マップを、転送元と転送先の列を持つ CSV ファイルとして保存します。
- 書き込まれる前にインポート内容を確認し、エラーのある行を修正します。
- DNS がリダイレクトサービスを指したら、主要な URL を抜き取りで確認し、旧サーバーを停止します。
移行リダイレクトでよくある間違い#
- すべてをトップページに送る。 訪問者は探していたページを見失います。各 URL を最も近い同等のページにリダイレクトしましょう。
- リダイレクトチェーン。 旧 URL が中間の URL を経由して最終ページに届くと、訪問のたびに転送が 1 回増えます。各旧 URL は最終的な転送先へ直接向けましょう。
- 恒久的な移転に一時的なリダイレクトを使う。 移転が恒久的なら、302 ではなく 301 を使います。
- クエリ文字列が失われる。 キャンペーンやトラッキングのパラメーターは、新しい URL まで引き継ぐ必要があります。
- ホスト名の見落とし。 www 版、国別ドメイン、古いサブドメインにもリダイレクトが必要です。
- 旧サーバーを早く止めすぎる。 旧ドメインに対してリダイレクトが応答することを確認してから、旧サーバーを停止しましょう。
よくある質問
移行のその部分については、通常は使いません。RedirHub はホスト名の DNS がこちらを指した時点でそのホスト名に応答するため、移転元のホスト名に適しています。新しいサイトが同じホスト名のままなら、変更したパスのリダイレクトは通常そのサイトのオリジン、CDN、またはサーバーで設定します。移行に伴って古い国別ドメインやレガシーのサブドメインなど他のホスト名も廃止する場合は、それらを RedirHub に向けられます。
変更する URL 1 件が管理リンク 1 件です。パスとクエリを引き継ぐドメイン全体のリダイレクトは、ドメインを 1 件使い、管理リンクは使いません。接続する旧ホスト名はそれぞれドメイン 1 件として数え、ルートドメインは www もカバーします。各プランに含まれる内容は、上のプランカードをご覧ください。
いいえ。新しいドメインでもパスが変わらなければ、ドメイン全体のリダイレクト 1 つですべてカバーできます。パスが変わる場合は、検索流入のあるページ、被リンク、ブックマーク、印刷物やメールで配布したものなど、重要な URL をマッピングします。アクセス解析やクロールのエクスポートが一般的な出発点で、後から別の CSV インポートで URL を追加することもできます。
旧ドメインの DNS を RedirHub に向けます。ダッシュボードには、ホスト名ごとに追加するレコード（CNAME または A レコード）が表示されます。ルートドメイン、または A レコードを使うホスト名では、確認用の TXT レコードも必要です。DNS の変更がすべてのリゾルバーに届くまでには、プロバイダーやレコードの TTL に応じて時間がかかります。DNS が確認されると、RedirHub が HTTPS を自動で準備し、安全な接続の準備ができた時点でリダイレクトを有効にします。主要なリダイレクトの確認が済むまで旧サーバーは稼働させておき、その後に停止しましょう。
インポートの確認では、ファイルとプランをチェックします。転送先の https:// の欠落や不正、未対応のリダイレクトタイプ、プランの容量、重複した www の行を確認し、書き込む前にすべての変更を表示します。転送先のページそのものにはアクセスしません。切り替え後は、無料のリダイレクトチェッカーで重要な旧 URL を抜き取り確認しましょう。
はい。プランは含まれる容量から始まり、拡張できます。Core と Pro では管理リンクの容量を追加できます。確認画面では、インポート前にファイルが使うドメイン数と管理リンク数がわかります。非常に大規模な移行や多数のドメインを伴う移行については、容量やオンボーディングを個別にご提案しますので、営業にご相談ください。
まず 2 つの数字から考えます。移行する旧ホスト名の数と、マッピングする変更 URL の数です。Core と Pro に含まれる内容は上のプランカードのとおりで、Pro ではさらに長期間のアナリティクス履歴が利用できます。どちらのプランも容量を追加できます。料金計算ツールに数字を入力すると料金を確認できます。
旧 URL へのアクセスがある限り維持しましょう。他サイトのリンク、ブックマーク、印刷物は、こちらの都合では期限切れになりません。リダイレクトのアナリティクスで、まだ使われている旧 URL がわかるため、推測ではなく根拠をもってリダイレクトを廃止できます。