リダイレクトチェーンとは？SEOへの影響と確認・解消方法を徹底解説

リダイレクトチェーンとは、あるURLにアクセスしたとき、目的のページに到達するまでに何度もリダイレクト（転送）を経由してしまう状態のことです。たとえば「旧URL→中間URL→新URL」のように、本来1回で済むはずの転送が2回、3回と連鎖してしまうケースを指します。

Googleは「3回以下、最大でも5回未満」に抑えることを推奨しており、放置するとクロールバジェットの浪費やページ表示速度の低下を招きます。

この記事では、Google公式ドキュメントとJohn Mueller氏の見解をもとに、リダイレクトチェーンの仕組みからSEOへの影響、無料ツールでの確認方法、環境別の修正手順、そして再発防止策までを網羅的に解説します。

読み終えたあとには、自社サイトのリダイレクトチェーンの発見から解消、予防まで一貫して対応できるようになるでしょう。

リダイレクトチェーンとは？【30秒で理解】

リダイレクトチェーンとは、URLにアクセスした際に最終ページへ到達するまで複数回のリダイレクトを経由してしまう状態です。SEOでは2ホップ以内が理想とされています。ここでは定義と仕組み、そしてリダイレクトループとの違いを解説します。

リダイレクトチェーンの定義と仕組み

リダイレクトチェーンとは、あるURLにアクセスした際に、最終的な目的ページに到達するまでに複数のリダイレクトを経由する状態を指します。

たとえば、以下のようなケースがリダイレクトチェーンに該当します。

https://example.com/old-page
  ↓ 301リダイレクト
https://www.example.com/old-page
  ↓ 301リダイレクト
https://www.example.com/old-page
  ↓ 301リダイレクト
https://www.example.com/new-page

本来であれば、古いURLから新しいURLへ1回のリダイレクト（1ホップ）で到達できるのが理想です。 しかし、サイト移行やURL変更を繰り返すうちに、上記のように3〜4回のリダイレクトを経由してしまうことがあります。

このような状態を「リダイレクトチェーン」と呼び、SEOの観点から改善が推奨されています。

リダイレクトループとの違い

リダイレクトチェーンと混同されやすいものに「リダイレクトループ」があります。両者の違いを整理しておきましょう。

項目	リダイレクトチェーン	リダイレクトループ
動作	最終的に目的地に到達する	永遠に循環し続ける
例	A→B→C→D	A→B→A→B→…
エラー発生	なし（到達はする）	あり（ERR_TOO_MANY_REDIRECTS）
対処の緊急度	中（改善推奨）	高（即時修正が必要）

リダイレクトループはA→B→Aのように循環してしまい、ブラウザがエラーを表示して閲覧できなくなります。 一方、リダイレクトチェーンは最終的には目的ページに到達するものの、その過程で無駄なリダイレクトを経由している状態です。

どちらも問題ですが、リダイレクトループの方が緊急度は高いと言えるでしょう。

リダイレクトチェーンがSEOに与える影響【Google公式見解】

結論から言えば、リダイレクトチェーンはクロールバジェットの浪費と表示速度の低下を引き起こします。ただし、PageRankの損失については、現在のGoogleでは発生しないことが公式に明言されています。

ここでは、Google公式ドキュメントと関係者の発言をもとに、具体的な影響を解説します。

クロールバジェットの浪費

Google公式のクロールバジェット管理ドキュメントでは、「長いリダイレクトチェーンはクロールに悪影響を与える」と明記されています。

Avoid long redirect chains, which have a negative effect on crawling.

（和訳）

長すぎるリダイレクトチェーンは、クロールに悪影響を与えるため避けてください。

Optimize your crawl budget

クロールバジェットとは、Googlebotが一定期間内にサイトをクロールする上限のことです。 リダイレクトチェーンがあると、Googlebotは各リダイレクトを1つずつ追跡する必要があり、本来クロールすべき他のページに割く時間が減ってしまいます。

特に数万〜数十万ページを持つ大規模サイトでは、この影響が顕著に現れるでしょう。

ページ表示速度の低下

リダイレクトが1回増えるごとに、約0.1〜0.5秒の遅延が発生すると言われています。Mozのリダイレクトガイドでも、リダイレクトチェーンがページ速度に与える影響について言及されています。

たとえば3回のリダイレクトがあれば、最大で1.5秒の遅延が生じる計算です。

Core Web Vitalsの観点からも、ユーザー体験の悪化は直帰率の上昇につながるリスクがあります。

リンクジュース（PageRank）への影響

リダイレクトチェーンが発生しても、PageRankが下がったりリンクジュースが失われることはないとされています。

The question posed in Google’s Webmaster Hangout:

“Is there any link equity loss from redirect chains?”

