リダイレクトチェーン：発生メカニズム、コスト、フラット化方法

リダイレクトチェーンは、緑のライトの裏に隠れるまれな技術的欠陥です。 URL を入力し、ページを取得、ステータス 200 — すべての通常テストが合格します。なぜなら、すべての通常 HTTP クライアントがチェーン全体を黙って追跡し、到達した場所のみを報告するからです。 途中のホップは存在し、各フェッチ時に課金されますが、ブラウザには何ホップあったかを知らせる情報はありません。

有用なリダイレクト検出は、エントリ URL、中間先、最終ページを表示します。 そのレコードにより、担当チームは元のリクエストを直接意図した先に送るべきルールを決定できます。 観測は修復後も簡単に検証できます：シーケンスを再度確認し、保存されたパスと比較します。

4-ホップチェーンは 4 個の別々の正しい判断から構成されます

チェーンは一層ずつ蓄積し、各層は到達時にその位置を獲得します：

1. TLS が到達します。 何者かがエッジルールを追加し、http:// を https:// に送ります。 意図した先は現在 HTTPS を使用します。
2. 正規のホストが選択されます。 チームは www を標準化し、頂点がそれにリダイレクトします。 同族ホスト名は同じ意図した先に導くべきです。
3. トレーリングスラッシュが正規化されます。 フレームワークまたは CDN デフォルトが、最終スラッシュを追加または削除するルールを追加します。 公開リンクとサイトマップ項目は、一貫して意図したスタイルを使用すべきです。
4. 国際化が配備されます。 ルートパスはロケールプレフィックスにルーティングを開始し、/blog/ は /en/blog/ へ。 ローカライズされたページは、別々の安定した URL が必要ですが、ルートからのリダイレクトはサイト設計の選択です。

これが 4 つの正しいルールで、今 http://example.com/blog は 4 回のリダイレクトを経て目的地に到達します。 CMS マイグレーションが /blog/* を /articles/* に書き換えると、最初の 4 つに触れずに 5 番目を追加します。これはアプリケーションで実装され、他はエッジ、ウェブサーバー、ルーターに存在します。 ルールはリクエストがスタックを通過する順序で発火し、最速で URL を解決する順序ではありません。 その構成は誰も所有していません。

これは、私たち自身のデータで http から https への結果が慎重に読み取られる必要がある理由でもあります。 2026 年 5 月 23 日から 8 月 31 日の間に、HTTP-to-HTTPS 正規化は 171 件の評価の 44% でフラグ付きでしたが、48 件の異なるサイトのうち 8% しかありませんでした。 サイトレベルの 8% は有病率の数値であり、評価数値は私たちの観測を示しており、ウェブ ではありません。 チェックは監査が実行されるたびに評価されるため、欠陥が残っている間に繰り返し監査された数少ないサイトが多くの失敗評価を寄与し、評価率を影響を受けたサイトの割合をはるかに上回ります。 44% を「44% のサイト」と引用すると、有病率が 5 倍以上過大評価されます。

Google は最大 10 ホップまでフォローし、5 未満に抑えるようにアドバイスします。

ホップ予算は文書化されており、民間伝承ではありません。 Google のクロールドキュメントでは、デフォルトでクロールャが最大 10 リダイレクトホップまでフォローし、個々の製品が異なることを指摘しています — Google の独自の検査ツールはリダイレクトをまったくフォローしません。 サイト移行ガイダンスはより具体的です： Googlebot は最大 10 ホップまでフォローできますが、「最終先に直接リダイレクトすることを推奨します。これが不可能な場合は、チェーン内のリダイレクト数を低く保ち、理想的には 3 以下、5 未満にしてください。」。 クロール予算ドキュメントはそれを一行にまとめます： 長いリダイレクトチェーンを避けるべきで、これはクロールに悪影響を与えます。

コストは 3 部分に分割され、それぞれ不均等な重みを持ちます：

クロール効率。 各ホップは Google のクロールャがコンテンツを受信せずに費やすリクエストです — ドキュメントはリダイレクトする URL によって返されたコンテンツは無視され、最終ターゲットのコンテンツのみが処理されると明示しています。 数百のURLを持つサイトでは、これはノイズです。 チェーンが URL パターンにあるサイトでは、すべての内部リンクがそれを使用し、全クローラ全体にわたって乗算され、同じホストがすでに対象としているクローラ容量制限と競合します。

未キャッシュ取得時のレイテンシ。 ホップは完全な往復です：DNS はすでにウォームかもしれませんが、ホップがホストを変更すると接続再利用は終了し、example.com から www.example.com ステップは定義上それを行います。 ユーザーは一度それを感じ、次に感じなくなります。なぜならブラウザは永続リダイレクトをキャッシュするからです。 冷たい状態で取得する機械は、ウォームキャッシュがないため、毎回それを感じます。

