301・302・307・308の違い|SEOリダイレクトの選び方と確認表
2026年7月15日
著者: 与謝秀作
リダイレクトは、あるURLへのアクセスを別のURLへ転送する仕組みです。301・302・307・308は、移転が恒久か一時か、リクエストのメソッドを維持するかで選びます。検索結果を確実に操作するスイッチではないため、URLの対応関係と実際の応答をセットで確認しましょう。
リダイレクトの目的:恒久移転と一時転送
恒久移転は今後使う場所を変更する場合、一時転送は元のURLへ戻す前提がある場合です。記事の移転、URL構造の変更、HTTPSへの統一では恒久転送を検討します。短期の別画面への案内は一時転送の候補ですが、まず転送が読者に必要かを判断します。
一時メンテナンスは何でも別ページへ転送すればよいわけではありません。短期の利用不能を伝えるなら503などの適切な応答も検討します。廃止して代替がないページは404や410が候補です。状況別の意味はGoogleのHTTP応答の説明で確認できます。
301・302・307・308の比較表
コード | 移転の意図 | メソッド | Googleへのシグナル | 用途例 |
|---|---|---|---|---|
301 | 恒久 | POSTがGETへ変わり得る | 転送先を正規URLとする強いシグナル | ガイドの恒久移転 |
302 | 一時 | POSTがGETへ変わり得る | 一時転送として扱う | 期間を決めた別画面 |
307 | 一時 | メソッドを変更しない | 一時転送として扱う | メソッド維持が必要な転送 |
308 | 恒久 | メソッドを変更しない | 恒久転送として扱う | メソッド維持を伴う移転 |
301・302と307・308のメソッド上の違いはHTTPの標準仕様 RFC 9110に基づきます。フォームやAPIのPOSTを含む経路は、SEO担当だけで決めずアプリケーション担当と試験してください。
検索の正規URLシグナルと順位保証の違い
Googleのリダイレクトガイドは恒久転送と一時転送を区別しています。恒久転送は転送先を正規URLとする強いシグナルですが、設定すれば指定日から必ず検索表示が入れ替わるわけではありません。一時転送も「旧URLが永久に表示され続ける」という保証ではありません。
転送先の内容、クロール、他の正規化シグナル、変更の規模も確認します。「301なら順位をすべて引き継ぐ」「302なら評価を渡さない」といった二択で判断しないでください。重複URLの正規化ガイドに沿って内部リンクやcanonicalとの整合を取ります。
移転・統合・廃止・メンテナンスの選択例
架空の状況 | 選択候補 | 判断の理由 |
|---|---|---|
同じガイドを新パスへ移転 | 301または308 | 同等内容が今後も新URLにある |
記事2本を実質同内容の新記事へ統合 | 内容を照合して恒久転送 | 単にテーマが近いだけでは足りない |
サービスを終了、代替なし | 404または410 | 無関係なページへ誘導しない |
短時間の保守停止 | 503等を検討 | 元ページの一時利用不能を伝える |
一時的な別画面へ転送 | 302または307 | 終了条件と元に戻す担当を決める |
在庫切れ商品を自動的に別商品へ転送すると、目的の商品を探す読者を困らせることがあります。商品情報を残すか、入荷案内を出すかも含めて判断します。
URL対応表を作り環境ごとに設定する
設定前に旧URLと新URLを1対1で整理し、同等内容の根拠、期待する応答、例外、戻し方を決めます。Apache、CDN、CMS、アプリケーションなど環境によって設定箇所は違います。環境を確認せず汎用設定を貼り付けると、既存ルールとの競合やループを起こせます。
旧→新 | 理由・意図 | 期待/実測 | 例外・戻し方・担当 |
|---|---|---|---|
/guide-old/ → /guide-new/ | 同じ手順・恒久 | 301/[確認] | POST対象外・旧設定保管・運用担当 |
/ended/ → なし | 代替なし・廃止 | 410/[確認] | 案内を再点検・編集担当 |
[記入] | [記入] | [記入] | [記入] |
クエリを保持するか、削除するか、アンカー付きリンクや認証経路をどう扱うかも決めます。公開前に検証できる環境と承認・切り戻しの手順を用意してください。
公開前に状態コード・Location・全転送段を検証する
ブラウザの開発者ツール等で最初の応答、Location、各転送段、最終応答を確認します。最終ページが200でも、途中でループしたり無関係な画面を経由したりしていないかを見ます。最終URLの本文、リンク、操作、意図しないnoindexも確認します。
架空例として「旧HTTP → 旧HTTPS → 新URL」という連鎖があるなら、旧入口から意図した新URLへ直接向ける設計を検討します。1段化はルール全体を理解して行い、クエリやログイン処理を壊さないようにします。GETだけでなく、必要なメソッドと端末で試験することが大切です。
公開後の内部リンク・サイトマップ・登録状態を追う
公開後は内部リンクを最終URLへ更新し、サイトマップやcanonicalも新しい方針にそろえます。旧URLと新URLを別々に記録し、Googleの取得日・登録情報の更新を追います。検索表示が変わるまでの時間を一律に約束しないでください。
- 旧URL:期待どおりの転送か、エラーが増えていないか。
- 新URL:200、主要本文、正規化、検索掲載の意図が一致するか。
- 導線:内部リンクが旧URLへ戻っていないか。
- 一時転送:終了日と解除担当が決まっているか。
ユーザーの到達確認と検索での処理確認を別々に残すと、転送は正常なのに取得情報が古い場合も切り分けやすくなります。
次に確認する内容に合わせて、リンク切れの調べ方と直し方|404・移転・一時障害の判断表、canonicalタグの設定と確認|重複URL・noindex・転送の違い、noindexの設定と確認|robots.txt・canonical・認証との使い分けも参照してください。


