リダイレクト設定の基礎とサイト移転時の使い方

サイト移転のリダイレクトは、古いURLを新しいトップページへ送るだけの設定ではありません。利用者が見ようとしたページの意図を、移転先の対応するページへ引き継ぐ仕組みです。行き先が雑であれば、転送自体は成功しても利用者は情報へたどり着けません。

設定を始める前に、旧URLと新URLの対応表を作ります。移転が恒久的か一時的かを決め、GET以外の通信があるか確認します。この設計ができていれば、サーバーやCMSが変わっても、必要な転送ルールと確認方法を整理できます。

最初に旧URLと新URLの対応表を作る

旧サイトのURLは、サイトマップ・アクセス解析・サーバーログから集めます。検索結果と社内資料も手がかりになります。

閲覧数の多いページだけでなく、広告やメールから直接開かれるページも対象です。PDF・採用情報・問い合わせ完了ページも含めます。画面のリンクをたどるだけでは、現在のサイト内から外れた古いURLを見落とします。

各URLには、内容が同等の新ページを一つずつ対応させます。商品ページなら後継商品、移転した会社案内なら新しい会社案内へ送ります。廃止したサービスをすべてトップページへ転送すると、利用者は探していた情報が消えたのか、転送設定を間違えたのか判断できません。代替がなければ、廃止理由や次の選択肢を説明するページを用意する方が親切です。

URLのパスを機械的に引き継げる部分と、個別に対応付ける部分を分けます。カテゴリー構造を変更した移転では、同じ末尾名でも意味が違う場合があります。クエリ文字列も、新サイトが同じ絞り込み条件として使えるときだけ引き継ぎます。対応表には担当者と確認状況も持たせると、公開直前の転送漏れを追いやすくなります。

状態コードは期間と通信方法で選ぶ

HTTPのリダイレクトは3xxの応答とLocationヘッダーで行き先を伝えます。RFC 9110では、301は恒久的、302は一時的な転送を表します。一方、301と302は、POSTのリクエストが転送時にGETへ変わる場合があります。ページ閲覧だけを想定した選び方を、フォームやAPIへそのまま当てはめることはできません。

307は一時的な転送で、リクエストメソッドを維持します。RFC 7538で定められた308は、メソッドを維持する恒久的な転送です。ただし、POSTを維持すれば安全になるわけではありません。転送先が同じ入力を受け取り、二重送信や意図しない処理を起こさないことを個別に試す必要があります。

通常のページ閲覧を恒久移転するなら301が一般的な選択肢になりますが、移転期間と通信方法から判断することが先です。一時的なメンテナンス、キャンペーン中だけの差し替え、フォームやAPIでは要件が異なります。検索エンジンへの合図だけでコードを選ばず、利用者のリクエストをどの形で引き継ぐかまで考えます。

設定する場所を一つに寄せる

リダイレクトはCDN・ロードバランサー・Webサーバー・CMS・プラグインで設定できます。移転ルールを各層へ分散すると、どれが先に動くか分かりにくくなり、wwwの有無やHTTPSへの統一が互いを呼び戻してループすることがあります。基本の移転ルールは、管理責任を持てる一つの層へ寄せます。

一回の転送で最終URLへ到達する設計が理想です。HTTPS化・ドメイン移転・末尾スラッシュの統一を別々に積み重ねると、複数回の転送が発生します。各条件を整理し、旧URLから正規の新URLへ直接送れるか確認します。例外ルールを一般ルールより先に評価するかなど、適用順も記録します。

設定例をそのまま貼り付ける方法は避けます。Webサーバーの種類、CMS、ディレクトリ構成によって記法と適用範囲が異なるためです。変更前の設定を保存し、テスト環境か影響を限定したURLで動作を確かめてから広げます。転送先をクエリから受け取る仕組みでは、外部の任意URLへ送れないよう入力も制限します。

HTTPSの旧URLには旧側の証明書も必要になる

旧ドメインのHTTPS URLへ接続した利用者は、リダイレクトを受け取る前にTLS接続を行います。旧側の証明書が失効していれば、ブラウザーは転送先へ進む前に警告を出します。「新サイトは正常だから旧証明書は不要」と考えると、ブックマークや検索結果から来た利用者を新サイトへ案内できません。

旧ホスト名を受けるサーバーと有効な証明書を維持し、その上で新URLへのリダイレクトを返します。非wwwとwwwの両方が使われていたなら、DNS・証明書・転送を両方で確認します。DNSの切り替えだけでは、URLのパスや利用者の意図を新サイトへ渡せません。

移転公開時にDNS・証明書・リダイレクトを無記録で変えると、失敗した場所が分からなくなります。警告なのか接続不能なのか、転送間違いなのかも区別できません。新側が旧ホスト名を受けられる状態を先に作ります。次に証明書と転送ルールを準備し、切り替え前後の応答を保存します。

本番確認は深いURLと失敗例まで含める

ブラウザーでトップページを一度開くだけでは、リダイレクトの検証になりません。HTTPの応答ヘッダーを確認し、状態コードとLocationが対応表どおりかを見ます。キャッシュ済みの恒久転送に影響されない方法でも試します。旧サイトの深いページ・クエリ付きURL・PDF・存在しないURLをサンプルとして確認します。

フォームやAPIがある場合は、GETのページとは分けてテストします。メソッド・本文・認証情報が想定どおり扱われるか確認します。

転送先で二重処理が起きないことも必要です。ループだけでなく、複数回の転送も異常として扱います。外部の無関係なURLへの転送や、すべてがトップへ着地する設定も同様です。

公開後は古い入口が残っている間の責任を持つ

公開後は、新サイト内のリンク・canonical・サイトマップを新URLへ更新します。広告・メールテンプレート・社内文書も対象です。リダイレクトがあるから古いリンクを残してよいわけではありません。転送ログと404をしばらく確認すると、対応表から漏れた旧URLや外部から参照され続けるURLを見つけられます。

転送ルールをいつまで維持するかは、固定の日数では決められません。契約・顧客のブックマーク・外部リンク・印刷物を調べます。

業務システムの依存も確認して判断します。旧ドメインと証明書の更新責任も含めて記録し、廃止するときは関係部署と影響を再確認します。移転は新サイトの公開日で終わらず、古い入口から迷わず到達できる状態を維持するところまで続きます。