リダイレクトはURL変更や常時SSL化、www統一、サイト移転で欠かせる仕組みです。本記事は301/302/307/308の違い、SEO評価の引き継ぎ、canonical併用、Apache/Nginx・CMS・CDNでの設定、ヘッダー確認とループ解消までを実務手順で解説。失敗を防ぎ、ユーザー導線と検索評価を両立できます。
目次
リダイレクトの基本と使う場面・目的
リダイレクトは、あるURLに来た人や検索エンジンを、意図した別のURLへ自動で案内する仕組みです。ページの場所を変えたときでも「見つからない」を防ぎ、ブックマークや検索結果から来た人を正しいページに導けます。SEO面では、評価（リンクや掲載順位のシグナル）を受け渡す役割があり、適切な種類を選ぶことで無駄な評価の分散やクロールの浪費を抑えられます。使う主な場面は、URL変更・常時SSL化・www有無の統一・末尾スラッシュの統一・サイト移転・キャンペーンでの一時的な別URLへの案内などです。基本は「なぜ転送するか」を明確にし、1対1の転送・最短経路・重複の解消を心がけます。
【主な目的】
- ユーザー体験の維持：古いURLからでも迷わず到達できる
- 評価の保護：適切な方式で検索評価を新URLへ集中させる
- 正規化：重複URL（http/https、www有無、末尾スラッシュ等）を一つに統一
| 場面 | 主な目的 | 注意点 |
|---|---|---|
| URL変更 | 旧→新へ評価と導線を集約 | 301で恒久転送、1対1・チェーン回避・内部リンク更新 |
| 常時SSL化 | http全体をhttpsへ統一 | 全パターンをカバー、HSTSは段階導入、混在コンテンツに注意 |
| www統一 | www有無の片方へ集約 | 選んだ片側に完全統一、サブドメインとの混同回避 |
URL変更時の評価保持とユーザー導線
記事のスラッグ変更やディレクトリ再編、LPの置き換えなど、URLを変えるときは評価の目減りと迷子を防ぐ設計が大切です。基本は「旧URL→新URLを301で1対1」「最短経路」「内部リンク更新」の3点です。たとえば /blog/old-title を /blog/new-title に変えた場合、301を設定したうえで、サイト内のリンク・メニュー・サイトマップ・OGPなどの参照先も新URLへ更新します。複数段の転送（チェーン）はクロールの浪費や遅延の原因になるため、旧→新を一発で結ぶのが理想です。変更の影響が広い場合は、優先順位の高いページ（流入・収益が多い）から順に対応し、サーチコンソール等でエラーの有無を確認します。
【実務手順（例）】
- 変更対象のURL一覧を作成（旧→新の対応表を用意）
- サーバー/エッジで301を設定（1対1・最短経路）
- 内部リンク・サイトマップ・メニュー・OGP画像URLを更新
- テスト環境でヘッダーと遷移確認→本番反映→エラーチェック
| 変更例 | 推奨対応 |
|---|---|
| /service-old → /service | 301を設定、旧URLへの内部リンクを全て新URLへ置換 |
| /blog/abc → /column/abc | カテゴリ変更でも1対1の301、カテゴリ一覧のリンクも更新 |
常時SSL化やwww統一など正規化の用途
正規化は「同じ内容が複数URLで見える」状態を一つに揃えることです。代表例が http→https の常時SSL化、www有無の統一、末尾スラッシュや大小文字の揺れの統一です。これらが混在すると、評価が分散したり、意図しないURLが検索結果に出たりします。対処は、選んだ正規パターンへ一貫して301転送し、内部リンクも正規URLのみを参照させることです。合わせて canonical の指定やサイトマップのURLも正規に揃えると、検索エンジンが正解を判断しやすくなります。http→httpsでは、画像やスクリプトのhttp混在を解消し、必要に応じてHSTSの導入を段階的に検討します。
【正規化チェック】
- http/https混在はないか（すべてhttpsへ301）
- www有無は統一されているか（片側に集約）
- 末尾スラッシュ・大文字小文字・日本語エンコードの統一
- 正規URLを一度決めたら一貫運用（リンク・サイトマップ・OGPすべて）
- リダイレクトは「最短で1回」になるよう設計（チェーンを作らない）
| 用途 | 設定の要点 | 注意点 |
|---|---|---|
| http→https | 全リクエストをhttpsへ301 | 混在コンテンツ解消、外部リンクの張替えは可能な範囲で |
| www統一 | wwwあり/なし片方に集約 | サブドメインとの区別、証明書のSAN設定 |
一時移転と恒久移転の使い分け判断
リダイレクトには「恒久（301/308）」と「一時（302/307）」があります。恒久は「今後もずっと新URLで提供する」場合に使い、評価の受け渡しを意図します。サイト移転・URL設計の見直し・http→https・www統一などが該当です。一時は「期間限定の案内やテスト」で使い、元のURLに戻す前提のときに適します（キャンペーンLP、在庫切れ時の一時案内、A/Bテストなど）。302と307、301と308の違いは「メソッド保持（POSTなど）を厳密に守るか」です。フォーム送信後の転送など、リクエスト方法を変えたくない場面では307/308が候補になります。長期間302を放置すると、実質的な移転とみなされることがあるため、期間や目的を明確にしておきます。
| 用途 | 推奨コード | 補足 |
|---|---|---|
| 恒久移転（URL変更・https統一） | 301（または308） | 評価の集約が目的。チェーン回避と内部リンク更新が鍵 |
| 短期の代替表示（キャンペーン等） | 302（または307） | 終了日時を決め、原状復帰。長期放置は避ける |
| フォーム送信後の転送 | 307/308 | メソッド保持が必要なケースで検討 |
- 恒久なのに302を使い続ける→評価が分散・クロールも非効率
- テスト目的の一時案内を301で固定→後戻りが複雑化 種類と違い：301/302/307/308
- 恒久移転（設計変更・https・www統一）→ 301（必要なら308）
- 短期切替（告知・品切れ代替）→ 302（必要なら307）
- フォーム送信後やAPIの転送など“方法を変えたくない”→ 307/308 恒久転送301と一時転送302の挙動差
- 恒久なら301：内部リンク・サイトマップ・OGPも新URLに更新
- 一時なら302：期日を決め、終了後は必ず元に戻す
- どちらも「旧→新」は1回のみ。階段状のチェーンは解消
- フォーム送信後のURL整理：307/308でPOSTを維持
- APIエンドポイントの移設：クライアント挙動とキャッシュを要確認
- 多端末テスト：主要ブラウザ・OSで再現性を確認し、ログで検証
- 常用しない：恒久運用や移転ではHTTPリダイレクトを必須に
- 0秒でも注意：表示のチラつきや計測の乱れが起きやすい
- 計測と告知：一時的に使う間は、ページ上で移転先を明示
- 基本はHTTPの301/302/307/308で設計する
- やむを得ない暫定のみメタ/JSを使用し、後日必ず置き換える SEOと正規化：評価・重複・移転時
- 恒久は301で最短1回、内部リンクとサイトマップも新へ統一
- 正規化は“リダイレクト＋canonical”を併用して一貫性を担保 評価の引き継ぎとクロール最適化
- 旧→新は301で1対1・最短1回、内部リンク/サイトマップ/構造化も新へ統一
- canonicalと実際のURLが一致している（相互矛盾なし）
- 404/ソフト404、チェーン/ループが残っていない
- リダイレクト：技術的に同一であるURL（http/https、www有無等）は301で統一
- canonical：増殖する派生URL（パラメータ/並び替え等）は正解を指示
- canonicalでAを指示しつつ、内部リンクはBに向ける（矛盾）
- 正規化すべき差（http/https等）をcanonicalだけで済ませる サイト移転時の段取りと注意点
- 事前：対応表作成、ステージングで301/内部リンク/構造化データを検証
- 公開：XMLサイトマップ差し替え、監視ルール用の計測タグ確認
- 公開後：404/ソフト404・チェーン/ループ・インデックス推移を監視し微修正
- “1対1・最短1回・全置換”の三原則を徹底
- 公開後1〜2週間は日次で監視し、早期に微修正を回す 設定手順：サーバー・CMS・CDN
- 前段（CDN/エッジ）：プロトコル・ホスト名の正規化を一括で実施
- 中段（Webサーバー）：ディレクトリ単位やパターン単位の恒久転送を設置
- CMS：記事/固定ページの1対1転送、パーマリンク変更時の自動301を活用
- 旧→新の対応表を作成し、サンプルURLで挙動・ヘッダーを確認
- サイトマップ・内部リンク・パンくず・構造化データ内URLも新へ統一 Apache/Nginxでの基本ルール例
- まずホスト名とプロトコルを決める（例：https://example.com）
- その正規形へ、ホスト・プロトコルの揺れを“1回”で転送するルールを最上位で定義
- 次に、旧ディレクトリや拡張子変更などのパターン転送を定義（旧→新の1対1）
- 最後に、例外（特定パスを除外）を明示してループを防止
- ホスト・プロトコル統一を先に実行→その後にパス置換を適用
- 旧→中間→新の多段を作らない。古い中継ルールは必ず削除 WordPress等CMSでの安全な設定
- 前段で正規化を完了（http/https、www有無、末尾スラッシュ）
- CMSで旧→新の1対1転送を登録。対応表をもとに漏れなく設定
- カテゴリ変更・スラッグ変更の際は、メニュー・関連記事・サイト内検索結果を同時に更新
- 404テンプレートで代替導線を提示し、ログを確認して漏れ転送を追加
- “1対1・最短1回”の原則を徹底。チェーンは早期解消
- 404ログを毎週確認→漏れURLに転送追加、内部リンクも同時修正 CDN/エッジでのリダイレクト設計
- 順序：プロトコル/ホストの正規化→パス置換→例外の順に評価
- 条件：ホスト名・パス・拡張子・クエリの一致条件を簡潔に保つ
- キャッシュ：リダイレクトのキャッシュTTLを短めにし、ロールバック容易に
- 検索エンジンのクローラーは例外扱いにして、正規URLを巡回できるように
- 広範囲の一括転送は必ず段階適用。問題時は即時ロールバック 確認方法と失敗回避チェック
- 旧→新は1対1・最短1回。中継ルールは残さない
- 正規URLを一貫使用（サイトマップ・内部リンク・OGPも統一） 挙動確認・ヘッダー検証の手順
- 旧URLを開き、最終到達URLが正規形かを確認（www/https/末尾スラッシュ）
- ネットワークでステータスとLocationを確認（1回で新URLへ、コードの妥当性）
- 到達先のcanonical・H1・パンくず・内部リンクが正規URLかを確認
- サイトマップ・検索コンソール・ログで404/ソフト404やチェーンの有無を確認
- 代表URLに加え、クエリ付き・末尾スラッシュ違い・www揺れも必ず検証
- CDN/サーバー/CMSの設定が重ならないよう、役割分担を文書化 運用前のテストと監視のポイント
- 前：ステージングで代表＋揺れパターンを検証し、ヘッダーと着地点を記録
- 直後：日次で30x回数・404・速度を観測、チェーン/ループを即解消
- 以降：週次でクロール統計・インデックス推移・主要KWの流入を確認
- 変更は小さく適用し、計測で安全を確認してから全体展開
- 設定と結果を必ず記録（URL対応表・変更日時・担当）し、再現性を担保 まとめ
「301/302/307/308」は、ブラウザや検索エンジンに“どのくらいの期間・どんな条件で”別URLへ移動させるかを伝える合図です。大きな違いは〈恒久か一時か〉と〈リクエスト方法（GET/POSTなど）を変えないか〉の2点です。一般的なサイト運用では、URL変更・https化・www統一などの恒久的な移転は301（または308）で一貫させ、キャンペーン等の短期的な切り替えは302（または307）を使います。フォーム送信後のようにメソッドを保持したい場面では307/308が有力候補です。どの方式でも「1対1」「最短1回」「内部リンクも正規URLに更新」を守ると、ユーザー体験と検索評価の双方が安定します。
| コード | 性質（期間/メソッド） | 主な用途・注意点 |
|---|---|---|
| 301 | 恒久／メソッド保持は規定なし（実装依存） | URL恒久変更・https化・www統一。最短経路の301で集約 |
| 302 | 一時／メソッド保持は規定なし（実装依存） | 短期の代替表示。長期放置は避け、終了後は原状復帰 |
| 307 | 一時／メソッド保持（POST等を維持） | フォーム送信後の一時移転など。期間を明確に運用 |
| 308 | 恒久／メソッド保持（POST等を維持） | 恒久移転でメソッド保持が必要な時。301同様に設計 |
301は「今後は新URLで提供する」という恒久の宣言です。旧URLに外部リンクが残っていても、ユーザーを迷わせず、新URLに評価を集めやすくなります。URL設計の見直し、ディレクトリ統合、http→https、www統一など、戻す前提がない変更は301でそろえるのが基本です。302は「一時的に別URLを見せる」という扱いで、キャンペーンLP、在庫切れ時の代替案内、メンテナンス回避など“期間限定”に向きます。302を長期間放置すると、恒久移転と解釈される可能性や、内部運用と乖離が生じるため、終了時期と復帰フローをあらかじめ決めておくと安全です。どちらの方式でも、1対1の転送と最短経路が重要で、転送チェーンが増えると表示が遅くなり、クロール効率も下がります。
【実務の着眼点】
| 場面 | 推奨 | 注意点 |
|---|---|---|
| カテゴリ統合 | 301で恒久移転 | 旧カテゴリの内部リンクを全置換。一覧ページも更新 |
| 在庫切れ代替 | 302で短期案内 | 在庫復帰で解除。長期は専用ページ新設を検討 |
307/308でのメソッド保持と注意点
307（Temporary Redirect）と308（Permanent Redirect）は「リクエストメソッドを保持する」のが特徴です。例えばフォーム送信（POST）後の転送でGETに変わってしまうと、再送エラーや意図しない挙動が起きますが、307/308なら方式（POST/PUTなど）や本文の扱いを保ったまま別URLへ案内できます。307は一時、308は恒久という違いだけで“メソッド保持”の考え方は共通です。運用上の注意は、古いクライアントや一部プロキシでの解釈差、キャッシュの取り扱い、CORS/認証付き画面での再送挙動です。フォームやAPIで使う際は、ステージング環境でブラウザ・端末ごとのテストを行い、重複送信を避けるためのトークンや二重送信防止を併用すると安全です。恒久移転でメソッド保持が不要なら301で十分ですが、保持が必要・想定される場合は308を選ぶとブレが少なくなります。
【使いどころとテスト】
メタリフレッシュ・JS遷移の位置づけ
メタリフレッシュ（HTMLのmeta要素での遷移）や、JavaScriptでのlocation遷移は、「どうしてもサーバー側で設定できない場面の暫定策」として考えるのが無難です。HTTPレベルのリダイレクト（301/302/307/308）に比べると、表示が遅れやすく、支援技術や一部クローラーでの解釈が安定しにくい場合があります。特にユーザーの環境でスクリプトが無効なとき、JS遷移は動作しません。メタリフレッシュを使う場合は遅延を0秒にしても、ヘッダーでのリダイレクトには及ばないため、サーバー・CDN・CMSでの設定が可能になり次第、HTTPリダイレクトへ置き換える前提で運用します。
【使うなら守りたい最小ルール】
| 方式 | 利点 | 制約・注意 |
|---|---|---|
| HTTPリダイレクト | 最速・標準的・解釈が安定 | サーバー/エッジ設定が前提（推奨） |
| メタリフレッシュ | HTML編集だけで設定可 | 遅延・チラつき・支援技術/クローラーで不安定 |
| JS遷移 | 条件分岐など柔軟 | スクリプト無効で不発、計測が乱れやすい |
リダイレクトは、検索評価を正しく受け渡し、クロールの無駄を減らし、重複URLを一つに揃えるための“交通整理”です。評価はリンク・掲載の履歴・ユーザー行動など複数のシグナルから成り、URLが分散すると力が割れてしまいます。そこで、恒久の変更は301（必要に応じて308）で旧→新を1対1で結び、内部リンク・サイトマップ・パンくず・OGPのURLまで新に揃えます。正規化では、http/https、www有無、末尾スラッシュ、大小文字、トラッキング付与の違いをなくし、canonicalで“正解URL”を明示しつつ、可能な範囲はリダイレクトで統一します。サイト移転時は、転送設計と同時に、内部リンク置換・XMLサイトマップ更新・Search Consoleの設定確認・計測のUTM/計測タグの整合を一体で進めます。公開後は、クロールエラー、転送チェーン、クリック先の不一致を監視し、最短1回転送へ修正するのが安全です。
| 論点 | 目的 | 実務のポイント |
|---|---|---|
| 評価の引き継ぎ | 旧URLの力を新へ集約 | 301/308で1対1、内部リンク全置換、外部主要リンクへ連絡 |
| 正規化 | 重複の排除 | http→https、www統一、末尾スラッシュ統一、canonical整合 |
| 移転運用 | ダウンタイムと損失の最小化 | 事前テスト→本番→監視の三段構え、チェーン/ループ解消 |
評価の引き継ぎでは「旧→新を明確に示す」「矛盾を作らない」ことが肝心です。旧URLが残ったまま内部リンクやサイトマップが混在すると、クロールが分散し、反映が遅れます。まずは対象URLの対応表（旧/新）を作り、301で1対1、最短経路にします。次に、内部リンク・ナビ・サイトマップ・パンくず・OGP・構造化データ内URLを一斉置換し、canonicalも新URLへ揃えます。公開後は、クロール統計やインデックス登録の推移を見ながら、404やソフト404、転送チェーンを重点監視します。重要ページは、外部のリンク元に可能な範囲で新URLへの差し替え依頼を行うと回復が早まります。クロール最適化の観点では、不要なパラメータの正規化、アーカイブ重複の抑制、同一内容のタグ一覧からの重複を避ける工夫が有効です。
【チェックリスト】
| 症状 | 原因の例 | 対処 |
|---|---|---|
| クロール消費が高い | 重複URL放置、チェーン転送 | 正規化ルール追加、チェーン解消、サイトマップ整理 |
| 評価の鈍化 | 内部リンク混在、旧URLの露出 | 全置換、外部主要リンクの張替え依頼 |
重複URL統合とcanonicalの併用
重複URLは、http/https、www有無、末尾スラッシュ、大小文字、パラメータ付き、同一内容の一覧・タグページなど、多くの要因で発生します。基本は“ユーザーと検索エンジンの入口を一つに揃える”こと。リダイレクトで技術的に統一できるもの（http→https、www統一、末尾スラッシュなど）は301で集約し、商品在庫の絞り込みや並び替えのようにURLが増えやすい領域は、canonicalで“正解URL”を明示します。canonicalは魔法ではないため、内部リンクやサイトマップ、パンくずが正規URLを指すことが前提です。ページ内のhreflangや構造化データの中のURLも正規に合わせ、AMP/モバイル別URLがある場合は相互参照を崩さないようにします。
【併用の型】
| ケース | 推奨アプローチ | 注意点 |
|---|---|---|
| 並び替え・絞り込み | 正規URLにcanonical、内部リンクは正規のみ | サイトマップに派生を載せない、noindexは必要に応じて |
| 末尾スラッシュ揺れ | 片側へ301で統一 | 内部リンクとパンくずを同じ形に統一 |
| Utm等トラッキング | 正規URLにcanonical、内部リンクはパラメータなし | 計測のための自動付与は正規化と矛盾させない |
サイト移転は、評価と導線の“引っ越し”です。段取りを誤ると、アクセス減やインデックス混乱を招きます。最初に、旧→新の対応表を作り、テスト環境で301挙動と内部リンクの整合を確認します。公開直前にXMLサイトマップを新URLで用意し、robots.txtの許可/除外、重要ページのクロール確認までチェックします。公開後は、旧URLから新URLへ301が最短で掛かっているか、Search Consoleのカバレッジ・内部リンク・サイトリンク検索ボックスの挙動などを日次で監視します。大規模移転では、段階公開（ディレクトリ単位）や、負荷分散のためのキャッシュ戦略も有効です。リダイレクトの有効期間は十分に長く取り、外部リンクの張替え依頼は主要参照元から優先的に行います。
【公開前後の流れ】
| 落とし穴 | 起きる理由 | 回避策 |
|---|---|---|
| チェーン増加 | 旧→中間→新の多段転送 | 旧→新を直接に修正、古い中継ルールの削除 |
| 混在URL | 内部リンク置換漏れ | テンプレ/メニュー/パンくずを一括置換、検出はクローラで |
| 正規/実URLの不一致 | canonicalとリンク先が違う | 正規URLへ統一、サイトマップも同一に |
リダイレクトは「どの層で、何を、どの順番で」行うかが肝心です。原則は、広範囲に効かせる正規化（http→https、www統一、末尾スラッシュ統一）はサーバーやCDNの“前段”で一括、個別URLの置き換えや投稿スラッグの変更はCMS側で“きめ細かく”対応します。これにより、不要な転送の多段化や設定の重複を防げます。作業は必ずステージングで検証し、公開直後は計測と監視を日次で回します。
【進め方の全体像】
| 層 | 得意な用途 | 注意点 |
|---|---|---|
| CDN/エッジ | http→https、www統一、国/端末別の分岐 | キャッシュと併用。誤設定で広範囲に影響するため事前テスト必須 |
| Webサーバー | パス/拡張子/ディレクトリの置換、旧→新の恒久移転 | 最短1回の設計、チェーン/ループを必ず解消 |
| CMS | 投稿・固定ページ単位の1対1転送、下層の例外処理 | プラグインとサーバー設定の二重化に注意、運用ルールを一本化 |
ApacheとNginxは“前段で広く・確実に”正規化と恒久移転を処理するのに向いています。Apacheはディレクティブによるディレクトリ単位の設定や、仮想ホスト単位の制御が柔軟で、Nginxはサーバーブロックで高速に一括処理できます。どちらも「評価を引き継ぐ恒久転送」は恒久コード（301または308）を用い、http→https、www統一、末尾スラッシュの統一などを1回で完結させます。
【実装手順（共通の考え方）】
| 用途 | Apacheでの着眼点 | Nginxでの着眼点 |
|---|---|---|
| http→https | 仮想ホストでプロトコル統一。全リクエストを恒久転送 | サーバーブロックで恒久転送。HSTS導入は混在解消後に段階適用 |
| www統一 | ホスト名の統一を最上位で実行、サブドメインとの混同を防止 | ホスト単位で集約、証明書のSAN/ワイルドカードを確認 |
| 末尾スラッシュ | 片側に統一し、内部リンクも同形に | 正規表現でまとめず、必要十分な範囲で簡潔に |
CMSでは「記事単位の1対1転送」と「自動301の活用」がポイントです。WordPressなら、パーマリンク変更時に旧スラッグから新スラッグへ自動301を行う仕組みや、投稿IDを軸に転送できるプラグインがあります。広範囲の正規化（http→https、www統一）はCMSではなく前段で実施し、CMS側は細かなURL変更・カテゴリ統合・古い固定ページの統合など“下層の個別対応”に専念すると安全です。
【運用手順（例）】
| テーマ | 推奨アプローチ | 注意点 |
|---|---|---|
| パーマリンク変更 | 自動301＋手動の例外登録。RSS/OGPも差し替え | プラグインとサーバー設定の二重転送を避ける |
| カテゴリ整理 | 一覧→新一覧へ1対1、古いタクソノミーはnoindexも併用可 | タグ/アーカイブでの重複に注意、canonical整合 |
| 多言語/AMP | hreflang/AMPリンクを更新、相互参照を保つ | 正規URLと矛盾させない（canonicalは常に正規へ） |
CDN/エッジは、世界中の手前で高速に判定・転送できるため、正規化や単純なパターン転送に最適です。http→https、www統一、国/端末別の分岐など、リクエストの“入口”で決め切ると、オリジンに到達する前に正規URLへ集約できます。一方で、誤設定は広範囲に影響するため、必ずステージングや限定ルールでのカナリアリリース（小さく開始）を行い、ログでヒット状況を監視します。
【設計の考え方】
| ユースケース | 設計ポイント | 監視・運用 |
|---|---|---|
| http→https | 全リージョン共通で恒久転送、HSTSは段階導入 | ヒット率と失敗率をモニタ、混在コンテンツの残存確認 |
| www統一 | ホスト判定で片側へ集約、サブドメインは除外 | 誤吸収が無いかアクセスログで検証 |
| 国/端末分岐 | クッキー/ヘッダー条件を明確化し、SEO面は正規URLを維持 | 検索クロールを分岐対象に含めない設計（例外ルール） |
リダイレクトは「設定して終わり」ではなく、意図どおりに動いているかを確認し続ける運用が重要です。確認は、①挙動の確認（画面遷移が期待どおりか）②ヘッダーの検証（ステータスコード・Locationの値）③副作用の確認（canonical・サイトマップ・内部リンクの整合、計測の乱れ）という順で進めると漏れが少なくなります。まずは検証用のURLリスト（旧→新の対応表）を作り、代表パターンだけでなく、クエリ付き・末尾スラッシュ違い・www有無・http/httpsなど“揺れ”を含むサンプルを用意します。ブラウザの開発者ツールではネットワークタブでステータスとLocationを確認し、オンラインのヘッダーチェッカーやサーバー/エッジのアクセスログでも突き合わせます。公開後は、ページ速度の変化、転送回数、404/ソフト404、インデックスの推移、クロール統計を日次→週次で観測し、チェーンやループを早期に解消すると安全です。
| 観点 | 確認内容 | 主な方法 |
|---|---|---|
| 挙動 | 旧URLから新URLへ一発で到達するか | ブラウザ遷移・開発者ツールのネットワーク |
| ヘッダー | 301/302/307/308とLocationの正確性 | ヘッダーチェッカー、ログ（ステータス・リファラ） |
| 副作用 | canonical・サイトマップ・内部リンクの整合 | ページ源データ確認、クローラレポート、GSC |
挙動とヘッダーは「画面」と「通信」の両面で確認します。まず、代表URL（旧→新の対応表）を一つずつ開き、期待どおりの新URLに着地するか、URL欄の最終表示が正規形かを目視で確認します。並行して開発者ツールのネットワークで、各リクエストのステータスコード（301/302/307/308）とLocationヘッダーの遷移先を確認し、余計な一時遷移が入っていないか、クエリや末尾スラッシュが意図どおりかをチェックします。onlineのヘッダーチェッカーを併用すれば、キャッシュの影響や端末差の切り分けがしやすくなります。さらに、着地点のcanonicalが最終URLを指しているか、サイトマップに古いURLが残っていないか、パンくず・内部リンクが正規URLに統一されているかも合わせて確認します。最後に、計測の面では、リダイレクトにより参照元やUTMが失われていないか、LPで自動付与されるパラメータと矛盾していないかを点検すると安心です。
【確認ステップ】
| 項目 | 見るべき内容 | 意図 |
|---|---|---|
| ステータス | 301/302/307/308の使い分けが意図通り | 恒久・一時・メソッド保持の方針を担保 |
| Location | 最終URL、クエリ、末尾の揺れが正規化 | 評価の分散とクロール浪費を防止 |
| canonical | 到達先が自己指し・正規URLを指す | 検索エンジンに“正解”を明示 |
無限ループ・チェーンの解消策
無限ループは「A→B→A…」の往復でページが開けなくなる状態、チェーンは「A→B→C→D」のように転送が階段状に続く状態です。どちらもユーザー体験を損ない、クロール消費や計測の乱れを招きます。原因は、正規化ルールの順序が逆、同じ条件を複数層（CDN/サーバー/CMS）で重複設定、除外条件の不足などが典型です。解消は、①プロトコル/ホストの正規化を最上位で先に実施②その後にパス置換や個別転送③特定パスの除外を明示、の順に再設計します。既存の中継ルールは削除し、旧→新を直接結ぶ1本に整理します。ログでは、同一リクエストIDまたはIPで連続30xが多発していないか、転送回数が2回以上になっていないかを監視します。
| 症状 | 主な原因 | 修正の指針 |
|---|---|---|
| 無限ループ | www統一とhttps統一の順序ミス、除外不足 | 正規化の順序を統一、特定パスを除外、自己参照を回避 |
| チェーン | 古い中継ルールの残存、CMSとサーバーの二重転送 | 旧→新を直接に、二重設定を廃止、1対1へ整理 |
公開前はステージングで「想定パターンを網羅したテスト」を行い、公開後は「日次→週次での監視」を定例化します。テストでは、旧→新の対応表に沿って、ディレクトリ・拡張子変更・http/https・www有無・末尾スラッシュ・クエリ付き・多言語・モバイル専用など、想定しうる揺れを含むサンプルを作成します。監視では、アクセスログでの30x回数、平均転送回数、404/ソフト404、ページ速度（転送前後）、検索コンソールのカバレッジやサイトマップの送信状況を追い、異常があれば設定を巻き戻せるように変更履歴を必ず残します。大規模移転では、段階公開（ディレクトリ単位）やカナリアリリースで影響を限定し、問題がなければ適用範囲を広げると安全です。
【公開前後のチェック】
| フェーズ | 目的 | 見る指標 |
|---|---|---|
| ステージング | 設計どおりの転送と整合性 | ステータス/Location、canonical、サイトマップ差分 |
| 公開直後 | ユーザー体験の担保と不具合潰し | 平均転送回数、404/ソフト404、速度、離脱 |
| 安定運用 | 評価の集約とクロール最適化 | チェーン発生率、クロール消費、インデックス推移 |
要点は「目的→方式→実装→検証」。恒久は301、暫定は302/307、メソッド保持は307/308を選択。正規化とcanonicalを整え、サーバー/ CMS/ CDNで一貫設定。導入前にステージングで挙動とヘッダーを確認し、チェーン/無限ループを排除。公開後はクロールと計測を監視し、必要に応じてルールを微調整しましょう。
