URLリダイレクトチェーンチェッカー

URLを入力して、そのリダイレクトチェーンを追跡し、HTTPステータスコード、リダイレクション、および全体の読み込み時間を分析します。

https://example.com

URLリダイレクトチェーンチェッカーの使い方

1
URL を入力する
調べたい完全な URL を、http:// または https:// を含めて入力するか貼り付けます。
2
リダイレクトをチェックする
「Check Redirects」をクリックして URL をたどり、すべてのホップを最終的な宛先まで追跡します。
3
リダイレクトチェーンを読む
各ステップ、その HTTP ステータスコード(301 や 302 など)、チェーン全体の合計時間を確認します。

4
SEO の評価に基づいて対処する
ホップが多すぎる、チェーンが遅い、一時的なリダイレクト、エラーコードなどを指摘する「SEO Impact」パネルを使って、問題を修正します。

リダイレクトの仕組みと、チェーンが害になる理由

リダイレクトとは何か、そしてチェーンはどう形成されるのか

リダイレクトとは、ブラウザがリクエストした URL がいまは別の場所にあることを伝える、サーバーからの指示です。サーバーは 3xx ステータスコードと、新しいアドレスを示す Location ヘッダーで応答し、ブラウザは自動的にそのアドレスへリクエストし直します。リダイレクトチェーンは、あるリダイレクトの転送先がそれ自体またリダイレクトになっているときに生じます。ブラウザは A をリクエストすると B へ送られ、その B からさらに C へ送られ、ようやく C で実際のページにたどり着く、という具合です。この経路の矢印の一本一本が、サーバーへの別々の往復になります。

チェーンはたいてい、時間とともに偶発的に積み重なっていきます。サイトが http から https へ移り、後で non-www から www へ切り替え、さらに URL のパス構成を変更する。こうした変更を一つひとつ統合せずに前のものの上へ重ねていくと、たった 1 本の古いリンクが、たどり着くまでに 3 段も 4 段もホップを跳ね回ることになりかねません。このチェッカーはすべてのホップを追跡し、経路の全体を表示するので、チェーンがどれだけ伸びてしまったかを正確に確認できます。

301 と 302 ― 恒久的と一時的

最もよく使われる 2 つのリダイレクトコードは、まったく異なる意味を持ちます。301 は恒久的なリダイレクトです。移転が最終的なものであることをブラウザと検索エンジンに伝えるので、ブックマークは更新され、古い URL に蓄積されたランキングシグナルが新しい URL へ引き継がれ、転送先がインデックスされます。302 は一時的なリダイレクトです。元の URL がいずれ戻ってくると示すため、検索エンジンはふつう元の URL をインデックスに残したまま、ランキングシグナルの引き継ぎには慎重になります。実際には恒久的な移転に 302 を使うのは典型的な SEO の失敗で、リンクの評価が古い URL に取り残されてしまいます。

目安はシンプルです。廃止したページや移転したドメインのように変更が恒久的なら 301 を使います。季節限定のキャンペーン、A/B テスト、メンテナンスページのように本当に一時的なら 302 を使います。長く使うリダイレクトで迷ったときは、ほぼ必ず 301 が正解です。

307 と 308 ― 厳格な新しいコード

HTTP はその後、古くからの曖昧さを取り除くために 307 と 308 を追加しました。元の 301 と 302 のコードは、リダイレクト時に POST リクエストを GET に変えてしまう形で広く実装されていました。これはページの移転にはたいてい好都合ですが、フォーム送信や API には誤った挙動です。308 は 301 と同じく恒久的なリダイレクトですが、HTTP メソッドと本文が保持されることを保証します。307 は 302 の一時的版で、同じ保証を備えています。通常のページのリダイレクトでは、308 の実際の SEO 上の効果は 301 と同じで、307 は 302 と同じです。

307 に出会う場面はおもに 2 つあります。ブラウザが内部的に http を https へ格上げする際に HSTS プリロードが発行するリダイレクトと、リクエストメソッドの保持が重要になる API のトラフィックです。コンテンツの URL については、恒久的な移転に 301 を使い続けるのが、慣例的でよく理解された選択肢であることに変わりはありません。

チェーンとループが害になる理由

チェーン内のホップは一つひとつが完全なリクエストとレスポンスのやり取りであり、その遅延は積み重なっていきます。とりわけ往復時間の長いモバイルネットワークでは、余分なリダイレクト 1 つごとに、ユーザーが何かを目にするまでに数百ミリ秒が上乗せされることもあります。チェーンはクロールバジェットも浪費します。検索エンジンが 1 サイトあたりに費やせるリクエスト数には限りがあり、それを A から B、C、D とたどることに使ってしまえば、本当のコンテンツをクロールするための余力がそれだけ減ります。さらに、ランキングシグナルが長いチェーンの途中でわずかに失われ、最終ページへきれいに流れ込まないという証拠もあります。

