リダイレクトチェッカー：301リダイレクトとチェーンを確認

リダイレクトチェッカーを使うと、リンクをクリックしてからページにたどり着くまでの間に実際に何が起きているかがわかります。 入力したURLはすべて、自動リダイレクトをオフにした状態でMarqlyのサーバーからリクエストされるため、 レスポンスが1つずつ記録されます。記録されるのは、ステータスコード、転送先を示す Location ヘッダー、 かかった時間、そしてSEOに関わるヘッダーです。続いてその転送先を追跡し、これを最大10回まで繰り返します。 これはGoogleのクローラーがデフォルトで使う上限と同じです。リダイレクトチェーン全体、最終URLとステータス、 そしてループ、一時的なリダイレクト、遅いホップ、失われたトラッキングパラメータ、まとめるべきチェーンについての わかりやすい警告が表示されます。

リダイレクトを確認する方法

1. 入力欄にURLを貼り付けます。一括チェックする場合は、1行に1つずつ最大10件のURLを貼り付けます。
2. 必要に応じてユーザーエージェントを選びます。デフォルトではMarqlyチェッカーとして名乗ります。 Chrome、iPhoneのSafari、Googlebot（スマートフォン）、Googlebot（パソコン）のユーザーエージェントも送れるので、 ブラウザ、スマートフォン、クローラーで扱いを変えているルールを見つけられます。
3. http/https と www あり/なし のバージョンもまとめて確認する にチェックを入れると、 同じアドレスの4つの形を一度にテストできます。サイトの正規ホスト名が1つに決まっていて、 どのバリエーションも1ホップでそこに到達するかを確かめる最も手早い方法です。
4. リダイレクトをチェック を押します。URLごとにカードが表示され、判定、ヒント、ホップごとのチェーンを確認できます。
5. テキストのレポートには 結果をコピー、ホップごとに1行のスプレッドシートには CSVをダウンロード、 同じチェックを再実行できるリンクを送るには 共有リンクをコピー を使います。

結果の見方

各カードの先頭には、最終ステータスコード、入力したURL、リダイレクト回数、合計時間、最終URLが表示されます。 その下のヒントでは、注意すべき点を示します。エラー（ループ、上限を超えるチェーン、404で終わるチェーン）から、 警告（一時的なリダイレクト、meta refresh、httpsからhttpへのダウングレード、失われたクエリパラメータ、 最終ページの X-Robots-Tag: noindex）、さらに中立的な情報（末尾スラッシュやwwwの変更、別ドメインへの移動、遅いホップ）までが対象です。 なお、これらのヒントの文言とサーバーからの一部のエラーメッセージは、現在のところ英語で表示されます。

チェーンの表には、すべてのリクエストが順番に並びます。ステータス はサーバーが返したHTTPステータスコードです。URL はリクエストしたアドレスで、その下に、そのホップがクライアントを次に送る先が表示されます。 サーバーが相対パスの Location を返した場合も、絶対URLに変換済みです。時間 は、そのホップでサーバーがヘッダーを返すまでにかかった時間です。 各行の ヘッダー を開くと、Location、Cache-Control、Content-Type、X-Robots-Tag、Link（canonicalを宣言できる場所）、Strict-Transport-Security、X-Redirect-By（WordPressや一部のプラグインはここに自分の名前を入れます）、Server を確認できます。 Cookieの値は表示せず、設定されたCookieの数だけを示します。

301・302・307・308の違い：リダイレクトのステータスコードの意味

HTTPのリダイレクト用ステータスコードはRFC 9110の15.4節で定義されています。 違いを分けるのは2つの問いです。移動は恒久的か、そしてリダイレクトを追跡するときにクライアントがリクエストメソッドを 変えてよいか（たとえばフォームのPOSTをGETにしてよいか）です。GoogleのHTTPステータスコードに関するドキュメントでは、Googleのクローラーとインデックス登録がそれぞれをどう扱うかが説明されています。

通常のページでは、コンテンツが恒久的に移動したときに 301 を使います。スラッグの変更、記事の統合、 ドメイン移行、HTTPSへの切り替えなどです。メンテナンスページ、短期キャンペーン、テストのように元のURLが戻ってくる場合は302 か 307 を使います。APIのエンドポイントやPOSTリクエストを受けるフォームのように メソッドが重要な場合は 308 を選びます。RFC 9110では、301と302ではリダイレクトされたPOSTをGETに変えることが クライアントに認められていますが、307と308では禁止されているためです。

