リダイレクトチェーンビューアー

任意のURLの完全なリダイレクトチェーンを追跡し、最終到達先までの各ホップ（301/302/307/308）を確認します。正規リダイレクト（HTTP→HTTPS、www/非www、ロケールパス）を検証し、ループや長いチェーンを明らかにし、オプションでLocationを含む生ヘッダーを検査できます。監査と監視のために結果をJSONにエクスポートできます。

Loading…

このツールについて リダイレクトチェーンビューアー

URLを入力して、そのリダイレクトをホップごとに追跡し、実際の到達先を確認します。このツールは、SEO移行、リダイレクトルール（Nginx/CDN/アプリ）のデバッグ、正規ホスト/HTTPS動作の検証、ユーザーとクローラーを遅くするリダイレクトループや不要な追加ホップの発見に最適です。

機能

  • リダイレクトチェーン（301/302/307/308）を追跡し、最終到達先URLを明らかにします。
  • 各ホップのLocationターゲットを表示し、ルーティングと正規化を理解します。
  • 一般的な正規リダイレクト（HTTP→HTTPS、www↔非www）を検証します。
  • 詳細なデバッグのためのオプションの生ヘッダービュー（Locationやキャッシュヘッダーが存在する場合を含む）。
  • チケット、監査、移行手順書のために結果をコピーします。
  • 自動化と繰り返し可能なSEOチェックのためにJSONレポートをエクスポートします。
  • デフォルトで安全：プライベートネットワークターゲットをブロックし、固定のUser-Agentを使用します。

🧭 使い方 for redirect-chain-viewer

1

テストしたいURLを貼り付けます

開始URLを入力します（可能であればプロトコルを含めて）。http://とhttps://の両方をテストすると、正規化の問題が明らかになることがあります。

2

「リダイレクトを追跡」を有効にしたままにします

このツールはチェーンを追跡するように設計されています。リダイレクトを追跡すると、各ホップと最終到達先が表示されます。

3

デバッグ時は「生ヘッダーを表示」を有効にします

より詳細な手がかり（Locationの形式、キャッシュレイヤー、サーバーの動作）が必要な場合は、生ヘッダーを有効にして詳細を確認します。

4

チェーンを解釈します

追加のホップ、プロトコルの切り替え、ホスト名の切り替え、ロケールの書き換えを探します。最適なチェーンは通常、正規URLへの0〜1ホップです。

5

監査のためにJSONをエクスポートします

JSONレポートをダウンロードして結果を保存し、時間の経過とともに変化を比較したり、SEO/運用チケットに証拠を添付したりします。

技術仕様

リダイレクト追跡の動作

このツールはURLにリクエストを送り、リダイレクトレスポンスを追跡し、最終到達先または設定されたリダイレクト上限に達するまで各ホップを収集します。

