最初に「転送する理由」と終了条件を決める
リダイレクトはURL変更を利用者とクライアントへ伝える仕組みで、アクセス制御や侵害対策ではありません。目的が曖昧なまま規則を追加すると、無関係なページへの誤転送、循環、原因不明のキャッシュが残ります。
恒久的な移転
ページ統合、ドメイン変更、HTTPからHTTPS、正規URL変更など、旧URLへ戻さない場合です。同等の最終URLへ永続転送し、内部リンクやcanonicalも更新します。
一時的な退避
短期間のメンテナンス、地域・在庫による一時表示など、元URLを再び使う場合です。終了日、解除担当、監視を決めます。
送信後の別ページ参照
フォーム送信後に完了ページをGETで表示させる場合は303を検討します。二重送信を避ける設計と、成功・失敗時の挙動を確認します。
削除して代替がない
内容が対応しないトップページへ一括転送せず、404または410を返します。転送先が利用者の目的を満たす場合だけ対応付けます。
会員、権限、障害、端末判定を隠す目的で3xxを重ねないでください。認証は401・403、存在しない資源は404・410、過負荷や保守は適切な5xxと案内を含めて別に設計します。
301・302・303・307・308は期間とメソッドで選ぶ
永続か一時かに加え、転送後も同じHTTPメソッドと本文を送る必要があるかを確認します。ブラウザ画面だけでなく、API、Webhook、決済、ログインも対象です。
表は横にスクロールできます。
| コード | 意味 | メソッド | 代表的な用途 | 確認点 |
|---|---|---|---|---|
| 301 | 恒久的な移転 | POSTがGETへ変わる実装がある | 通常ページの恒久URL変更 | キャッシュ、検索信号、旧URLへの復帰予定 |
| 302 | 一時的な移転 | POSTがGETへ変わる実装がある | 元URLへ戻す一時表示 | 解除日、元URLを正規として維持するか |
| 303 | 別の資源を参照 | 転送先をGETまたはHEADで取得 | POST成功後の完了ページ | 二重送信、失敗時の再送、結果URL |
| 307 | 一時的な移転 | メソッドと本文を維持 | 一時的なAPI・送信先変更 | 認証、署名、本文、クライアント対応 |
| 308 | 恒久的な移転 | メソッドと本文を維持 | 恒久的なAPI・送信先変更 | 長期キャッシュ、全クライアントの実測 |
307は302より「安全」という意味ではない
307と308の特徴は、転送時にメソッドと本文を維持することです。機密性、認証、権限、入力検証を強化する状態コードではありません。機密データを別ホストへ送る場合は、転送先、TLS、認証情報、Cookie、CORS、ログを別に確認します。
旧URLと最終URLを一対一で対応付ける
実装前にURL対応表を作り、転送元、最終URL、状態コード、クエリ、例外、担当、終了条件を記録します。同じ内容に最も近いURLへ直接つなぎます。
完全一致を先にする
個別移転、廃止ページ、API、ファイル、管理画面の例外を先に評価し、その後にディレクトリやホスト全体の規則を適用します。
パスとクエリを明示する
パスを維持するか、末尾スラッシュや大文字小文字を正規化するか、業務パラメーターを残すかを列ごとに決めます。計測用パラメーターも無条件に削除しません。
一段で最終URLへ送る
A→B→CではなくA→Cにします。HTTP、www、末尾スラッシュ、旧パスを一度に正規化し、既存の古い規則も最終URLへ更新します。
代替がなければ転送しない
削除された記事を無関係なカテゴリやトップへ集約しません。利用者が同じ目的を達成できる資源がない場合は404・410と案内を返します。
URL対応表の最小列
転送元URL｜最終URLまたは404/410｜状態コード｜メソッド維持｜クエリ方針｜例外｜確認担当｜有効化日時｜解除条件｜検証結果
ループとチェーンは責任層・規則順・転送グラフで防ぐ
CDN、ロードバランサー、Webサーバー、CMS、アプリがそれぞれ転送すると、利用者から見えない条件が循環します。正規化を担当する層を一つ決め、入口から最終応答までを記録します。
- 1
転送の所有者を一つにする
どの層がスキーム、ホスト、パスを正規化するか決めます。他の層は同じ判断を重複させず、設定一覧に責任境界を残します。
- 2
例外を広い規則より先に置く
ACME検証、ヘルスチェック、管理用経路、Webhookなど必要な例外を先に評価します。例外を公開してよいか、認証が必要かも確認します。
- 3
TLS終端後のスキーム認識を確認する
プロキシでTLSを終端すると、背後のサーバーはHTTPと認識する場合があります。X-Forwarded-Protoなどは、信頼するプロキシが外部値を破棄して設定する構成に限って使います。
- 4
転送元と転送先をグラフで検査する
各URLを頂点、Locationを辺として、自己参照、A→B→A、複数ホップを検出します。代表URLだけでなく全対応表へ実行します。
- 5
正規URLを一つに揃える
リダイレクト先、内部リンク、canonical、hreflang、サイトマップ、構造化データのURLを同じ最終URLへ揃えます。相反する信号を残しません。
設定は専用の入口で、狭い条件から実装する
設定例をそのまま貼り付けず、ホスト、TLS終端、既存規則、パス、クエリ、アプリの基準URLに合わせます。構文検査、設定差分、再読み込み、即時復旧のコマンドを変更票へ残します。
Apache HTTP Server
単純なURL転送はmod_aliasのRedirectを優先し、条件が必要な場合だけmod_rewriteを使います。HTTP専用VirtualHostから最終HTTPS URLへ送り、プロキシ配下では信頼済み転送情報を使います。
Redirect permanent /old/ https://example.com/new/
NGINX
単純な転送はserverまたはlocationでreturnを使い、正規表現rewriteを増やしすぎません。server_nameの一致、URIと引数の扱い、既存locationの優先順位を確認します。
return 308 https://example.com$request_uri;
CDN・ロードバランサー
エッジで完結させるなら、アプリ側の同等規則を外します。ホストヘッダー、転送プロトコル、キャッシュキー、地域規則、障害時のバイパスを確認します。
条件: scheme=http / 応答: 308 / Location: https://正規ホスト+元URI
アプリ・CMS
業務状態に依存する転送だけを担当させます。ユーザー入力を無検証でLocationへ入れず、許可した同一サイト内URLまたは明示した外部URLだけを使います。
Locationは許可リストで検証し、外部入力を直接連結しない
本番で301・308を先に広く有効化しないでください。永続転送はブラウザや中間キャッシュに残り、設定を戻しても同じ利用者で再検証できない場合があります。限定URLと短いキャッシュ方針で動作を確定してから拡大します。
各ホップの応答と、転送後の利用者操作を分けて検証する
ブラウザが最終ページを表示しただけでは、状態コード、途中のチェーン、メソッド変更、誤ったキャッシュを確認できません。生の応答、追跡結果、実操作、ログを保存します。
- 1
転送を追わず最初の応答を取る
curl -Iなどで状態コードとLocationを確認します。Locationが絶対URLか相対URLか、正規ホスト・パス・エンコード・クエリが期待どおりか記録します。
- 2
追跡して全ホップを数える
curl -ILなどで各3xxと最終応答を確認します。意図した1回で最終URLへ着き、最終状態が200など期待値であること、最大転送回数へ達しないことを確認します。
- 3
POST・APIは安全な検証先で送る
HEADやGETの結果をPOSTへ当てはめません。検証環境でメソッド、本文、Content-Type、Authorization、Cookie、署名、CORSが維持または意図どおり変更されるか確認します。
- 4
ブラウザと主要操作を確認する
Chrome、Edge、Safariで、通常遷移、戻る、更新、ブックマーク、ログイン、フォーム、決済、ダウンロード、エラー表示を確認します。Networkで各応答も保存します。
- 5
クローラーとログで面を確認する
URL対応表を巡回し、ループ、チェーン、404、5xx、誤った外部ホストを集計します。公開後はサーバーログ、Search Console、サイトマップ、canonical選択を継続監視します。
検証コマンド例
初回応答: curl -I https://旧URL ｜ 全ホップ: curl -IL --max-redirs 10 https://旧URL ｜ POSTは本番データを使わず、検証用エンドポイントとテスト資格情報で実行します。
解除は規則削除だけでなく、キャッシュと検索信号まで戻す
一時転送には最初から終了日時と解除担当を設定します。障害時は新しい規則を重ねず、転送を担当する層で対象規則を無効化し、既知の設定へ戻します。
- 1
証拠を保存して変更を止める
発生時刻、URL、全状態コード、Location、レスポンスヘッダー、ブラウザ、ログ、直前差分を保存します。利用者影響のある追加変更を止めます。
- 2
権威層の新規規則を無効化する
CDNまたはWebサーバーなど担当層だけを既知状態へ戻し、構文検査後に安全に再読み込みします。別層へ同じ規則を追加して迂回しません。
- 3
キャッシュを限定して扱う
CDNキャッシュは対象URLだけを無効化します。ブラウザが記憶した301・308はサーバー側から完全には消せないため、新しいセッションや未使用URLでも検証し、影響を記録します。
- 4
URL信号を計画どおり復元する
内部リンク、canonical、hreflang、サイトマップまで変更した場合は、復旧計画の同じ版へ戻します。転送だけを戻して相反する検索信号を残しません。
- 5
同じURL対応表で再試験する
初回応答、全ホップ、最終状態、POST・API、主要操作、ログを再確認します。原因、影響、復旧、再発防止、残るキャッシュを記録します。
公開可能と判断する完了チェック
全URLを同じ形式で記録し、担当者が結果を再現できる状態を完了とします。
設計
- 転送理由、恒久・一時、終了条件、担当
- 旧URL、最終URLまたは404/410、状態コード
- メソッド、本文、クエリ、認証情報の扱い
- 例外、規則順、責任層、復旧設定
自動検証
- 最初の状態コードとLocation
- 一段で最終URLへ到達し、ループがない
- 最終応答、クエリ、エンコード、外部ホスト
- POST・API・Webhookのメソッドと本文
実利用
- Chrome・Edge・Safariの遷移とNetwork
- ログイン、フォーム、決済、ダウンロード
- モバイル、戻る、更新、ブックマーク
- アクセシビリティとエラー時の案内
公開後
- 3xx、404、5xx、転送回数、外部転送のログ
- 内部リンク、canonical、hreflang、サイトマップ
- Search Consoleと旧URLへのアクセス
- 一時転送の解除日と永続転送の維持担当
根拠にした一次資料・標準資料
HTTP仕様、検索エンジン、サーバー実装は更新されます。利用中の製品バージョンの公式資料と設定検査コマンドも照合してください。
リダイレクトでよくある質問
301と308はどちらを使えばよいですか？
どちらも恒久転送です。通常のGETページでは301が広く使われます。POSTやAPIでメソッドと本文を維持する要件がある場合は308を検討し、実際の全クライアントで試します。
302と307の違いはセキュリティですか？
セキュリティ強度の違いではありません。307はメソッドと本文を維持する一時転送です。302ではPOSTをGETへ変える実装があるため、要件とクライアントの実測で選びます。
削除したページをトップページへ転送してよいですか？
利用者の目的を満たす同等ページがないなら一括転送しません。404または410を返し、必要なら検索や関連ページへの導線をエラーページに用意します。
curl -Iが成功すれば検証は完了ですか？
完了ではありません。-IはHEAD要求です。全ホップ、最終応答、GET、POST・API、認証、Cookie、主要ブラウザ操作、ログまで用途に応じて確認します。
301を解除すればすぐ元に戻りますか？
ブラウザや中間キャッシュが301・308を保持している場合があります。権威層の規則を戻し、対象キャッシュを限定して無効化し、新しいセッションでも確認します。検索信号の再処理には時間がかかります。
URL移転と運用の関連ガイド
正しいリダイレクトは、状態コードではなく対応表と検証で決まる
理由、最終URL、期間、メソッドを決め、一つの責任層から一段で転送します。各応答と主要操作を記録し、一時転送の解除と永続転送の復旧経路まで維持してください。
この記事の編集・検証方針
Finite Field 編集部
RFC 9110、Google Search Central、Apache HTTP Server、NGINXの一次資料を照合し、状態コード、検索上の扱い、プロキシ配下のループ、設定・検証・解除を分けて編集しています。
複数層・多数URLの移転を行う方へ
リダイレクト設計と移転検証を相談する
CDNとアプリで規則が重なる、APIや決済を止められない、大量の旧URLを移す場合は、構成図、URL対応表、既存規則、ログ、復旧条件を準備してください。
リダイレクト設計を相談する構成と運用条件を確認したうえで対応可否をご案内します。無停止、検索順位、クロール完了時期、外部サービスの継続、事故の完全防止を保証するものではありません。