リダイレクトは、古いURLへ来た利用者を新しいURLへ自動で案内する仕組みです。サイト移転で住所が変わったときや、HTTPをHTTPSへ統一するときに使います。同じURLのままサーバーだけを移すなら、通常は移転用のリダイレクトは不要です。

恒久的にページを移す場合は301、一時的な移動なら302が基本の選択肢です。旧会社案内から新会社案内へ、というように内容が対応するページへ転送します。すべてをトップページへ送ると、目的の情報へたどり着きにくくなります。

内容が対応するページへ転送する

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

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

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

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

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

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

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

状態コード移転の意味メソッドの扱いで見る点
301恒久的な移転POSTがGETへ変わる場合がある
302一時的な移転POSTがGETへ変わる場合がある
307一時的な移転元のメソッドを維持する
308恒久的な移転元のメソッドを維持する

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

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

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

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

たとえばApacheでmod_aliasの設定が許可されている環境なら、単一ページの恒久転送は次のように表せます。実際のドメインとパスへ置き換える例です。

RedirectMatch 301 ^/old-page\.html$ https://example.jp/new-page/

この例はパスが/old-page.htmlと一致したときの転送で、通常のページ閲覧を想定しています。コード自体にGETだけを許す条件やクエリの判定はないため、フォームやAPIのURLにはそのまま使わないでください。構文はApacheのmod_alias資料を参照できます。

設定場所と適用範囲は、WebサーバーやCMSの構成によって異なります。既存の設定を保存してから、テスト環境か影響を限定したURLで試すと、WordPressやCDNの転送ルールとの競合も見つけやすくなります。

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を見つけられます。

Googleのサイト移転ガイドでは、転送を少なくとも1年間維持するよう勧めています。それ以降も、ブックマークや印刷物から古いURLへ来る人がいるなら、残す意味があります。旧ドメインへのHTTPS接続も受け続ける場合は、ドメインと証明書の維持費用も移転後の費用に含まれます。