Google’s John Mueller answered:

“For the most part that is not a problem. We can forward PageRank through 301 and 302 redirects. Essentially what happens there is we use these redirects to pick a canonical. By picking a canonical we’re concentrating all the signals that go to those URLs to the canonical URL.”

（和訳）

GoogleのWebマスターハングアウトで投げかけられた質問:

「リダイレクトチェーンからリンクエクイティ（PageRank）は失われますか？」

Googleのジョン・ミューラー氏の回答:

「ほとんどの場合、それは問題ありません。301および302リダイレクトを通じてPageRankを転送できます。基本的に、リダイレクトは正規URL（canonical）を選択するために使用されます。正規URLを選択することで、それらのURLに集まるすべてのシグナルが正規URLに集中するのです。」

Google Shares How 301 Redirects Pass PageRank

ただし、リダイレクトチェーンによるクロールの遅れや表示速度の低下など、別の理由で順位が下がることはあります。

PageRankは失われなくても、リダイレクトチェーンは見つけたら修正するようにしましょう。

Googleが許容するリダイレクト回数

では、何回までのリダイレクトなら許容されるのでしょうか。 結論、実務的には2ホップ以内を目標とし、3ホップ以上の場合は改善することを検討するのがおすすめです。

Google Search Central（サイト移行ガイド）には以下のように記載されています。

Avoid chaining redirects. While Googlebot can follow up to 10 hops in a “chain” of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5. Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains.

（和訳）

リダイレクトの連鎖は避けましょう。Googlebotは複数のリダイレクト（例: ページ1 > ページ2 > ページ3）で最大10ホップをたどることができますが、最終的な目的地へ直接リダイレクトすることをお勧めします。

それが不可能な場合は、リダイレクトの連鎖数を少なく保ち、理想的には3以下、5未満にしてください。 リダイレクトの連鎖はユーザーのレイテンシを増加させ、すべてのユーザーエージェントやブラウザが長いリダイレクトチェーンをサポートしているわけではありません。

Google Search Central（サイト移行ガイド）

Google公式では3ホップ以下が理想としています。 ただ、Googleにとってもユーザーにとってもリダイレクトチェーンはなるべく少ないほうが良いため、実務的には2ホップ以内を目標とし、3ホップ以上の場合は改善することを検討するのがおすすめです。

リダイレクトチェーンが発生する原因

リダイレクトチェーンは主に3つの原因で発生します。 サイト移行時の設定ミス、CMSやプラグインの自動リダイレクト、そして過去のリダイレクト設定の蓄積です。

自社サイトがどのパターンに該当するかを把握することで、適切な対処が可能になります。

サイト移行・URL変更時の設定ミス

最も多いのが、サイト移行やURL変更時の設定ミスです。

典型的な例として、以下のようなケースがあります。

https://example.com → https://www.example.com → https://www.example.com

http→https移行とwww統一を別々のタイミングで行った場合、このようなチェーンが生じやすくなります。 本来は、すべての旧URLから最終URLへ直接リダイレクトすべきところを、中間のURLを経由させてしまうことが原因です。

CMS・プラグインの自動リダイレクト

WordPressなどのCMSでは、パーマリンク変更時に自動でリダイレクトが設定される場合があります。 便利な機能ではあるものの、複数回のURL変更を重ねると意図せずチェーンが発生しがちです。

また、リダイレクト系プラグインを複数導入していると、プラグイン同士が干渉してチェーンを生むケースもあります。CDNやキャッシュプラグインの設定との競合が原因になることも少なくありません。

過去のリダイレクト設定の蓄積

長年運営しているサイトでは、担当者の変更による引き継ぎ漏れや、古いリダイレクト設定の放置が原因となることも少なくありません。

.htaccessファイルが肥大化し、どのリダイレクトが有効なのか把握できなくなっているケースもあるでしょう。

リダイレクトチェーンの確認方法【無料ツール5選】

リダイレクトチェーンの確認は、無料ツールで簡単に行えます。 1URLずつの確認ならオンラインツール、サイト全体の一括チェックならScreaming Frogがおすすめです。

ここでは、用途に応じた5つの確認方法を紹介します。

httpstatus.io（オンラインチェッカー）

httpstatus.ioは、URLを入力するだけでリダイレクト経路を確認できる無料のオンラインツールです。

リダイレクトの経路とステータスコード（301/302など）が一覧で表示されます。 インストール不要で即座に確認できるのがメリットですが、1URLずつの確認になるため、大量のURLをチェックするには向きません。

Chrome拡張機能「Redirect Path」

Redirect Pathは、Chromeブラウザにインストールして使う拡張機能です。

日常のブラウジング中に自動検出してくれるため、実務で最も手軽に使える方法と言えます。 Chrome限定という点がデメリットですが、SEO担当者なら入れておいて損はないでしょう。

