302リダイレクト完全ガイド:301との違い・SEOへの影響・実装例と安全対策
302リダイレクトとは何か — 概要
302リダイレクトは、HTTPレスポンスステータスコードの一つで「Found(見つかった)」を示します。一般的には「一時的に別の URL に移動している」ことを表します。クライアント(ブラウザやクローラー)はレスポンスに含まれる Location ヘッダを参照して一時的に示された新しい URI にアクセスしますが、元の URI が将来的にも有効であるという前提があるため、恒久的な変更を意味する 301(Moved Permanently)とは区別されます。
歴史と標準化(RFC の位置づけ)
- HTTP/1.0 時代の記述では 302 は「Moved Temporarily(一時的に移動した)」とされましたが、実装上のあいまいさがありました。
- HTTP/1.1(RFC 7231)では 302 の正式な理由句は「Found」となり、実装上の互換性問題を解決するために 303(See Other)や 307(Temporary Redirect)、さらに 308(Permanent Redirect:RFC 7538)といった追加のステータスが導入されました。
- 重要な点は、302 は「一時的な移動」を示すが、過去のブラウザ実装の挙動(特に POST を GET に変える等)を考慮すると、意図する動作が曖昧になりやすい、ということです。
HTTP レベルでの意味と挙動
- 302 は「リクエストされたリソースが一時的に別の URI にある」ことを示す。レスポンスヘッダに Location を含めるのが通常。
- クライアントは Location に従ってリダイレクト先に再リクエストするが、将来的には元の URI を使うべきと見なす(=恒久的移転ではない)。
- 歴史的理由で、あるブラウザは POST リクエストに対する 302 の応答でメソッドを GET に変更して再リクエストすることがある。この問題を解決するため、POST 後に GET にしたい場合は 303、メソッドを保持したい一時的リダイレクトは 307 を使うのが推奨される。
- キャッシュについて:302 レスポンスはデフォルトではキャッシュ不可と見なされる(Cache-Control や Expires ヘッダがある場合を除く)。
301 と 302 の違い(SEO 観点も含む)
技術的・運用的に重要な違いは次の通りです。
- 恒久性:301 は恒久的な移動を示す。302 は一時的な移動を示す。
- 検索エンジンの扱い:一般に 301 はインデックスの更新とリンク評価(PageRank 的な評価)の移譲に使われます。302 は「一時的」であるためリンク評価を移譲しない可能性が高い。しかし検索エンジン(Google など)は状況により 302 を 301 とみなすこともあるので、意図と異なる動きになる場合がある。
- おすすめ:URL を恒久的に変更する場合は 301 を使用。短期間のリダイレクトやテスト用に一時的に別の URL に誘導する場合は 302 を使用。
302 を使うべきケース・使ってはいけないケース
- 使うべきケース
- キャンペーンページなど、期間限定で別ページを表示する場合(元の URL が将来復活する想定)
- A/B テストなど、一時的にトラフィックを別の URL に誘導する場合
- ログイン後の一時的な振り分け(ただし POST 後の PRG パターンでは 303 が適切なことが多い)
- 使ってはいけないケース
- サイト構造を恒久的に変更する(この場合は 301)
- POST リクエストの後でメソッドを保持したままリダイレクトしたい場合(この場合は 307)
- SEO 上で恒久的な評価移行を期待する場合(301 を検討)
実装例(サーバー・アプリケーションでの設定)
いくつか代表的なサーバーとプラットフォームでの 302 設定例を示します。
- Apache (.htaccess)
Redirect 302 /old-page https://example.com/new-page # または mod_rewrite RewriteEngine On RewriteRule ^old-page/?$ /new-page [R=302,L] - Nginx
location = /old-page { return 302 https://example.com/new-page; } - PHP
header("Location: /new-page", true, 302); exit; - WordPress(PHP 内)
wp_redirect( $location, 302 ); exit;セキュリティ対策として外部の URL にリダイレクトする場合は wp_safe_redirect() を使うと安全性が高まります。
- Java Servlet
response.sendRedirect("/new-page"); // HTTP 302 が送られるのが一般的
ブラウザやクローラーの挙動、キャッシュの扱い
- ユーザーエージェントは Location を参照して自動的にリダイレクト先へ遷移するのが一般的。
- デフォルトでは 302 の応答はキャッシュされない(ただし Cache-Control や Expires ヘッダが明示されていればキャッシュ可能)。
- 検索エンジンは 302 を「一時的移行」と見なすが、リダイレクト状態が長期間続くと恒久移行と判断することがある(その場合、インデックスを切り替える可能性あり)。
セキュリティ上の注意点(オープンリダイレクト)
リダイレクト処理はオープンリダイレクト脆弱性の温床になりがちです。外部パラメータをそのまま Location に渡すと、攻撃者がユーザーをフィッシングサイト等へ誘導できてしまいます。対策としては次のような方法があります。
- リダイレクト先をホワイトリスト化する(許可されたドメインやパスのみリダイレクト可能にする)。
- 相対パスのみ許可するか、外部の場合は明示的に検証をする。
- フレームワークや CMS の提供する安全なリダイレクト API(WordPress の wp_safe_redirect など)を利用する。
- 重要操作後は PRG(Post/Redirect/Get)パターンを適切に用い、意図しない二重送信やリダイレクトループを防ぐ。
POST 後のリダイレクトと PRG パターン
フォーム送信(POST)後にリダイレクトを行う場合、同じメソッドを維持するか(POST のまま)あるいは GET に変えるかで選ぶべきステータスが変わります。一般的には PRG(Post/Redirect/Get)パターンにより、POST 後に GET へリダイレクトしてブラウザのリロードで二重送信が発生する問題を避けます。この場合 303(See Other)が明示的に適切です。302 を使うとブラウザの実装差により意図せぬメソッド変更が発生するリスクがあります。
メタリフレッシュや JavaScript でのリダイレクトとの違い
- メタリフレッシュ(HTML の meta refresh)や JavaScript による location 書き換えは HTTP レベルのステータスコード(302 など)とは異なり、サーバー側の正規のリダイレクトではないためクローリングや SEO の扱いが不利になりやすい。
- 可能な限りサーバーサイドで 3xx を返してリダイレクトする方が標準的で明確です。
運用上のベストプラクティス(WordPress 含む)
- 恒久的な URL 変更には 301 を使用する。302 は短期間の切替やテスト用に限定する。
- WordPress では wp_redirect / wp_safe_redirect を使う。外部 URL のリダイレクトは wp_safe_redirect や明示的なバリデーションを行う。
- リダイレクト設計を一覧化して管理し、リダイレクトループやチェーン(A → B → C など)を避ける。チェーンはパフォーマンスとクロール効率を低下させる。
- 重要なページ移行では Search Console 等でサイトマップやサイト移転の通知を行い、検索エンジン側での反映状況を確認する。
まとめ(技術的要点)
- 302 は「一時的なリダイレクト」を示す HTTP ステータスコード(Found)。
- 恒久的移転には 301 を、POST 後に GET にする場合は 303、メソッドを維持したい一時リダイレクトには 307、永続的でメソッドを維持したい場合は 308 を使うのが適切。
- SEO 観点では 302 は一時的扱いとなるため、恒久的な価値移行を期待する場合は 301 を検討する。
- 実装時はリダイレクト先の検証、チェーン回避、キャッシュ制御等に注意する。WordPress なら wp_safe_redirect 等の API を活用する。
参考文献
- RFC 7231 — Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content — Section 6.4.3 (302 Found)
- RFC 7538 — Permanent Redirect (308)
- MDN Web Docs — HTTP 302 Found(日本語)
- Google Search Central — Redirects
- WordPress Developer Resources — wp_redirect()
- OWASP — Unvalidated Redirects and Forwards
- RFC 7231(HTTP/1.1)総合ドキュメント


