301・302・303・307・308リダイレクトの違いと設定【2026年最新】

リダイレクトとは？SEOとユーザー体験での役割

HTTPリダイレクトは、サーバーが3xx状態コードとLocationヘッダーを返し、別のURLを参照するようクライアントへ伝える仕組みです。URL変更、HTTPからHTTPSへの統一、ドメイン移転、一時的な退避、フォーム送信後の画面遷移などに使います。

Google検索では、301と308は転送先を正規URLとみなすための恒久的なシグナル、302・303・307は元URLを検索結果に残す意図を示す一時的なシグナルとして扱われます。ただし、リダイレクトだけで順位や置換時期が保証されるわけではありません。内容の対応、内部リンク、canonical、サイトマップ、クロールと再処理を含めて判断されます。

301・302・303・307・308の違いを比較

選び方は「恒久か一時か」と「転送後も同じメソッドと本文を使うか」の2段階です。通常のGETページだけでなく、ログイン、決済、API、Webhook、ファイル送信まで対象に含めてください。

301と302は歴史的なクライアント挙動により、POSTがGETへ変更される場合があります。メソッド変更を許容できない処理では、307または308を選び、実際に利用するクライアントで確認します。

目的別：どのリダイレクトを選ぶか

迷ったときは、コード一覧から選ぶのではなく、次の順序で要件を絞ります。GETページと送信処理を同じ規則で扱わないことが重要です。

よくある目的と推奨候補

SEOで失敗しないURL対応表とサイト移転手順

サイト移転では、実装前に旧URLと最終URLを対応付けます。ページだけでなく、画像、動画、JavaScript、CSS、PDFなど、外部から参照される資産も対象です。サイトマップ、アクセスログ、Search Console、CMS、被リンクのあるURLを組み合わせて一覧化します。

リダイレクトループ・チェーンの原因と直し方

ループは設定文1行だけで起きるとは限りません。CDN、ロードバランサー、Webサーバー、CMS、アプリがそれぞれスキーム・ホスト・パスを正規化すると、利用者から見えない条件が循環します。最初に「どの層が最終決定を持つか」を一つ決めます。

Apache・NGINX・PHPでのリダイレクト設定例

設定例はそのまま貼り付けず、正規ホスト、TLS終端、既存ルール、クエリ、アプリの基準URLに合わせてください。変更票には、構文検査、差分、再読み込み、即時復旧のコマンドを残します。

Apache：単純な転送はRedirectを優先する

HTTPからHTTPSへの全体転送は、専用のポート80 VirtualHostに置くと責任範囲が明確です。単純な転送でmod_rewriteを増やすと、条件順と例外の把握が難しくなります。

<VirtualHost *:80>
  ServerName example.com
  ServerAlias www.example.com

  Redirect permanent / https://example.com/
</VirtualHost>

ディレクトリ単位の恒久移転では、元パスの後続部分を新パスへ引き継ぐかを確認します。

Redirect permanent /old/ https://example.com/new/

NGINX：単純な転送はreturnで終了させる

単一URLの転送は完全一致のlocation =とreturnで狭く定義します。広い正規表現のrewriteを追加する前に、既存のserver・location優先順位を確認してください。

location = /old-page/ {
  return 301 https://example.com/new-page/;
}

server {
  listen 80;
  server_name example.com www.example.com;

  return 308 https://example.com$request_uri;
}

通常のWebページだけなら301が広く使われます。308はメソッドと本文を維持するため、APIや送信処理を含む構成で有力ですが、古いクライアントを含む利用環境で確認します。

PHP・CMS：サーバー設定を触れない場合の最小例

アプリ層の転送は、業務状態に依存する場合やサーバー設定へアクセスできない場合に限定します。出力前にヘッダーを設定し、処理を終了します。ユーザー入力を無検証でLocationへ連結しないでください。

<?php
header('Location: https://example.com/new-page/', true, 301);
exit;

curl・ブラウザ・ログでリダイレクトを検証する方法

ブラウザで最終ページが表示されても、途中に302やチェーンが混ざっている、POSTがGETへ変わった、別ホストへ認証情報を送ろうとしている可能性があります。最初の応答、全ホップ、最終状態、実操作、ログを分けて保存します。

GETで最初の応答とLocationを確認する

curl -IはHEAD要求です。GETと同じ設定が返るとは限らないため、本文を捨ててレスポンスヘッダーを取得する方法も併用します。

curl -sS -D - -o /dev/null \
  'https://old.example.com/path?ref=test'

全ホップ、最終URL、転送回数を確認する

curl -sS -L --max-redirs 10 -o /dev/null \
  -w 'final_url=%{url_effective}\nstatus=%{http_code}\nredirects=%{num_redirects}\n' \
  'https://old.example.com/path'

期待値は、原則として転送回数1、最終URLが対応表どおり、最終状態が200などの正常応答です。最大転送回数へ達した場合は、ループ、循環、不要な正規化を疑います。

POST・APIは検証環境とテスト資格情報で送る

curl -sS -v -L --max-redirs 5 \
  -H 'Content-Type: application/json' \
  --data '{"test":true}' \
  'https://staging.example.com/old-endpoint'

curlは-LでPOSTを追跡すると、301・302・303の後は通常GETへ切り替え、307・308では同じメソッドを再送します。--post301などで挙動を強制できますが、それはクライアント設定であり、サーバーの状態コード選択を置き換えるものではありません。

解除・ロールバックとキャッシュ対策

一時転送は、開始時点で終了日時と解除担当を決めます。恒久転送も、誤設定や想定外の影響に備えて、設定だけでなく内部リンクと検索信号を同じ版へ戻せる復旧計画が必要です。

公開前・公開後のリダイレクトチェックリスト

担当者が同じ結果を再現できることを完了条件にします。「ブラウザで開けた」だけでは完了にしません。

2026年7月時点の一次資料と更新方針

HTTP仕様、検索エンジン、Webサーバー、検証ツールは更新されます。利用中の製品バージョンの公式文書と設定検査コマンドも照合してください。本記事は2026年7月29日に以下を再確認しました。

Finite Field 編集部の更新方針検索上の扱いはGoogle Search Central、状態コードの意味はRFC、設定例は各サーバーの公式文書、検証挙動はcurl公式文書を優先します。画面や仕様が変わった場合は、取得日と本文を更新します。

リダイレクトでよくある質問

URL移転とサーバー運用の関連ガイド