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 で終わるか検証した
• □ 旧設定が長期に滞留していないか、定期的に整理している

← 技術ドキュメント一覧へ戻る