リダイレクトループは、その病的な極端例です。A が B を指し、B が A を指し返すため、ブラウザはあきらめて ERR_TOO_MANY_REDIRECTS のようなエラーを表示するまで堂々巡りを続け、ページにはまったくたどり着けなくなります。このチェッカーは、長すぎるチェーン、遅いチェーン、意図しない可能性のある一時的なリダイレクト、経路上のエラーステータスコードを指摘するので、これらの不具合の一つひとつが隠れずに表面化します。

チェーンを 1 ホップに平坦化する

チェーンの修正方法は、すべての起点が 1 ホップで最終的な転送先へ直接リダイレクトするようにすることです。A が B を経て C へ向かっているなら、A のルールを更新して C へ直行させ、B の中継を取り除きます。Apache では、.htaccess やサーバー設定のリダイレクトルールを編集して、転送元が最終的なターゲットに対応づくようにします。Nginx では、rewrite や return ディレクティブを更新します。目指すのは、どのリダイレクトの転送先もそれ自体がリダイレクトにならない状態です。

リダイレクトは定期的に監査しましょう。サイトが進化するにつれて、チェーンはまた忍び込んでくるからです。移転や HTTPS 化、URL の再構成を行ったあとは、最も重要な入口の URL をあらためて追跡し、それぞれが 1 回の 301 で正規のページへ解決することを確認します。外部の被リンクに現れる URL には特に注意してください。それらは最も多くのリンク評価を運んでおり、きれいな直接リダイレクトの恩恵を最も大きく受けるからです。

正規化 ― どのサイトにも必要なリダイレクト

リダイレクトの問題の大半は、正規化 ― URL のあらゆる変種を 1 つの正規形へ集約する取り組み ― に行き着きます。その軸は 4 つあります。プロトコル(http か https か)、ホスト(www か non-www か)、末尾のスラッシュ(パスの最後にスラッシュが付くか付かないか)、そして大文字・小文字です。これらのあらゆる組み合わせでサイトにアクセスできてしまうと、検索エンジンには重複コンテンツと映り、リンクのシグナルが変種ごとに分断されてしまいます。その対処法が、各変種を 1 つの好ましい URL へまとめる一連の 301 リダイレクトです。

肝心なのは、これらをチェーンにせず 1 ホップにまとめることです。http://example.com を https://example.com へ、さらに https://www.example.com へと送るのは、1 回で済むところを 2 回リダイレクトしています。いくつの軸が誤っていようと、正規でないリクエストはどれも 1 回の 301 で完全な正規 URL に着地するよう、ルールを設定しましょう。それが実現しうる最もきれいな結果であり、このチェッカーが良い習慣として表示するものです。

メタリフレッシュと JavaScript リダイレクト

すべてのリダイレクトが HTTP レベルで起こるわけではありません。メタリフレッシュによるリダイレクトは、HTML の meta http-equiv="refresh" タグを使い、一定の遅延のあとブラウザを別の場所へ送ります。JavaScript リダイレクトは、スクリプトから window.location を変更します。どちらもユーザーにとっては機能しますが、SEO の面では劣ります。動作が遅く、検索エンジンはサーバー側の 301 ほど確実には扱わず、遅延のあるメタリフレッシュは唐突に感じられたり、質の低い体験として指摘されたりすることさえあります。さらに、リダイレクトはページ本文の読み込み後に決まるため、HTTP レベルのリダイレクト追跡には現れません。

サーバーを自分で制御できる場合は、メタリフレッシュや JavaScript リダイレクトよりも、本物の HTTP 301 を選びましょう。クライアント側のリダイレクトは、サーバーを本当に設定できない場合のために取っておきます。このチェッカーはサーバーが発行する 3xx レスポンスをたどるため、ブラウザではリダイレクトするように見えるのにここでは直接の 200 と表示されるページは、リダイレクトがクライアント側で起きており、サーバー側へ移すべきだという強いヒントになります。

よくある質問

リダイレクトチェーンチェッカーは何を表示しますか?

URL をすべてのリダイレクトのホップを通じてたどり、各ステップの HTTP ステータスコード、最終的な到達 URL、リダイレクトの総数、チェーンの累積読み込み時間を報告します。

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

余分なホップごとに遅延が増え、リンクの評価が薄まることがあります。ツールはリダイレクトが多すぎるチェーン、合計時間が遅いもの、一時的な (302) リダイレクト、エラーステータスコードを指摘するので、可能な限り単一の 301 に短縮できます。

301 リダイレクトと 302 リダイレクトの違いは何ですか?

301 は恒久的なリダイレクトで、SEO の価値のほとんどを新しい URL に引き継ぎます。302 は一時的なもので、価値を完全には引き継がないことがあります。チェッカーは、本来恒久的であるべきだった場合に備えて、302 が検出されると警告します。

http または https を含む完全な URL を入力する必要がありますか?

はい。チェッカーはプロトコルを含む完全な URL を必要とします。http:// または https:// を省くと、有効で完全な URL を入力するよう求められます。

ツールは無料ですか?URL をサーバーに送信しますか?

登録不要で無料です。他のドメインをまたぐリダイレクトをたどるため、入力した URL は当サイトのサーバー経由でチェックされ、サーバーが代わりにリダイレクトを取得してその追跡結果を返します。