リダイレクトとは？301・302の違いと設定・確認方法
与謝秀作
リダイレクトは、あるURLへ来たリクエストを別のURLへ転送する仕組みです。ページ移転、URL統一、一時的な移動などで使います。基本は移動が恒久か一時か、HTTPメソッドを保持する必要があるかで方式を選び、旧URLから関連する新URLへ直接つなぐことです。
301・302・303・307・308の違い
コード | 主な意味・用途 | メソッドの扱い |
|---|---|---|
301 | 恒久的な移動 | POSTからGETに変わる場合がある |
302 | 一時的な移動 | POSTからGETに変わる場合がある |
303 | 処理後、別の結果ページ等を取得させる | 通常GETで結果を取得する用途 |
307 | 一時的な移動 | 元のメソッドを保持 |
308 | 恒久的な移動 | 元のメソッドを保持 |
メソッドの違いはRFC 9110の転送仕様に基づきます。GETで記事を読む転送と、POSTで送ったフォームやAPIを再送する転送は同じではありません。送信先に同じデータを渡してよいかも含め、アプリの設計で判断してください。
検索エンジンへの意味と順位の限界
恒久移転なら301・308、一時移動なら302・307などを検討します。Googleは転送を正規URL選択のシグナルとして扱いますが、302先が永遠に登録されないわけではありません。他のシグナルや実際の状況も影響します。301を設定すれば順位・流入が完全に引き継がれる、という保証もありません。Googleの転送ガイドを基準にします。
canonicalは重複・類似ページの正規URLを示す強いシグナルであり、利用者を転送する指示ではありません。ユーザーも新しいURLへ移動させたい場合は、canonicalだけをリダイレクトの代わりにしないでください。
設定前に旧新URLを対応付ける
ページ移転では、旧ページと同じ目的を満たす新ページを決めます。すべての旧URLをトップページへまとめて転送すると、読者が必要な情報へ届かず、適切な対応先として扱われない場合があります。統合で一対一にならないときも、残した内容と検索意図から対応を判断します。
旧パス | 新パス | 方式 | 理由 | 確認 |
|---|---|---|---|---|
/old-guide | /new-guide | 301または308 | 同じガイドの恒久移転 | 1回の転送、最終200、内容一致 |
/campaign | /temporary-campaign | 302または307 | 元へ戻す予定の一時移動 | 戻す日、メソッド、条件 |
フォーム送信後の処理 | 結果表示ページ | 設計に合う303等 | 再読み込みと再送を分ける | 成功・失敗・重複のテスト |
表は架空のパスによる設計例です。クエリ、末尾スラッシュ、大文字・小文字、言語、wwwの有無など、実際に旧リンクで使われるパターンも一覧にします。移行全体の要件はCMSの選定・移行と合わせて整理できます。
設定する層と適用範囲を明確にする
CMS・ホスティングの機能
対応機能がある場合は、旧パス、新しい転送先、ステータス、適用範囲を指定します。別のCDNやサーバーにも同じ設定があるとループや二重転送が起こるため、どこを転送の管理元にするか決めます。
Apache
1ページの完全一致の説明例は「RedirectMatch 301 ^/old-page$ /new-page」です。これはパス/old-pageだけを対象にする例で、ドメイン全体の移転ルールではありません。通常のRedirectはパスの前方一致も扱うため、下位パスを意図せず巻き込まないか確認します。正規表現や置換先の扱いはApacheのmod_alias資料に沿って検証してください。
.htaccessは、共用ホスティングなど主設定へアクセスできない場合に使われます。主設定を変更できる環境では、性能・管理面から主設定での対応を検討します。.htaccessへ移せば高速になるという一般則はありません。
Nginx
1ページの説明例は「location = /old-page { return 301 /new-page; }」のように、完全一致のlocationへ限定します。サーバー全体へ同じreturnを置く例とは適用範囲が異なります。実際の構成、既存location、クエリの要否を確認し、構文テストと検証環境での確認を経て反映します。例をそのまま未知の設定へ追加しないでください。
公開前後の検証チェックリスト
確認項目 | 期待する結果 |
|---|---|
旧URLの応答 | 意図した3xxとLocationを返す |
転送先 | 関連する正しいURL、意図した最終200 |
チェーン・ループ | 不要な中継や循環がない |
条件の違い | クエリ・末尾スラッシュ・言語・メソッドが設計どおり |
検索設定 | 内部リンク・canonical・hreflang・サイトマップが新URLと一致 |
操作と計測 | フォーム再送やイベント二重発火が意図せず起こらない |
ブラウザで最終ページが開くことだけでは、途中のステータスや転送回数までは分かりません。開発者ツールや許可されたHTTP確認手段で応答を確認します。403が出る場合はアクセス拒否の調査、502などはサーバー間エラーの調査を行い、転送の問題と区別します。
移転後も監視し、転送を維持する
旧URLへのアクセス、転送失敗、新URLのクロール・登録、検索実績を追います。Googleのサイト移転手順では、転送はできる限り長く、通常少なくとも1年維持することを案内しています。1年で必ず解除する、評価の引き継ぎが完了すると保証する意味ではありません。外部リンクや利用者のブックマークのため長期維持も検討します。
検索実績はSearch Consoleの分析手順で条件をそろえて確認します。戻す場合も、旧新URL、canonical、内部リンク、サイトマップを同時に整え、転送元と転送先が互いを向く状態を防ぎます。変更日・担当・設定元・検証結果・戻す条件を残すことが、移転を安全に管理する基本です。
小さな範囲で先に試す
多くのURLを変更するときは、代表的な記事、画像への参照、クエリ付きURL、言語別URL、フォームなど、挙動の異なる種類から試験対象を選びます。パスの数が少なくても、ホスト全体へ適用するルールなら影響は大きくなります。対応表と実際の応答を照合してから範囲を広げ、反映後も旧URLから新しい内容へ到達できるかを点検します。転送の設定場所と責任者を一つの台帳で管理すると、後から別担当者が同じルールを追加する重複も防ぎやすくなります。