シグナル統合、そこに民間伝承が存在します。 古い主張は、各ホップがリンクエクイティのパーセンテージを失うというものでした。 Google は 2016 年 7 月に公開でそれに反論し、Gary Illyes は 30 倍リダイレクトは PageRank を失わないと断言し、John Mueller がその年初に http‑to‑https 移行について述べたことを明確にしました。 心配の耐久版はより狭く、まだ現実的です：301 は利用可能な最も強力な正規化シグナルであり、リダイレクトの価値はそれが一つの宛先を明確に命名することにあります。 チェーンはまだ一つの宛先を命名するので、エクイティの議論は 3 の理由の中で最も弱いものです。 クローラ効率とレイテンシがケースを担います。

AI フェッチャーとエージェントはブラウザよりもチェーンを寛容に扱いません

ブラウザはサイトがテストされる中で最も許容的なリダイレクトクライアントです。 彼らは長いチェーンをコメントなしで追跡し、永続リダイレクトを積極的にキャッシュし、宛先を要求された URL のように提示します。 プログラム的クライアント — AI アシスタント、検索パイプライン、エージェントが実際にフェッチするレイヤー — は、ブラウザテストでは明らかにできない方法で変化します。

curl は -L がない限り何も追跡しません；チェーンは 301 を返し、本文は空です。 ライブラリ HTTP クライアントはそれぞれ独自のホップ上限と、全く追跡しないかどうかのデフォルトを選択し、これらのデフォルトはフェッチコードを書いた人によって設定され、サイトによってではありません。 スペック準拠クライアントはリダイレクトがオリジンを横断すると認証情報をドロップします。これは apex‑to‑www ホップが行うことです。 メソッドの意味も変わります：301 と 302 は POST を GET に書き換える長い歴史がありますが、307 と 308 は元のメソッドを保持します — これはエージェントが読み取りではなく送信している瞬間に重要です。

予算制約を追加します。 時間制限の下でページを処理するサマライザーまたはエージェントは、コンテンツを返さないホップに時間を費やし、内部ホップ上限を超えるフェッチはサイトがダウンしているように見えます。 チェーンは自分自身をチェーンとして報告しません；空の結果として報告します。 これは our indexability data の指令衝突と同じ失敗形状です — サイトは人間には機能し、機械には静かに機能しません。

4 ステップでフラット化：在庫、折りたたみ、再リンク、マップを保持

1. 実際のホップ数を在庫化します。 測定し、設定について推論しないでください。単一の URL の場合：

curl -sIL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' http://example.com/blog
curl -sILD - -o /dev/null http://example.com/blog | grep -iE '^(HTTP/|location)'

最初の行がカウントを示し、二番目の行がパスを示します。 http:// と https:// フォーム、apex と www に対して、末尾にスラッシュがある場合とない場合の両方で実行し、各テンプレートから代表的な URL に対して実行します — チェーンは通常、ページではなくパターンに存在します。 audit はホームページ、canonical ターゲット、および代替ホストで同じウォークを行い、追跡されたパスを証拠として報告します。

2. 各チェーンを単一の 301 にまとめる。 エントリ URL と在庫から最終目的地を取り、最初を最後に直接マッピングするルールを作成します。両方を見える最外層（通常はエッジまたは CDN）で行います。その後、チェーンで構成された中間ルールを退役させ、新しいものの後ろに残さないようにします。 永続的な移動には 301 を、メソッドが生存しなければならない場合は 308 を使用します。 ターゲットは自らを canonical と宣言する 200 でなければなりません。canonical が別の場所を指すページにリダイレクトすると、別の語彙で曖昧さが再開されます。これは私たちの canonical tags guide が通過する相互作用です。

3. 内部リンクを最終 URL に指す。 フラット化されたルールは、古い URL を名前に持つすべての内部リンクでホップコストを発生させます。サイトマップ、ナビゲーション、hreflang アノテーション、canonical タグ、および本文内リンクはすべて直接目的地を参照するべきです。リダイレクトは外部のインバウンドリンクと古いブックマークのためだけに存在します。 このステップは、設定修正をクローラ効率の向上に変えるものです。

4. チェーンマップを保持する。 退役したすべてのルール、そのエントリ URL、および最終目的地をインフラ構成と共に保存するファイルに記録します。チェーンは再形成されます。次にロケールプレフィックスを追加する人やパススキームを移行する人は、リクエストパスに既にある 4 つのルールを確認できないためです。 マップは、レイヤー 5 を出荷する人に構成を可視化させるものであり、次の在庫への入力です。 完全なチェックごとに処理は、私たちのリダイレクトと URL 正規化ガイドにあります。

フラット化されたリダイレクト層は、コンテンツ依存性がなく、ランキング遅延もなく、単一コマンドで実行できる検証ステップを持つ数少ない技術的改善の一つです。 多くのサイトで壊れたまま残るのは、誰も手動でテストしてホップを報告しないためです。 トレースが監査の一部になると、4 チームの正しい決定の間のシームは、パス、ホップごとのステータス、および1つのルールを書き込む発見になります。