リダイレクトチェーンとは、誰かがリクエストした URL と、最終的に 200 で応答するページの間に、2回以上のリダイレクトが連続することです。Google は、Googlebot が最大 10 ホップまでたどること、最終的な転送先へ直接リダイレクトすることを推奨していること、そして長いチェーンがクロールの足かせになることを文書化しています。ランキングを破壊するとは述べておらず、恒久的なリダイレクトでは PageRank の損失は生じないとも述べています。したがって、率直なまとめとしては、チェーンは、SEO 上の大惨事ではなく、安く直すべきレイテンシとクロール効率の問題です。
ほとんどのチェーンは、意図して作られるものではありません。誰かが HTTPS のルールを追加し、別の誰かが www のルールを追加し、マーケティングツールがリンクをトラッカーで包み、各ホップは、それ単体なら妥当です。以下では、層がどう積み重なるか、各ホップが何を犠牲にするか、どの SEO の主張が Google のドキュメントに照らして成り立つか、そしてチェーンの追跡と平坦化の方法を説明します。まずステータスコードの用語を知りたい場合は、URL リダイレクトの種類が地図になります。チェーンが自分自身に戻ってループしているなら、代わりにリダイレクトループの修正方法が必要です。
リダイレクトチェーンとは
リダイレクトチェーンは、URL A が C を直接指す代わりに、A が B にリダイレクトし、B が C にリダイレクトするときに起こります。それぞれの矢印は独立した HTTP レスポンスで、クライアントはそのたびに新しいリクエストを行います。リダイレクト1回は普通で、「チェーン」は2回から始まります。
複数のリダイレクトとリダイレクトのホップは、同じものを別の角度から表した言葉で、リクエストから最終ページまでのリダイレクトの数です。リダイレクトループは、URL に再訪するために終わらないチェーンです。それに対し、チェーンは終わります。そこに着くまでに時間がかかりすぎるだけです。
リダイレクトチェーンが生まれる仕組み
チェーンが積み重なるのは、各層が独自の好みを強制するからです。リクエストが出会う順に、よくある層は次のとおりです。
- スキーム。
http://がhttps://に向かいます。通常はサーバーやプロキシのルールです。 - ホスト。 アペックスが
wwwへ、またはその逆に向かいます。スキームのルールの後に発動する、別のルールです。 - パス。 末尾スラッシュや小文字化の正規化処理が、
/Promo/を/promoに書き換えます。 - キャンペーンまたはトラッキングのラッパー。 広告のクリックトラッカー、メールプラットフォームのリンク書き換え、あるいはショートリンクが、他のすべての前に置かれます。
- 旧来のマップ。 過去のリニューアルで作られ、誰も向け直さなかったリダイレクトです。
これらを合わせると、単純な http://example.com/Promo/ が4ホップかかることがあります。HTTPS へ、次に www へ、次に正規化されたパスへ、そして古いリニューアルのルールを経て、公開中のページへです。ショートリンクは先頭に加わります。1つなら正当なホップです。害が始まるのは、その転送先が最終的な URL ではない場合です。ターゲットとして http://example.com/promo を貼り付けると、あなたのリンクは、転送先のサイトが気づかないうちに作ったチェーンの先頭に立ちます。URL 短縮ツールは SEO に悪影響を与えるかでは、この問いのランキング面を扱っています。短く答えると、きれいな1ホップなら問題なく、積み重なったものは自分で直すべきものです。
チェーンは、見逃しやすいものです。ブラウザがそれを隠すからです。アドレスバーには最終的な URL が表示され、ページが読み込まれるので、何もおかしく見えません。また、すべてのルールに引っかかるリクエストの変種、通常は最も古い印刷物にある最も古い http:// のリンクでしか、表面化しません。
Googlebot は何ホップまでたどるか
Googlebot は、既定では最大 10 回のリダイレクトのホップをたどります。これは Google のクローラーのドキュメントそのままです。さらに、Google の特定のプロダクトでは異なる上限を使う場合があること、URL 検査ツールはリダイレクトをまったくたどらないことも、付け加えられています。それより長いチェーンでどうなるかは、Google は明記していないので、単にターゲットに到達しないと想定してください。
10 は上限であり、推奨ではありません。Google のサイト移転に関する指針は、最終的な転送先へ直接リダイレクトし、それができない場合は、チェーンを短く、「理想的には 3 以下、少なくとも 5 未満」に保つよう述べています。チェーンはユーザーのレイテンシを増やし、すべてのユーザーエージェントが長いチェーンに対応しているわけではないからです。つまり、目標は1ホップ、許容は数ホップ、そして 10 で厳格に停止、ということです。
ブラウザには独自の上限があります。Chrome は 20 で諦め、ERR_TOO_MANY_REDIRECTS を返します。これは、リダイレクトループのガイドで扱っている症状です。HTTP の標準も、数字を定めていません。RFC 9110 は、クライアントが循環するリダイレクトを検出して介入すべきだと述べているだけです。
各ホップのレイテンシのコスト
どのホップも、少なくともネットワークの往復1回分のコストがかかります。別のホスト名へのホップは、さらにコストがかかります。クライアントは、新しい名前を解決し、TCP 接続を開き、TLS ハンドシェイクを完了してからでないと、何も送れないからです。Lighthouse 自身の監査は、リダイレクトが2回以上あるページを不合格とし、余分な往復がリソースを「数百ミリ秒」遅らせる可能性があると述べています。
計算を示します。ベンチマークではなく、説明のための例です。往復を 100 ms とします。これは、電波が中程度のモバイル回線では普通です。リクエストの前に、DNS、TCP、TLS 1.3 のハンドシェイクが必要な、新しいホストへのホップは、3 から 4 往復、つまり 300 から 400 ms かかっても不思議ではありません。同じホストへの開いている接続を再利用するホップは、1往復で、100 ms です。すると、新しい接続が2回ある4ホップのチェーンは、本来のページが始まる前に約 900 ms を費やし、平坦な1回のリダイレクトなら約 450 ms です。
モバイルでは、単純な理由で状況がさらに悪化します。制約は帯域幅ではなくレイテンシだからです。リダイレクトのレスポンスはごく小さいため、待ち時間はすべて往復であり、速いプランに変えても何も変わりません。画像を縮めるより、ホップを1つ削除するほうが安いことがよくあります。サーバー側で1ホップがどれだけのコストであるべきかは、リダイレクトを 15 ms 未満に抑える方法を参照してください。
チェーンは、データも失います。各ホップは、書き換えルールがクエリ文字列を落とす可能性のある場所であり、utm_source が取り除かれるのは、UTM パラメータがアナリティクスから消えるときの、よくある原因です。
リンクエクイティとクロールバジェット:Google が文書化していること
まずリンクエクイティです。Google のサイト移転のドキュメントは、「301 などの恒久的なリダイレクトでは PageRank の損失は生じない」と述べています。Google の Gary Illyes も 2016 年に、30x のリダイレクトについて同じことを述べましたが、それはドキュメントではなく、ソーシャルでの投稿でした。そのため、リダイレクトの各ホップが一定の割合のエクイティを失わせるという昔の経験則は、俗説です。割合を示す Google の情報源はなく、15 パーセントのような数字が、引用元なしで SEO の記事に繰り返し現れます。誰かが数字を挙げたら、出典を尋ねてください。
それでも、チェーンは無料ではありません。2つの影響が文書化されています。1つ目は、クロール効率です。大規模サイト向けの Google のクロールバジェットの指針は、長いリダイレクトチェーンはクロールに悪影響を与えるため、避けるようはっきり述べています。2つ目は、先述のユーザーのレイテンシで、ページエクスペリエンスのシグナルに影響します。クロールバジェットが重要になるのは主に、非常に大規模なサイトや、頻繁に更新されるサイトです。200 ページのサイトが、いくつかのチェーンでクロールバジェットの問題を感じることはまずありませんが、訪問者は速度のコストを感じます。
インデックスに関する微妙な点もあります。Google は、恒久的なリダイレクトを、転送先の正規化のシグナルとして使います。どの URL が表示されるかは、一部には、各リダイレクトが一時的か恒久的かに左右されます。301 と 302 のホップが混在するチェーンでは、そのシグナルが不明瞭になり、コードを一度で決めておくべき十分な理由になります。それらのシグナルがどう相互作用するかは、canonical と 301 リダイレクトで扱っています。
私の立場はこうです。エクイティについて慌てず、速度とクロールの衛生のためにチェーンを直し、1つを平坦化したことによるランキングの上昇を約束しないことです。そのような上昇を文書化した人はいません。測定できるのは、読み込みが速くなることと、無駄な取得が減ることです。
リダイレクトチェーンの検出方法
まず curl から始めましょう。ブラウザが隠すすべてのホップを出力してくれるからです。最初のコマンドは、各レスポンスのステータス行と Location を表示します。
curl -sIL http://example.com/Promo/ | grep -E '^HTTP|^[Ll]ocation'
きれいな結果は、3xx が1つ、その後に 200 です。チェーンでは、先に 3xx の行が2つ以上現れます。ホップ数と、リダイレクトに費やされた時間を知るには、curl 自身の数値を出力させます。
curl -sL -o /dev/null \
-w 'hops: %{num_redirects}\nfinal: %{url_effective}\nredirect time: %{time_redirect}s\ntotal: %{time_total}s\n' \
http://example.com/Promo/
2つの注意点があります。-I は HEAD リクエストを送りますが、一部のサーバーは HEAD に対して GET と異なる応答をするため、結果がきれいすぎる場合は、-I なしで繰り返し、-o /dev/null -D - でボディを捨ててください。そして、すべてのルールを発動させる、最悪のケースの変種をテストしてください。http://、www なし、大文字のパス、末尾スラッシュです。正規の URL だけをテストするから、チェーンが生き残ります。きれいな変種を信じるより、醜い変種を過剰にテストするほうがよいと考えています。
ブラウザでは、開発者ツールを開き、ネットワークパネルで「Preserve log」(ログを保持) にチェックを入れて、以前のホップが遷移後も残るようにして、再読み込みします。各リダイレクトが、それぞれ 301 または 302 の行として表示されます。私たちのリンクチェッカーは、ターミナルなしで同じチェーンを表示します。
サイト全体を監査するには、Screaming Frog や Sitebulb のようなデスクトップのクローラーに、各チェーンをすべてのホップとステータスコードとともに一覧にする、リダイレクトチェーンのレポートがあります。長く使われるリンクについては、リンクのリダイレクトの監視のように、同じ追跡を定期ジョブに組み込んでください。
リダイレクトチェーンの平坦化の方法
平坦化とは、古い URL がすべて、最終的な URL を直接指すようにすることです。手順は次のとおりです。
- 正規の形を選びます。スキーム、ホスト、末尾スラッシュの方針、大文字小文字です。それを書き留めます。
- 古い URL をそれぞれ追跡し、最終的な転送先を記録します。
- すべてのルールを、次のルールではなく、その最終的な転送先を指すように書き換えます。
- 内部リンク、サイトマップ、
rel="canonical"タグを最終的な URL に更新し、クローラーとユーザーが、そもそもチェーンに入らないようにします。 - 追跡をやり直し、多くても1ホップであることを確認します。
サーバー側の工夫は、スキームとホストを1つのルールにまとめることです。nginx では、次のようになります。パスとクエリ文字列を残すために $request_uri を使っています。
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 and key directives go here
return 301 https://www.example.com$request_uri;
}
これで、http://example.com/page へのリクエストは、1ホップで https://www.example.com/page に向かいます。2つのルールなら、2ホップになったところです。Apache とアプリケーションレベルでの同等の方法は、.htaccess でリダイレクトを設定すると URL をリダイレクトする方法で扱っています。
まず 302 でテストしてください。ブラウザは 301 を積極的にキャッシュするので、間違いが長く残ります。チェーンが1ホップになったら、恒久的なコードに切り替えます。HSTS も役立ちます。ブラウザが Strict-Transport-Security ヘッダーを一度見た後は、http:// を内部的に https:// へアップグレードするため、再訪問者はそのホップをまるごとスキップします。ただし、クローラーや初回の訪問者には何の効果もないため、1ホップのルールを補完するものであり、置き換えるものではありません。
チェーンが繰り返し現れるなら、原因は構文ではなくプロセスです。リンク腐敗の防止では、古いマップが積み上がらないようにする監査の習慣を説明しています。
行儀のよいショートリンクのリダイレクトとは
ショートリンクは、スラッグから最終的な正規のページまで、ちょうど1ホップであるべきで、それ以外は不要です。リクエストは短いドメインに届きます。レスポンスは、転送先を Location に持つ 3xx です。転送先は直接 200 で応答します。中間の短縮ツールも、再びリダイレクトするトラッカーも、古い形を貼り付けたために www や HTTPS へホップする転送先もありません。
コードは、用途によって決まります。
302(または307) は、キャンペーン、ソーシャルの投稿、メール、QR コードでの、追跡する編集可能なリンクに使います。後から転送先を向け直すことができ、すべてのクリックがリダイレクト層に届くため、分析が完全に保たれます。301(または308) は、移転が恒久的で、転送先を正規のものとして扱ってほしい場合、たとえば古いアドレスを恒久的に置き換えるバニティ URL に使います。
302 を既定とするのが理にかなっている、キャッシュの罠については、301 と 302 のリダイレクトで説明しています。チェーンを1ホップに保つ習慣が2つあります。転送先には常に最終的な URL を貼り付けること。それは、一度読み込んで、アドレスバーからアドレスをコピーしたものです。そして、公開前に、新しいリンクに上記の curl のカウントを実行することです。その転送先を1回保存して、再印刷なしで編集できるようにしたい場合は、無料の Elido ワークスペースから始めて、この記事のコマンドで最初のリンクを追跡してみてください。
第三者が、自分では制御できないホップを追加することもあります。広告プラットフォームのクリックトラッカーや、メールプロバイダーのリンクラッパーは、望むと望まざるとにかかわらず、ショートリンクの前に置かれるため、自分が担当する経路を1ホップに保つ最良の理由になります。ブランドドメインは、ホップを追加しません。それについては、ショートリンク用のカスタムドメインで説明しています。
この記事はエンジニアリングクラスターに属します。ステータスコードの全体像はURL リダイレクトの種類を、ショートリンクの背後にあるリダイレクト層は、URL 短縮ツールの仕組みを読んでください。
関連記事
よくある質問
SEO にとって、リダイレクトは何回から多すぎますか?
Google のサイト移転に関する指針は、最終的な転送先へ直接リダイレクトし、それができない場合は、チェーンを理想的には 3 ホップ以下、少なくとも 5 ホップ未満に保つよう述べています。Googlebot 自体は最大 10 ホップまでたどるため、それは目標ではなく厳しい上限です。実際には、1ホップを目指し、2を超えるものは修正すべきバグとして扱ってください。
リダイレクトチェーンでリンクエクイティは失われますか?
Google は、301 などの恒久的なリダイレクトでは PageRank の損失は生じないと述べているため、チェーンが、古い SEO の助言が主張したようにエクイティを漏らすことはありません。チェーンが犠牲にするのは、クロール効率とユーザーのレイテンシで、どちらも Google が文書化しています。「1ホップごとに 15 パーセント失う」という数字は俗説として扱ってください。その数字を示す Google の情報源はありません。
Googlebot は何回のリダイレクトをたどりますか?
Google のクローラーのドキュメントによれば、既定では最大 10 ホップです。Google の特定のプロダクトでは異なる上限を使う場合があり、URL 検査ツールはリダイレクトをまったくたどりません。ブラウザはループでもっと早く止まります。Chrome は 20 ホップで諦め、ERR_TOO_MANY_REDIRECTS を返します。
リダイレクトチェーンはページ速度に悪影響を与えますか?
はい。各ホップは、本来のページの読み込みが始まる前に、ネットワークの往復を丸ごと1回追加し、新しいホスト名へのホップでは、さらに DNS、TCP、TLS のセットアップが加わる可能性があります。Lighthouse は、リダイレクトが2回以上あるページにフラグを立て、その遅延を数百ミリ秒に及ぶ可能性があると説明しています。低速なモバイル回線では、ペナルティは小さくならず、大きくなります。
リダイレクトチェーンはどう確認しますか?
curl -sIL https://example.com/page | grep -E '^HTTP|^[Ll]ocation' を実行すると、すべてのホップのステータス行と Location ヘッダーが順に出力されます。-w '%{num_redirects}' を加えるとホップ数を数えられ、ブラウザの開発者ツールで、ネットワークパネルの「ログを保持」オプションをオンにする方法もあります。Screaming Frog や Sitebulb のようなクローラーを使えば、サイト全体のすべてのチェーンをレポートできます。
301 の後に 302 が続くと問題ですか?
シグナルが混ざった、余分な1ホップです。Google は、恒久的なリダイレクトを転送先の正規化のシグナルとして扱い、一時的なものは、元の URL を検索結果に残す傾向があるため、混在したチェーンでは、結果の予測がしにくくなります。移転の本当の意図に合ったコードを持つ、1つのリダイレクトにまとめてください。
Elidoを試す
URLを貼り付けて短縮リンクを取得
登録不要。リンクは30日間有効。永久に保存するには登録してください。
Free、登録不要 · 1日あたり2件