HOME > 技術ドキュメント > 301/302 リダイレクト設計のベストプラクティス
301/302 リダイレクト設計のベストプラクティス
執筆:株式会社エスロジカル(Webシステム受託開発・インフラ構築・運用改善)
URL 変更・サイト統合・HTTPS 化のたびに発生するのが「リダイレクト設計」です。
301 と 302 を取り違える、リダイレクトチェーンを伸ばす、ループを作ってしまう──いずれも
SEO 評価の取り損ねとリンク切れの遠因になります。
本記事では、実務で押さえておきたい設計原則と、Apache・Nginx での実装サンプルを整理します。
1. 301 / 302 / 307 / 308 の違い
| コード | 名称 | 永続性 | メソッド変換 | 典型用途 |
|---|---|---|---|---|
| 301 | Moved Permanently | 永続 | 多くは GET に変換 | 恒久的な URL 変更・HTTPS 化(実務で最も頻用) |
| 302 | Found | 一時 | 多くは GET に変換 | キャンペーン期間中の差し替え・A/B |
| 303 | See Other | 一時 | GET に変換(明示) | POST 後 GET(PRG パターン) |
| 307 | Temporary Redirect | 一時 | 維持 | POST のまま別 URL へ転送 |
| 308 | Permanent Redirect | 永続 | 維持 | API の URL 恒久変更でメソッドを保ちたい |
選び方の原則:恒久的な変更なら 301(API では 308)。「いずれ元 URL に戻すかもしれない」ものだけ 302。 302 を使うと検索エンジンは新 URL に評価を集約しないため、サイト統合や HTTPS 化に 302 を使うのは典型的な失敗です。 ステータスコード全般の整理は HTTPステータスコード実務ガイド も参照してください。
2. URL 変更・サイト統合時の設計原則
- 1-to-1 で対応付ける:旧 URL ごとに「新 URL の最終形」を 1対1 で決める。「とりあえずトップに集約」は、テーマ性を失って SEO 評価が大きく落ちます。
- サイト構造の階層も保つ:カテゴリページ → カテゴリページ、記事 → 記事、と同じ粒度の URL に転送する。
- クエリパラメータを丁寧に扱う:
?utm_source=...のような付加クエリは新 URL に引き継ぐ(広告計測が壊れる)。 - sitemap.xml も更新:新 URL のみを sitemap に載せ、旧 URL は外す。サーチコンソールで「変更されたアドレス」ツールを使うとクロールが早まる。
- 巡回検証を入れる:切り替え直後に リンク切れ巡回を 1度走らせて、リダイレクト先がさらに 404 になっていないか確認する。
3. リダイレクトチェーン・ループの落とし穴
- チェーン(連鎖):A → B → C → D のように何段もリダイレクトする状態。Googlebot は数段で諦めることがあり、ブラウザはユーザー体験を損ないます。常に「最終 URL」へ直接転送するのが原則。
- ループ:A → B → A のように戻ってきてしまうと
ERR_TOO_MANY_REDIRECTSで全停止。HTTPS 強制と www 強制を別々のルールで書くと起きやすい。 - HTTPS 化と www 統一は 1 ステップにまとめる:http://example → https://www.example の 1 ステップに圧縮し、http://example → https://example → https://www.example のように 2 段にしない。
- 古いリダイレクトの清算:サイト統合・リニューアルを繰り返した結果、何年も前の旧 URL ルールが .htaccess に残っているのは典型。長くなりすぎたルールセットは定期的に「最終 URL → 直接」に集約する。
4. Apache での実装
4-1. mod_alias の Redirect(最もシンプル)
|
# 単一 URL の 301 リダイレクト Redirect 301 /old-page.html /new-page.html # 削除済みページに 410 Gone を返す(mod_rewrite 不要) Redirect 410 /retired-section/ |
4-2. mod_rewrite(パターンマッチが必要なとき)
|
RewriteEngine on # ファイル名の単純な 1対1 変換 RewriteRule ^old_page\.html$ /new-page.html [R=301,L] # http → https を強制(HSTS と組み合わせる) RewriteCond %{HTTPS} !=on RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L] # 非 www を www に統一(同時に HTTPS 化) RewriteCond %{HTTP_HOST} ^example\.com$ RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L] |
注意:RewriteRule の [L] は「同じディレクトリ内のルール終端」を意味するだけで、サブディレクトリの .htaccess に処理が引き継がれることがある。
複雑な構成では [END](Apache 2.4 以降)を使うと完全終端できる。
5. Nginx での実装
5-1. return(最速・最も推奨)
|
# 単一 URL の 301 location = /old-page.html { return 301 /new-page.html; } # http を https に強制(別 server ブロックでまとめる) server { listen 80; server_name example.com www.example.com; return 301 https://www.example.com$request_uri; } # 非 www を www に統一(https 側) server { listen 443 ssl; server_name example.com; return 301 https://www.example.com$request_uri; } |
5-2. rewrite(パターンマッチが必要なとき)
|
# 旧 /blog/YYYY/MM/slug を /articles/slug に統一 rewrite ^/blog/\d+/\d+/(.+)$ /articles/$1 permanent; # permanent = 301 / redirect = 302 |
推奨:Nginx では rewrite より return のほうが正規表現評価が無く高速です。
6. SSL(HTTPS 化)と 301 リダイレクト
- HTTPS 化時は 301 一択:302 を使うと検索エンジンが「いずれ http に戻るかも」と判断し、HTTPS 版にランクが集約されない。
- 1 ステップに圧縮:http://example → https://www.example のように 1 リダイレクトで完結させる。
- HSTS との組み合わせ:切り替えが安定したら
Strict-Transport-Securityヘッダーを返してリダイレクト自体を削減(2回目以降のアクセスはブラウザ内部で https に書き換わる)。 - 証明書チェーン・有効期間:301 設計とは別に、サーバー証明書のチェーン・更新も必須。SSL証明書インストールチェッカー で確認できる。
7. リダイレクト設定後の検証手順
- curl -IL で連鎖確認:下記コマンドでチェーン全体を表示。301 が 1 段だけになっているかチェック。
- 主要 URL のリストを作って一括検証:旧サイトの URL リスト(sitemap.xml が便利)を入力に、全て 301 → 200 で終わるかを巡回する。
- 4xx・5xx が混ざっていないか:リダイレクト先がさらに 404 になっていないか、リンク切れチェック(dead-link-checker.com) のような定期巡回サービスで継続的に確認するのが安全です。
- Search Console:「ページ > 未登録」「リダイレクトエラー」のセクションで Google から見えている問題を確認。
|
# 連鎖の全段表示(最大 10 段まで追跡) curl -ILs --max-redirs 10 https://example.com/old-page.html # 最終 URL とステータスだけ簡潔に確認 curl -o /dev/null -s -w "%{url_effective} %{http_code}\n" -L https://example.com/old-page.html |
設計チェックリスト
- □ 恒久的な変更は 301(または 308)で返している
- □ リダイレクトチェーンが 2 段以下になっている
- □ HTTPS 化 + www 統一を 1 ステップに圧縮している
- □ sitemap.xml には新 URL のみを記載している
- □ 削除した記事は 404 ではなく 410 を返している(取り扱い終了が明確なもの)
- □ 切り替え後に全旧 URL を巡回して 200 で終わるか検証した
- □ 旧設定が長期に滞留していないか、定期的に整理している
dead-link-checker.com(弊社運営)なら、リダイレクト先がさらに 404 になっていないか・チェーンが増えていないかを定期巡回で検知できます。
関連:HTTPステータスコード実務ガイド / リンク切れ調査と運用フロー入門 / SSL証明書
