↪️ リダイレクトチェーン追跡
URL を入れるとリダイレクトを 1 ホップずつ追跡し、ステータスコード・所要時間・HTTP/HTTPS の遷移・ループ・過剰なホップを検出します。
完全無料
登録不要
サーバー処理
ログ・DB 保存なし
レート制限あり
5 言語対応
ダークモード
📚 リダイレクトのベストプラクティス
• SEO 上、リダイレクトは 3 ホップ以内が理想。Google は 5 ホップを超えると追跡を停止する場合あり。
• 永続的リダイレクトは 301、一時的は 302 / 307 を使う。
• HTTPS → HTTP のダウングレードは絶対に避ける。
• リダイレクトループは即座に修正すべき重大バグ。
📖 この診断で分かること
この診断は入力された URL から Location ヘッダーを順に辿り、各ホップのステータスコードと遷移先、最終的な到達先を表示します。実際のユーザーが体験するホップ数とは一致しないことがあります。HSTS が効いているブラウザでは HTTP から HTTPS への 1 ホップ目がネットワークに出る前に内部処理で置き換わりますし、Cookie や地域による出し分けを行っているサイトでは経路そのものが変わります。
| 判定項目 | 何を見ているか | 引っかかったときの対処 |
|---|---|---|
| 301 / 302 と 307 / 308 の使い分け | 301 と 302 は歴史的経緯から、リダイレクト時にブラウザが POST を GET に変えてしまうことが許容されています。307 と 308 はメソッドとリクエストボディをそのまま維持します。フォームの送信先や API のエンドポイントを 301 で移すと、body が消えたリクエストが届くという原因の分かりにくい障害になります。 | 恒久移転で GET しか来ないページなら 301、POST を受けるエンドポイントなら 308 を返します。一時的な切り替え（メンテナンス画面、A/B テスト）は 302 ではなく 307 を選ぶと、メソッドが変わらないぶん事故が減ります。 |
| ホップが 2 段になっている | http://example.com → https://example.com → https://www.example.com のように、HTTPS 化と www 正規化を別々のルールで書くと必ず 2 ホップになります。末尾スラッシュの有無を直すルールが加わると 3 ホップです。ホップごとに往復が発生するので、モバイル回線では体感でわかるほど遅くなります。 |
最初のルールで最終形（スキーム・ホスト・末尾スラッシュまで含めた形）へ一度に飛ばします。nginx なら return 301 https://www.example.com$request_uri; を listen 80 のサーバーブロックに 1 行書くだけで済みます。個別のリダイレクトを積み重ねる書き方は、増えるほど順序依存が読めなくなります。 |
| 最終到達先が canonical と違う | リダイレクトの終点と、そのページが宣言している canonical が食い違っていると、Google はどちらを正規と見なすか自分で決めます。Search Console に「ページにリダイレクトがあります」「Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」が並ぶのはこの状態です。 |
終点のページの canonical が自分自身の URLを指しているかを確認します。末尾スラッシュ・大文字小文字・トラッキングパラメータの有無まで完全一致させてください。サイト移転では「旧 URL → 新 URL の 1 対 1」が原則で、まとめてトップページへ飛ばすと Google はそれを 404 相当（ソフト 404）として扱います。 |
リダイレクトは消してよいものではありません。旧 URL への外部リンクと、まだ更新されていないブックマークは何年も残ります。Google 自身も、サイト移転時のリダイレクトは最低 1 年は維持することを推奨しています。当サイトも旧ドメインからの 301 を 1 年以上維持する方針で運用しています。到達先が 404 になっているリダイレクトが残っていないか、移転から数か月後にもう一度この診断を通してください。