meta refreshとJavaScriptリダイレクト

Googleのリダイレクトに関するガイドでは、 可能な限りサーバーサイドの永続的なリダイレクトを使うよう勧めています。Google検索は、即時のmeta refreshを永続的なリダイレクト、 遅延型のmeta refreshを一時的なリダイレクトとして解釈します。JavaScriptリダイレクトは、サーバーサイドのリダイレクトもmeta refreshも 使えない場合に限って勧められています。レンダリングが失敗する可能性があるためです。このチェッカーはmeta refreshタグとRefresh ヘッダーを追跡してラベルを付けますが、JavaScriptは実行しません。

リダイレクトチェーンとは？なぜ問題になるのか

リダイレクトチェーンとは、ホップが2つ以上ある経路のことです。たとえば http://example.com/page →https://example.com/page → https://www.example.com/page →https://www.example.com/page/ のような形です。チェーンが意図して作られることはほとんどありません。 サイトのHTTPS化、wwwの有無の統一、CMSの乗り換え、セクション名の変更を重ね、古いリダイレクトを書き直さずに さらにリダイレクトしていくうちに積み重なっていきます。1つひとつは単独で動いていても、重なると影響が大きくなります。

• 表示速度：ホップが1つ増えるごとに、ページの読み込みが始まる前に完全なリクエストが1回増えます。 別のホスト名へのホップでは、さらにDNSの名前解決とTLSハンドシェイクが加わります。時間の列で、各ホップのコストを確認できます。
• クロール：Googleによると、Googleのクローラーはデフォルトで最大10回のリダイレクトホップを追跡します。 ページのインデックス登録レポートでは、長すぎるチェーン、リダイレクトループ、チェーン内の不正なURLや空のURLがリダイレクトエラーとして表示されます。 Googleのサイト移転ガイドは、 最終的な宛先へ直接リダイレクトし、それができない場合でもチェーン内のリダイレクトを5個未満（理想的には3個以下）に抑えるよう勧めています。 チェーンはユーザーにとってレイテンシを増やし、長いチェーンに対応していないユーザーエージェントやブラウザもあるためです。
• ほかのクライアント：RFC 9110には、以前のHTTP仕様ではリダイレクトの上限として5回が推奨されていたこと、 そして今でもそのような固定の上限を設けているクライアントがありうることが書かれています。 Googlebotが許容するチェーンでも、ほかのソフトウェアでは失敗することがあります。
• 壊れやすさとデータの損失：ホップが増えるたびに、編集・削除・上書きされうるルールが1つ増えます。 URLを組み立て直すホップは、クエリ文字列を黙って落とすことがあります。こうしてUTMタグが、アクセス解析に届く前に消えてしまいます。 このチェッカーは、元のURLにあったパラメータが最終URLから消えている場合に警告します。

リダイレクトチェーンを解消する方法

1. 最終URLを特定する：旧URLをチェッカーにかけ、チェーンの最後のURLをコピーします。
2. 最初のリダイレクトを最終URLに向ける：AがBへ、BがCへリダイレクトしているなら、Aのルールを直接Cへ向け、 Bをまだ持っている人のためにB → Cは残します。リダイレクトマップやプラグインでは、転送先そのものが別のルールの転送元になっている ルールを探してください。
3. プロトコルとホスト名のルールをまとめる：最もよくあるチェーンは、http → https のあとに www なし → www が続くものです。 次のnginxの例のように、どのバリエーションも1ステップで正規の形へ送る1つのルールにまとめます。

# どのバリエーションからも1ホップで https://www.example.com へ
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate の行は省略
    return 301 https://www.example.com$request_uri;
}

4. リンク元を更新する：内部リンク、canonicalタグ、hreflangアノテーション、XMLサイトマップを最終URLに書き換えます。 Googleのサイト移転ガイドでも、内部リンクを新しいURLに更新するよう求めています。リダイレクトは外部からの古いリンクを受け止めるためのもので、 自サイトのナビゲーションを支えるためのものではありません。
5. リダイレクトは残しておく：Googleは、リダイレクトをできるだけ長く（一般的には1年以上）保持するよう勧めています。 チェーンをまとめるとは、転送先を付け替えることであって、古いルールを削除することではありません。
6. 再テストする：同じURLをもう一度、できればバリエーションのオプションをオンにして確認し、どれも1ホップで200のページに着くことを確かめます。