設定動作デフォルト
リダイレクトを追跡完全なチェーンを収集するためにリダイレクトを追跡します有効
最大リダイレクト数指定されたホップ数を超えるとトレースを停止します15
生ヘッダーを表示デバッグ用に出力に生のレスポンスヘッダーを含めます無効
タイムアウトリクエストのタイムアウト制限15000 ms
ユーザーエージェントリクエストのユーザーエージェントを識別しますEncode64Bot/1.0 (+https://encode64.com)
プライベートネットワーク安全性のため、プライベートネットワーク範囲へのアクセスをブロックします無効（プライベートネットワークは許可されていません）

一般的な「良い」リダイレクトパターン

ほとんどのサイトは、レイテンシとクローラーのオーバーヘッドを最小限に抑えるために、迅速に1つの正規URLに収束するべきです。

目的例のチェーン推奨
HTTP→HTTPShttp://example.com → https://example.com✅ はい（恒久的）
正規ホストhttps://example.com → https://www.example.com（または逆）✅ はい（恒久的）
末尾スラッシュの正規化/page → /page/✅ 場合による（一貫性を持たせる）
ロケール正規化/ → /en/✅ 戦略上必要な場合
複数ホップhttp → https → www → /en/ → /page/⚠️ 可能であれば減らす
SEO移行の場合、恒久的なリダイレクトは通常301または308です。リダイレクトチェーンは可能な限り短くし、内部リンクとサイトマップを最終的な正規URLに直接指すように更新してください。

ループ検出と失敗モード

リダイレクトループは通常、レイヤー間（CDN + Nginx + アプリケーション）での競合するルール、または正規化設定の不一致から発生します。

症状典型的な原因修正アプローチ
リダイレクト上限に達する2つのURL間でのループ（www↔非-www、http↔https、スラッシュルール）CDN、リバースプロキシ、アプリケーションルーターのルールを監査し、単一の信頼できる情報源を確保する
予期しない302/307認証、A/Bテスト、ミドルウェアによって設定された一時的なリダイレクト恒久的な移動には301/308に切り替える；ミドルウェアの動作を分離する
地域によってチェーンが異なるエッジルーティングがPOP/地域/デバイスによって異なる複数のエントリーURLをテストする；エッジでのリダイレクトを標準化する

コマンドライン

このツールが可視化するものと同様に、ターミナルからリダイレクトチェーンを迅速に検査するにはcurlを使用します。

macOS / Linux

リダイレクトチェーンのヘッダーを表示

curl -IL http://example.com

-Iはヘッダーのみを出力し、-Lはリダイレクトを追従します。各HTTPステータスとLocationのホップが表示されます。

リダイレクト後の最終的な有効URLを出力

curl -Ls -o /dev/null -w "%{url_effective}
" http://example.com

リダイレクトを追従した後の最終URLを出力します。

Windows (PowerShell)

レスポンスとリダイレクションを検査

Invoke-WebRequest -Uri http://example.com -MaximumRedirection 10 -Method Get | Select-Object StatusCode, BaseResponse

PowerShellは上限までリダイレクトを追従し、結果のステータスを表示できます。

ループをデバッグする場合は、リダイレクト上限を一時的に下げ（例：3–5）、早期に失敗させて競合するルールのペアを特定します。

ユースケース

SEO正規化チェック

すべてのエントリーURLが迅速かつ一貫して1つの正規URLに解決されることを確認します。

  • HTTPがHTTPSにリダイレクトされることを確認
  • www/非-wwwの正規選択が強制されていることを確認
  • マルチホップチェーンを減らしてクロール効率を改善

サイト移行とドメイン変更

古いURLが新しい同等のURLに正しくリダイレクトされ、チェーンが200レスポンスで終了することを検証します。

  • 古いスラッグが新しいスラッグにリダイレクトされることを確認
  • 移動したコンテンツに対して恒久的なリダイレクト（301/308）を確認
  • リダイレクト先が404になる状況を捕捉

CDN / リバースプロキシのデバッグ

URLがリクエストされた際のエッジルール、プロキシ、アプリケーション間の相互作用を理解します。

  • 各ホップを生成するレイヤーを特定する
  • 重複した正規化ルールによるループを検出する

ローカライズドルーティングのQA

長いリダイレクトチェーンやループを誤って作成することなく、ロケールや地域ルーティング（例: / → /en/）を検証します。

  • ロケール書き換え動作を確認する
  • /fr → /fr/ → /fr（ループ）パターンを避ける

❓ Frequently Asked Questions

❓なぜリダイレクトチェーンはSEOに悪いのですか？

リダイレクトチェーンはクローラーにとって遅延を増加させ、障害点を増やします。検索エンジンはリダイレクトを追跡できますが、長いチェーンはクロール予算を浪費し、特に大規模サイトでは信頼性を低下させる可能性があります。

❓301と308、どちらを使うべきですか？

どちらも恒久的なリダイレクトです。308はHTTPメソッドをより厳密に保持し、301は広く使用され理解されています。SEOの観点では、恒久的な移動に対して一貫して使用されていれば、どちらも問題ありません。

❓301を期待していたのに302/307が表示されるのはなぜですか？

一時的なリダイレクトは、ミドルウェア、認証フロー、A/Bテスト、または設定ミスがあるエッジルールから発生することが多いです。移動が恒久的な場合は、301/308に切り替え、内部リンクを最終URLに更新してください。

❓リダイレクトループの原因を見つけるにはどうすればよいですか？

ループは通常、競合するルール（例：CDNがwwwを強制、アプリが非wwwを強制；プロキシがHTTPSを強制、アプリがHTTPを強制）から発生します。一度に一つのレイヤーを監査し、可能であれば正規化ロジックを一箇所にまとめてください。

❓末尾のスラッシュをリダイレクトすべきですか？

どちらの戦略も機能しますが、一貫性を持たせることが重要です。一つの正規形式を選択し、内部リンクとサイトマップがそれを直接使用するようにして、リダイレクトを減らしてください。

❓ここにURLを貼り付けても安全ですか？

このツールは提供されたURLに対してサーバーサイドのリクエストを行い、プライベートネットワークターゲットをブロックします。URLに秘密情報（クエリストリング内のトークンなど）を含めないでください。

Pro Tips

Best Practice

正規URLに到達するまでのリダイレクトを0〜1回を目指してください。内部リンクとサイトマップを最終目的地に直接指すように更新します。

Best Practice

正規化ルールは一つのレイヤー（CDN、プロキシ、アプリのいずれか）にまとめ、競合するリダイレクトやループを避けてください。

Best Practice

恒久的な移動には301/308を使用し、リダイレクトが本当に一時的な場合を除き302/307は避けてください。

Best Practice

正規動作をテストする際は、プロトコルとホストのバリエーション（http/https + www/非www）の両方をチェックし、結果を比較してください。

Best Practice

移行中にJSON結果をエクスポートし、リグレッションを追跡し、ステークホルダーにリダイレクトの正確性を証明します。

Additional Resources

HTTPリダイレクト（MDN）
Documentation
HTTPレスポンスステータスコード（MDN）
Documentation
Google Search Central: URLリダイレクトとステータスコード
Documentation

Other Tools