301/302/307/308 リダイレクトをホップごとに検査し、ループ、クロスドメインリダイレクト、HTTPS ダウングレードの問題を特定します。
ブラウザにURLを入力すると、背後には見えない一連のジャンプが発生している可能性があります：HTTP→HTTPS、非www→www、旧ドメイン→新ドメイン、短縮URL→長いURL……リダイレクトの各ホップは時間を消費し、SEOランキングに影響を与え、さらにはHTTPSをHTTPに静かにダウングレードしている可能性もあります。リダイレクトチェッカーはサーバー視点でURLの完全なジャンプパスをホップごとに追跡し、各ホップのステータスコード（301/302/303/307/308）、Locationヘッダー、ターゲットアドレスを表示し、ループジャンプ、クロスドメインジャンプ、HTTPSダウングレード、チェーン切断などの問題を自動検出します。ドメイン移行、HTTPS展開、SEO最適化における隠れたリダイレクトの隐患を発見するのに役立ちます。
Google公式はリダイレクトチェーンを単一ホップに抑え、最大でも3ホップを超えないよう推奨しています。Google Search Centralのドキュメントによると、Googlebotは通常最大5つのリダイレクトホップまで追跡した後に追跡を停止しますが、だからといって5ホップが安全というわけではありません。リダイレクトの各ホップはページ読み込み遅延（100-300ms/ホップ）を増加させ、クロール予算を浪費し、PageRank伝達の減衰を引き起こす可能性があります。1ホップはSEOへの影響がほぼなく；2ホップは許容範囲ですが最適化を推奨し；3ホップ以上からLCPとクロール効率に影響が出始め；5ホップ以上はページがインデックスされないリスクがあります。本ツールを使用してコアページのジャンプチェーンを検出し、重要なURL（トップページ、コア製品ページ、高トラフィックのランディングページ）がすべて単一ホップで直接到達できるようにしてください。
正しく使用された301永久リダイレクトはSEOに有害ではありません。GoogleのGary IllyesとJohn Muellerは複数回にわたって確認しています：HTTPドメインからHTTPSドメインへの移行、および同一ドメイン内のページの永久移行における301リダイレクトのPageRank伝達は100%で、損失はありません。ただし注意点があります：1) 302一時リダイレクトはPageRankを伝達しません（または伝達効率が極めて低い）；2) リダイレクトチェーン内にnoindex、robots.txtによるブロック、4xx/5xxエラーが出現すると、重み伝達は中断されます；3) クロスドメインの301移行後は、Google Search Consoleでドメイン変更通知を提出してインデックス移行を加速させる必要があります；4) 301はブラウザに長期的にキャッシュされるため、テスト段階ではまず302で検証してから301に変更することを推奨します。
HTTPS→HTTPダウングレードジャンプは通常以下の原因によります：1) リバースプロキシ/CDNがHTTPでオリジンに戻しており、オリジンサーバーのNginx/Apacheが$scheme変数でプロトコルを取得するとhttpになってしまう；2) アプリケーション層コード内にhttp://プレフィックスのURLがハードコードされている；3) WordPressなどのCMSのHome URLまたはSite URLがhttpに設定されている；4) .htaccess内に旧HTTPルールが残存している；5) 第三者サービス（CDN/WAF）のSSL/TLS設定が「フレキシブル」モードで「厳格」モードではない。修復手順：まず本ツールでダウングレードがどのホップで発生するかを確認；CDNのSSLを「Full (strict)」モードに設定；NginxでX-Forwarded-Protoヘッダーを正しく処理；WordPressではwp-config.phpに$_SERVER['HTTPS']='on'; を追加；HSTSレスポンスヘッダーを展開してブラウザレベルでのダウングレードを防止；すべてのリダイレクトルールでターゲットがhttps://であることを確認。
Nginxのリダイレクトループの90%以上は、リバースプロキシ/CDNシナリオでX-Forwarded-Protoヘッダーが正しく処理されていないことが原因です。修復方法：1) CDN/ロードバランサーがバックエンドにX-Forwarded-Protoヘッダーを送信するようにする：proxy_set_header X-Forwarded-Proto $scheme; 2) Nginxの判断では、$schemeではなくX-Forwarded-Protoを使用してHTTPSへのジャンプ可否を決定します。mapブロックの使用が推奨されます：map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) serverブロック内にrewriteルールを書いて自分自身に無限にマッチさせないようにする；4) wwwと非wwwのリダイレクトは1つのserverブロック内でのみ片道ジャンプを構成し、双方向に構成しない。
Apache .htaccessのループは通常RewriteRuleルールの衝突が原因です。修復手順：1) RewriteEngine Onが1回だけ出現するようにする；2) HTTP→HTTPSジャンプルールをすべてのルールの最前部に配置し、以下を使用：RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]；3) www/非wwwルールはHTTPSジャンプの後に配置し、かつ片道ジャンプ（非www→wwwまたはその逆）のみを行う；4) [L]フラグの意味は「last」ですが、ルールがURLを変更した場合は最初からマッチングをやり直すため、ループが発生する可能性があります。複雑なルールでは[END]フラグの使用を考慮してください（Apache 2.3.9+）；5) 複数の.htaccessファイルがないか確認（サブディレクトリ内の.htaccessも有効になります）；6) 一時的にR=301をR=302に変更してテストし、ブラウザキャッシュの干渉を避ける。
Cloudflareのループで最も一般的な原因は、SSL/TLS暗号化モードの設定誤りまたはページルールの衝突です：1) CloudflareのSSL/TLSモードを「Flexible」から「Full」または「Full (strict)」に変更してください——FlexibleモードではCloudflareからオリジンサーバーへの通信がHTTPになるため、オリジンでHTTPS強制ジャンプを設定しているとループが発生します；2) Cloudflareの「Edge Certificates」にある「Always Use HTTPS」がオンになっているか確認し、オリジンとCloudflareの両方で重複してHTTPSジャンプを設定しないでください；3) Page Rulesに相互に衝突する転送ルールがないか確認してください；4) Cloudflare WordPressプラグインを使用している場合は、プラグインとCloudflareの両方でHTTPSリダイレクトを設定しないでください；5) Forwarding URLルールが、Cloudflareによって再びリダイレクトされるアドレスを指していないか確認してください。
核心的な違いは「永久的かどうか」と「リクエストメソッドを保持するかどうか」の2つの軸にあります。簡単な選択ガイド：通常のウェブページGETリクエスト（ユーザーがページにアクセスする場合）——永久的な移行には301（ドメイン移行、HTTPS切り替え、URL永久変更）、一時的なジャンプには302（A/Bテスト、一時メンテナンス、ログインジャンプ）を使用してください；POST/PUT/DELETEリクエスト（API呼び出し、フォーム送信）——永久的な移行には308、一時的なジャンプには307を使用し、リクエストメソッドとリクエストボディが失われないようにしてください；303は、POSTフォーム送信後に結果ページにジャンプする場合に専用で使用します（強制的にGETにして重複送信を防止）。簡単な覚え方：301=永久・GET安全、302=一時・GET安全、307=一時・全メソッド、308=永久・全メソッド、303=POST後結果ページ。
301永久リダイレクトはデフォルトでブラウザにキャッシュされますが、キャッシュ期間はレスポンスヘッダーのCache-ControlとExpiresの設定に依存します。キャッシュヘッダーが明示的に指定されていない場合、ブラウザによってデフォルトのキャッシュ動作が異なります：Chromeは通常301リダイレクトを数週間から数ヶ月キャッシュします（ブラウザを再起動した後もキャッシュされている場合があります）；Firefoxはデフォルトで301をキャッシュしますが、ブラウザ再起動後に再検証する場合があります；Safariのキャッシュ戦略は比較的保守的です。301キャッシュをクリアする方法：1) Chrome：設定→プライバシーとセキュリティ→閲覧データを削除→期間を「すべての期間」に選択→「キャッシュされた画像とファイル」にチェック→データを削除；2) 開発者ツール（F12）を開いた状態でNetworkパネルの「Disable cache」にチェック；3) URLの後に意味のないクエリパラメータ（?nocache=1）を追加してキャッシュをバイパス；4) Chrome上級者はchrome://net-internals/#socketsでFlush sockets、またはchrome://net-internals/#dnsでClear host cache；5) テスト段階では301の代わりに302一時リダイレクトを使用し、確認後に301に変更してください。
Meta RefreshはHTMLドキュメント内の<meta>タグで実装されるリダイレクトであり（例：<meta http-equiv="refresh" content="0;url=https://example.com/new">）、ブラウザ側でHTMLを解析した後にジャンプが実行されます。一方、HTTPリダイレクトは3xxステータスコードによってHTTPプロトコルレベルでサーバーが直接指示します。違いの比較：1) 速度：HTTPリダイレクトはレスポンスヘッダーを受け取った時点でジャンプを開始しますが、Meta RefreshはHTMLのダウンロードと解析が完了するまで待つ必要があり、速度がより遅くなります；2) SEO：Googleは通常Meta Refreshを認識して重みを伝達します（delay=0の場合）が、公式にはHTTP 301/302リダイレクトの使用が推奨されています。Meta Refreshはクライアントサイドジャンプであるため、シグナルがサーバーサイドリダイレクトほど明確ではないからです；3) 遅延：Meta Refreshは遅延時間を設定できますが（content="5;url=..."なら5秒後ジャンプ）、HTTPリダイレクトにはこの機能はありません；4) アクセシビリティ：W3CはMeta Refreshの使用を推奨していません。スクリーンリーダーなどの支援技術での処理が適切でなく、ユーザーを混乱させる可能性があるからです；5) 戻るボタン：Meta Refreshは一部のブラウザで戻るボタンの動作を壊す可能性があります。結論：常にHTTP 301/302/307/308リダイレクトを優先的に使用し、サーバー設定を制御できない場合（静的ページプラットフォームでサーバー側ルールを設定できない場合など）を除き、Meta Refreshの使用は避けてください。
はい、非常に大きな影響があります。リダイレクトはブラウザがHTMLドキュメントを取得する前に発生するため、リダイレクトの各ホップはHTMLドキュメントのダウンロード開始時間を遅らせます。LCP（Largest Contentful Paint、最大コンテンツフルペイント）の計算起点はナビゲーション開始時間であり、ブラウザは最終的なHTMLを取得した後でなければDOMの解析、CSSの読み込み、LCP要素のレンダリングを開始できません。1ホップあたり150msのネットワーク遅延（DNS+TCP+TLS+リクエストレスポンス）が増加すると仮定すると、3ホップのリダイレクトでLCPが少なくとも450ms増加し、これはLCPを「良好」（≤2.5s）から「要改善」（2.5-4s）の区間まで押し上げるのに十分です。GoogleのCore Web Vitalsドキュメントでは、「複数のリダイレクトを回避する」ことがLCP最適化の重要な提案の1つとして明記されています。ベストプラクティス：コアページはゼロリダイレクト（直接最終URLにリンク）を確保し、HTTP→HTTPSやwww正規化といった必要なリダイレクトは単一ホップに抑えてください。
短縮URL（bit.ly、t.cn、dwz.cn、url.cnなど）は通常1～3ホップのリダイレクトで最終URLに到達し、中間にUTMトラッキングパラメータ、デバイス検出ジャンプ、地域別ジャンプなどが含まれる場合があります。本ツールを使用すると：1) 短縮URLを入力し（http://またはhttps://を含む）；2) 追跡をクリックして各ホップの完全なパスを確認し；3) 最終ランディングURL、ジャンプ回数、ステータスコードタイプを確認し；4) 中間ジャンプにHTTPダウングレードや異常なクロスドメインがないかチェックできます。注意：一部の短縮URLはUser-AgentやIP地域によって異なる最終目標を返す場合があります。本ツールはサーバーIPでリクエストを行うため、ブラウザで直接アクセスした場合と結果が若干異なる場合があります（特に海外の短縮URLサービスでは）。微信/QQのurl.cn短縮URLについては、微信環境内でないと目標ページに正しくジャンプしない場合があります。
HTTPS強制ジャンプには301永久リダイレクトを使用すべきです。HTTPからHTTPSへの移行は永久的な変更であり、一時的なジャンプではないからです。301を設定した後、HSTSレスポンスヘッダーも展開すべきです。完全なHTTPS強制スキームは3つの段階に分かれます：1) 第一段階（テスト期）：まずHTTP→HTTPS 301リダイレクトを設定し、HSTSは有効にせず、1～2週間観察してすべてのリソースとサブドメインが正常に動作することを確認します；2) 第二段階（安定期）：Strict-Transport-Securityレスポンスヘッダーを追加し、初期のmax-ageは短めに設定し（max-age=300の5分など）、段階的にmax-age=31536000（1年）まで増やしていきます；3) 第三段階（Preload）：すべてのサブドメインがHTTPSをサポートしていることを確認した後、includeSubDomainsとpreloadディレクティブを追加し、HSTS Preload List（hstspreload.org）に提出して、ブラウザにドメインのHSTSポリシーを内蔵させ、初回アクセス時のHTTPウィンドウを解消します。HSTSは一度ブラウザにキャッシュされると、max-ageが期限切れになるまでサーバー側で取り消すことができないため、十分なテストを行ってください。
JavaScriptジャンプ（window.location.href='https://example.com'など）とHTTP 3xxリダイレクトには本質的な違いがあります：1) 実行レベル：HTTPリダイレクトはプロトコル層でサーバーがステータスコードを返し、ブラウザはレスポンスヘッダーを受け取った時点で即座にジャンプします；JSジャンプはHTMLのダウンロード、JSの解析と実行が完了した後にジャンプするため、速度がより遅くなります；2) SEO：検索エンジンクローラーはHTTP 301/302リダイレクトを正しく認識して追跡し重みを伝達しますが、JSジャンプのSEO効果はクローラーがJSを実行するかどうかと実行タイミングに依存し、シグナルが弱く不安定です；3) 中間過程：JSジャンプの前にページの読み込みが既に開始されているため（白画面や一部コンテンツのちらつきが発生する場合があります）、HTTPリダイレクトではユーザーが直接目標ページに到達するため、体験がよりスムーズです；4) 信頼性：JSはブラウザ、拡張機能、Content Security Policyによってブロックされる可能性がありますが、HTTPリダイレクトはブラウザのコア機能によって処理されるため、信頼性が最も高いです。結論：URLを永久的/一時的にジャンプさせる必要がある場合は常にサーバーサイドのHTTP 301/302リダイレクトを使用し、JSジャンプはインタラクティブロジック内のページナビゲーション（フォーム検証後のジャンプ、ボタンクリックによるジャンプなど）にのみ使用してください。
はい、リダイレクトチェーンはA/Bテストに多面的な影響を与えます：1) リダイレクトによってA/Bテストを実装する場合（ユーザーの50%を302でバージョンAに、50%をバージョンBにジャンプさせる場合）、リダイレクト遅延によって2つのバージョンのページ読み込み速度が異なり、速度自体がコンバージョン率に影響を与える可能性があるため（速度の速いバージョンは当然コンバージョン率が高くなります）、テストに偏りが生じます；2) リダイレクト過程でUTMパラメータや参照元マーカーが失われ、アトリビューションデータが不正確になる可能性があります；3) 302リダイレクトが長期間継続すると、Googleが独自に永久リダイレクトと判断して重みを伝達し、テストページのSEOに影響を与える可能性があります；4) 多ホップリダイレクトのいずれかのホップでCookieが設定されると、ユーザーのグループ分けロジックに影響を与える可能性があります。A/Bテストにはサーバーサイドレンダリングによる振り分けやクライアントサイドJSによる振り分け（Google Optimize、Optimizelyなど）を使用することを推奨し、リダイレクトによる振り分けは避けてください。どうしてもリダイレクトを使用する必要がある場合（完全に異なるURLパスをテストする場合など）は、302を使用し（301は使用せず）、かつ単一ホップで直接到達するようにし、テスト終了後は速やかにリダイレクトを削除してください。
ウェブサイトのリダイレクトチェーンを一括確認するにはクローラーツールを組み合わせる必要があります：1) Screaming Frog SEO Spiderなどのクローラーツールを使用してウェブサイト全体をクロールし、Redirect ChainsレポートですべてのリダイレクトURLとチェーン長を確認します；2) Ahrefs、Semrush、SitebulbなどのSEOツールのサイト監査機能を使用すると、リダイレクトチェーンやループを自動的に検出してくれます；3) コアページリストについては、スクリプトを作成して本ツールのバックエンドAPIを呼び出し一括検出することもできます；4) Google Search Consoleの「ページインデックス」レポートで「リダイレクトエラー」や「リダイレクトチェーンが長すぎる」の通知を確認します；5) Chrome DevToolsのLighthouse監査を使用すると、Performance部分でリダイレクトの問題が指摘されます。優先的に確認すべきページ：トップページ、主要ナビゲーションページ、高トラフィックランディングページ、最近移行/リニューアルしたページ、HTTPS切り替え後のすべてのHTTP URL、旧ドメインのすべてのURL。
301 | Moved Permanently | はい（永久） | 変更される可能性あり（POST→GET） | ドメイン移行、HTTPS切り替え、www/非www正規化、URL永久変更 |
302 | Found | いいえ（一時） | 変更される可能性あり（POST→GET） | 一時メンテナンスページ、ログインジャンプ、A/Bテスト、短期キャンペーンページ |
303 | See Other | いいえ（一時） | はい（強制GET） | POSTフォーム送信後の結果ページジャンプ、重複送信防止 |
307 | Temporary Redirect | いいえ（一時） | いいえ（元のメソッドを厳格に保持） | API一時リダイレクト、POSTデータを保持する必要のある一時ジャンプ |
308 | Permanent Redirect | はい（永久） | いいえ（元のメソッドを厳格に保持） | RESTful API永久移行、PUT/DELETEメソッドを保持する必要のある永久リダイレクト |
| 0ホップ（直接到達） | 影響なし、最適な状態 | 追加遅延なし | 現状を維持。内部リンクは直接最終URLを指すように |
| 1ホップ | PageRankは正常に伝達、SEO影響は無視できる | 約100-300msの遅延が増加（1回の往復） | 許容範囲。HTTP→HTTPSとドメイン正規化の一般的なホップ数 |
| 2ホップ | 重み伝達にわずかな減衰の可能性あり、クローラーは正常に追跡可能 | 約200-600msの遅延が増加 | 単一ホップに最適化することを推奨。内部リンクが中間ジャンプURLを指していないか確認 |
| 3ホップ | 重み伝達効率が低下、一部のクローラーは追跡を放棄する可能性 | 約300-900msの遅延が増加、LCPに影響が出る可能性 | 必須で最適化。リダイレクトルールを統合して直接最終URLに |
| 4-5ホップ | PageRankが明らかに減衰、インデックスに影響が出る可能性、クロール予算の浪費 | 500ms～1.5sの遅延が増加、LCPが基準超過の可能性大 | 緊急で修復。CDN/オリジン/アプリの多層リダイレクトの重ねがけを確認 |
| 6ホップ以上 | 深刻なリスク。検索エンジンが追跡を停止し、ページがインデックスから外れる可能性 | 遅延が1秒以上、ユーザーエクスペリエンスが極めて悪い | 直ちにループまたは設定エラーを調査し、リダイレクトルールを再構築 |
| ループ（ERR_TOO_MANY_REDIRECTS） | ページが完全にアクセス不能、検索エンジンがインデックスから削除 | ページが読み込めず、ブラウザがエラーを表示 | 最優先で修復。本ツールを使用してループノードを特定 |
| ERR_TOO_MANY_REDIRECTSループエラー、HTTP↔HTTPSが繰り返しジャンプする | CDN/ロードバランサーがHTTPでオリジンに戻し、オリジンサーバーがX-Forwarded-Protoヘッダーを正しく処理せず、常にHTTPSにリダイレクトする | Nginx設定に追加：set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } または$scheme変数をproxy_set_header X-Forwarded-Proto設定と併用 |
| wwwと非wwwが相互にジャンプしてループを形成する | CDN層でwww→非wwwのジャンプを設定し、オリジンのNginxで非www→wwwのジャンプを設定しているため、ルールが衝突している | 1つの正規化バージョンを選択（非wwwまたはwwwを推奨、一貫性を保持）、1層のみ（CDNまたはオリジン）でリダイレクトを設定し、他の層の対応ルールを削除 |
| リダイレクトチェーンが4-5ホップ経てから最終ページに到達する | HTTP→HTTPSジャンプ→非www→wwwジャンプ→末尾スラッシュ追加ジャンプ→旧パス→新パス、と多層ルールが重ねがけされている | リダイレクトルールを統合し、初期URLから直接最終URLに1ステップでジャンプさせる。Nginxではreturn命令を使用して一度に完全な最終アドレスにジャンプ |
| HTTPSサイトのリダイレクトチェーン内にHTTPノードが出現する（ダウングレード） | サーバー設定内にhttp://プレフィックスのリダイレクトターゲットがハードコードされているか、アプリがリダイレクトURLを生成する際にHTTPSであることを認識していない | アプリケーションがリバースプロキシを信頼し、X-Forwarded-Protoを正しく読み取るように構成；Nginxではhttps://の絶対URLまたは$scheme変数を使用（前提としてproxyが正しくschemeを設定していること）；HSTSを展開 |
| 301リダイレクトを修正したのにブラウザが依然として旧アドレスにジャンプする | ブラウザが301永久リダイレクトルールを長期的にキャッシュしており、F5更新では無効にならない | テスト段階では302一時リダイレクトを使用し、確認後に301に変更；ブラウザキャッシュをクリア（Chrome：設定→プライバシー→閲覧データを削除→キャッシュされた画像とファイル）；DevToolsのDisable cacheオプションを使用 |
| POSTリクエストがリダイレクト後にフォームデータが失われる | 301または302リダイレクトを使用しており、ブラウザが自動的にPOSTをGETリクエストに変更し、リクエストボディが破棄される | POST/PUT/DELETEなどの非GETリクエストについては、307（一時）または308（永久）リダイレクトに変更し、リクエストメソッドとリクエストボディを厳格に保持 |
| リダイレクト後のURLに%2520などの二重エンコーディング文字が出現する | URLパラメータが既に1回URLエンコードされているのに、サーバーがリダイレクト時に再度エンコードしてしまっている | リダイレクトロジックを確認し、URLのエンコードは1回のみにする；Nginxでは$uri（デコード済み）ではなく$request_uri（元のURI、デコードされていない）を使用 |
| AJAX/fetchリクエストがクロスドメインリダイレクト後にCORSエラーを報告する | クロスドメインリダイレクトのターゲットサーバーがCORSレスポンスヘッダー（Access-Control-Allow-Originなど）を構成していない | リダイレクトチェーン内の各ホップのサーバーがCORSヘッダーを正しく構成していることを確認；またはAJAXリクエストでクロスドメインリダイレクトを使用せず、フロントエンドがターゲットURLを取得してから直接リクエストする方式に変更 |