リダイレクトループを直すには

ループとは、すでに訪れたURLに戻ってくるチェーンのことで、いつまでも終わりません。ブラウザには「リダイレクトが多すぎます」という エラーが表示されます。よくある原因は、2つのレイヤーの食い違いです。CDNがオリジンとHTTPで通信しているのにオリジンがHTTPSを強制している、 Webサーバーの末尾スラッシュのルールとアプリケーション側の逆のルールがぶつかっている、wwwのルールがDNSレベルの転送とサイトの両方に 設定されている、といったケースです。URLが元に戻るホップを見てください。その Server ヘッダーや X-Redirect-By ヘッダーから、 どのレイヤーが送ったのかがわかることがよくあります。Cookieがないときだけ起きるループ（同意画面やログインのリダイレクト）もあり、 すでにCookieを持っている訪問者には影響しません。チェッカーはCookieを送らないので、こうしたループも見つけられます。

リダイレクトを一括でチェックする

1行に1つずつ最大10件のURLを貼り付ければ、一度にまとめて確認できます。重複は取り除かれ、URLごとに結果が表示されます。 CSVエクスポートはホップごとに1行で、入力したURLが各行に入るため、ステータスで絞り込んだり、ホップ数で並べ替えたり、 リダイレクトのルールを管理している担当者にそのまま渡したりできます。チェックしたいリンクがブラウザの古いブックマークなら、 先にブックマーク整理ツールで一か所にまとめておくと、手元に何があるかを把握してから 移転したものを直せます。サイト全体を調べる場合は、クローラーやサーバーログでリダイレクトされているURLを洗い出し、 重要なものをここでGooglebotのユーザーエージェントを使ってスポットチェックしてください。

HTTPS、www、末尾スラッシュ

ほとんどのサイトは、プロトコルとホスト名の組み合わせを1つに決めて応答し、それ以外の形はすべて1ホップで恒久的にそこへリダイレクトするべきです。 バリエーションのオプションは、http://example.com、https://example.com、http://www.example.com、https://www.example.com を同じパスで確認し、4つすべてが同じURLに着くか、それぞれ何ホップかかるかを報告します。 ヒントでは、チェーンの後半になってようやくHTTPSに切り替わるケース、wwwあり・なしを2回以上行き来するチェーン、 末尾スラッシュの追加・削除や大文字・小文字の変更だけを行うホップを指摘します。いずれも最初のリダイレクトに簡単にまとめられます。

ブラウザと結果が異なる理由

ブラウザが別の場所に着く場合、たいていは何かを記憶しています。RFC 9110は301のキャッシュを認めているため、ブラウザが古いリダイレクトを 飛ばしたり、すでに削除したリダイレクトをたどり続けたりすることがあります。サイトのHSTSヘッダーを一度受け取ったブラウザ （またはHSTSプリロードリストに載っているサイト）では、リクエストがパソコンから出ていく前に、ブラウザ内部で http:// がhttps:// に置き換えられます。Cookie、言語、地域が独自のリダイレクトを引き起こすこともあります。 チェッカーは毎回まっさらな状態から始め、サーバーが送ってきた内容を報告します。これはクローラーや初めての訪問者にとって重要な見え方です。

チェッカーの仕組み

各ホップは、Cloudflare上のMarqlyのサーバーから、リダイレクトを手動に設定した GET リクエストとして送られます。 そのため、チェッカーが記録するまでは何も追跡されません。ホスト名はすべて名前解決され、公開アドレスを指している必要があります。 プライベートネットワーク、localhost、クラウドのメタデータアドレスは、チェーンの途中でリダイレクトがそれらを指した場合も含めて拒否されます。 各ホップのタイムアウトは6秒で、チェーン全体は20秒または10回のリダイレクトで打ち切られます。ページ本文は破棄され、 最終的なHTMLページの先頭64 KBだけがmeta refreshの有無を調べるために読み込まれます。何も保存されず、結果はお使いのブラウザのタブの中にだけ存在します。

キャンペーン用のリンクを作るなら、UTMパラメータ作成ツールでリンクを作り、 このチェッカーでパラメータがすべてのホップを通り抜けて残るかを確認できます。マーケティング担当者がリンクやランディングページ、 資料をまとめて管理する方法はマーケター向けのMarqlyで紹介しています。 参考にしたい記事や事例はコンテンツキュレーションのやり方で集めておくと、URLが変わっても探し直せます。