curlコマンドでの確認（コマンドライン）

コマンドライン操作に慣れている方なら、curlコマンドでも確認できます。

curl -I -L https://example.com/old-page

コマンドプロンプト（ターミナル）でのリダイレクトの確認は、環境を選ばず高速に確認できる点がメリットです。

Screaming Frogでの一括チェック

サイト全体を一括でチェックしたい場合は、Screaming Frogが最適です。無料版でも500URLまでクロールできます。

Screaming Frogでのリダイレクトチェーンのチェック方法は、公式のブログがわかりやすかったので参考にしてください。

Screaming Frogは大規模サイトでリダイレクトチェーンを網羅的に把握したい場合に有効です。

Screaming Frogの使い方は「【無料】Screaming Frogで内部リンクを徹底調査する方法」で詳しく解説しています。

Google Search Consoleでの監視

Google Search Consoleでも、リダイレクト関連の問題を確認できます。

定期的にSearch Consoleをチェックする監視体制を構築することで、問題の早期発見が可能になります。

内部リンクのリダイレクトをチェックするなら「inSite（インサイト）」がおすすめ

内部リンクでリダイレクトが発生しているかどうかを確認するなら、サイト管理自動化ツール「inSite（インサイト）」がおすすめです。

サイトURLとコンテンツエリアのClass名を入力するだけで、記事情報や内部リンク構造等を一括で取得し管理できるツールです。 内部リンクのアンカーテキスト・URLに加えて、リダイレクトの有無も確認できます。

リダイレクトをちゃんと把握して、サイトのマイナスポイントを減らしてSEOで成果を出したい方は、ぜひお試しください。

リダイレクトチェーンの解消方法【環境別】

リダイレクトチェーンの解消方法はシンプルです。 中間のリダイレクトを削除し、すべての旧URLから最終URLへ直接リダイレクトするように修正します。

ここでは、Apache環境とWordPress環境それぞれの対処法を解説します。

.htaccessでの修正（Apache）

Apache環境では、.htaccessファイルを編集してリダイレクト設定を修正します。

# 修正前（チェーン発生）
Redirect 301 /old-page /middle-page
Redirect 301 /middle-page /new-page

# 修正後（直接リダイレクト）
Redirect 301 /old-page /new-page
Redirect 301 /middle-page /new-page

ポイントは、すべての旧URLが最終URLへ直接リダイレクトするように設定することです。 中間のURLへのリダイレクトは削除または修正しましょう。

WordPressでの対処法

WordPress環境では、以下の点を確認・修正します。

修正後の動作確認

修正が完了したら、必ず動作確認を行いましょう。

• httpstatus.ioでリダイレクト経路を再確認
• チェーンが1ホップに解消されていることを確認
• CDN・サーバーのキャッシュをクリアしてから再確認

修正後もチェーンが残っている場合は、キャッシュが原因の可能性があります。 CDNやサーバーのキャッシュもクリアしてから再確認してください。

リダイレクトチェーンを防ぐ3つのポイント

リダイレクトチェーンの予防には、「URL変更時のルール策定」「定期的なサイト監査」「リダイレクト管理表の活用」の3つが有効です。仕組み化することで、再発を防止できます。

URL変更時のルール策定

URL変更時のルールを社内で策定しておきましょう。

• URL変更時は、必ず旧URLから最終URLへ直接リダイレクトする
• 中間URLを経由する設計は避ける
• 複数の変更（http→https、www統一など）は同時に行う

このルールをドキュメント化し、担当者全員が確認できる状態にしておくことが重要です。

定期的なサイト監査の実施

月次または四半期で、サイト全体のリダイレクト状況を監査する体制を構築しましょう。

リダイレクト管理表の活用

リダイレクト設定を一元管理するスプレッドシートを作成しておくと、担当者変更時の引き継ぎがスムーズになります。

元URL	転送先URL	ステータスコード	設定日	設定理由	担当者
/old-page	/new-page	301	2025/01/09	URL構造変更のため	山田

この管理表を定期的に更新することで、「なぜこのリダイレクトが設定されているのか分からない」という状況を防げます。

リダイレクトチェーン対策のまとめ

リダイレクトチェーンについて、定義から確認方法、解消・予防策まで解説しました。

リダイレクトチェーンは放置しても即座に大きな問題にはなりませんが、大規模サイトほど影響が蓄積していきます。 GoogleのJohn Mueller氏も「リダイレクトチェーンは問題になりうる」と言及しており、発見次第の対応が推奨されます。

合わせて、リンク切れ対策や内部リンクの基本設計、SEO対策の全体像も確認しておくと、サイト全体の技術的SEOをより効果的に改善できるでしょう。