301と302の違いを徹底解説 — 技術・SEO・運用で使い分けるための実践ガイド

はじめに:301と302が重要な理由

ウェブサイト運用やリダイレクト実装で頻繁に出会うHTTPステータスコードのうち、301と302は最も基本的かつ重要なものです。見た目はどちらも“別のURLへ移動させる”ために使われますが、目的・副作用・クライアントや検索エンジンの扱い方が異なります。本コラムではプロトコル仕様、ユーザーエージェントの振る舞い、SEOへの影響、実運用での注意点と設定例、検証方法までを詳細に解説します。

基本の違い(仕様・意味)

  • 301 Moved Permanently(恒久的な移動):リソースが恒久的に新しい位置へ移動したことを示します。以降のリクエストは新しいURLを使うべきであることを意味します(RFC 7231 に基づく表現)。

  • 302 Found / Moved Temporarily(一時的な移動):リソースが一時的に別の位置にあることを示します。元のURLは将来的にも有効である可能性が高いため、クライアントは恒久的な変更とは扱わないのが原則です。

クライアント(ブラウザ)やプロキシの振る舞いの違い

  • HTTPメソッドの扱い:歴史的に、301/302はブラウザがPOSTリクエストをリダイレクト先でGETに変えるなどの振る舞いをしたため混乱がありました。RFC 7231以降も完全な統一はされておらず、結果として

    のリダイレクトに関しては、メソッドと本文を確実に保持したい場合は文字通りの“保持”を意図した307(Temporary Redirect)や308(Permanent Redirect)を使うことが推奨されます。

  • キャッシュ性:301レスポンスは既定でキャッシュ可能とみなされることが多く、プロキシやブラウザがLocationを保存して以降のアクセスで新URLへ直接アクセスする可能性があります。一方、302は基本的にキャッシュされない(明示的にCache-Control等で指示しない限り)ため、一時的なリダイレクトに向きます。

検索エンジン(SEO)への影響

  • インデックスとURL置換:一般に、301は恒久移転として検索エンジンが元のURLを新しいURLに置き換える信号になります。つまり古いURLのインデックスが新しいURLに更新されやすいです。302は一時的な移動とみなされるため、元のURLがインデックスに残ることが多いです。

  • リンク評価(Link Equity / PageRank)の継承):長年の議論がありましたが、主要な検索エンジン(Google等)は301/302ともにリダイレクト先へリンク評価を伝搬するようになっています。ただし、実務上は「恒久的にURLを変更するなら301を使う」ことが明確なシグナルとなり、検索結果の安定性やインデックス更新の予測がしやすくなります。Googleは状況に応じて302を恒久的と判断して扱うこともあるため、意図していない結果を避けるために適切なステータスを使うことが重要です(参考:Google Search Central)。

  • 運用上の影響:サイト移転やURL正規化(canonical)を行う際、301を適切に使わないと古いURLが検索結果に残り続けたり、クロール予算が浪費されることがあります。逆に一時的キャンペーンやA/Bテストでは302を使うことで旧URLを維持したままの運用が可能です。

実際の利用シーンと推奨

  • サイト恒久移転(ドメイン変更、URL構造の常時変更):301を使用。これは検索エンジンに恒久的変更を伝え、インデックスの更新を促すため。

  • HTTP→HTTPSへのリダイレクト:通常は301を推奨。恒久的な移行とみなされるため。

  • 一時的なキャンペーンページやメンテナンス(期限あり):302を使用。ユーザーを一時的に別ページへ誘導する目的に適する。

  • フォーム送信後のリダイレクト:POSTのままリダイレクト先でもPOSTを保持したい場合は307/308を検討。GETに切り替えて問題なければ302や303を使うこともある。

サーバ設定例(よくある環境)

  • Apache(.htaccess)で301例:RewriteRuleやRedirectPermanentを使用します。例:
    Redirect 301 '/old-page' '/new-page'

  • Nginxで301例:serverやlocationコンテキストで書きます。例:
    return 301 '/new-page';

  • ※上記は概念的な記述です。実運用では正規化(末尾スラッシュ、www有無)、クエリ文字列の扱い、パス正規化なども考慮してください。

検証とデバッグの方法

  • curlで確認:ターミナルからヘッダだけを確認する。例:
    curl -I 'https://example.com/old-page'

  • ブラウザのDeveloper Tools:NetworkタブでステータスコードとLocationヘッダ、リダイレクトチェーンを確認できます。

  • オンラインツール:RedirectチェッカーやSEOツールでチェーンの深さ、最終ステータス、レスポンスヘッダを確認。

注意点・よくある落とし穴

  • リダイレクトチェーンとループ:複数のリダイレクトを重ねるとレスポンス遅延やクロール浪費の原因になります。可能な限りチェーンを短く(理想は1回)し、ループが発生しないようにすること。

  • 誤ったステータス選択:恒久的移行なのに302を使うと検索エンジンが旧URLを残したままにする可能性があります。逆に一時的なリダイレクトに301を使うと将来戻したときに検索エンジンが元に戻さないことがあります。

  • キャッシュヘッダの設定:301はキャッシュされやすいので、移行テスト中は短めのCache-Controlやno-cacheを設定しておくと安全です。

  • クエリパラメータの扱い:クエリを適切に引き継ぐか、切り捨てるかを明確に。クロール時に同一コンテンツが複数URLで存在すると重複コンテンツ問題になります。

運用フロー(移行時のチェックリスト)

  • 1) 移行対象URLリスト(旧URL→新URL)を作成する。

  • 2) 一括で301を設定する前にサンプルで検証(数ページ)する。

  • 3) ブラウザとcurlでステータスとLocation、キャッシュヘッダを確認。

  • 4) サイトマップ・内部リンク・canonicalタグを新URLに更新する。

  • 5) Search Console等で移行状況を監視し、クロール数・インデックス状況に異常がないか確認。

まとめ:いつ301、いつ302を使うか

結論として、URLを恒久的に変更する(ドメイン移転、恒久的な構造変更、常時HTTP→HTTPS化など)の場合は301を使うのが基本です。一方、キャンペーンや一時的なページ差し替え、短期的なメンテナンスなどでは302が適切です。POSTなどのHTTPメソッドを保持したいケースでは307/308の検討が必要です。検索エンジンは賢くなっていますが、運用側が明確な意図を持って適切なステータスコードを返すことが、予期しないインデックス変化やユーザー体験の悪化を防ぐ最善策です。

参考文献