リダイレクトチェーンとは？Googleは10ホップまで・推奨3個以下の根拠と解消手順

リダイレクトチェーンとは、あるURLにアクセスしたとき、最終ページに着くまでに転送（リダイレクト）が2回以上連続している状態です。1回の転送で目的のページに着くなら、それはチェーンではありません。SEOの記事では「チェーンがあると評価が落ちる」と抽象的に語られがちですが、Googleは追跡するホップ数の上限も、推奨する本数も、リンク評価の扱いも公式ドキュメントで明示しています。この記事では、公式ドキュメントと実在サイトの計測記録をもとに、問題となる条件、検出方法、最終URLへ直接転送する修正手順を解説します。301と302の違いや設定方法そのものはリダイレクトとは？301・302の違いと設定方法・SEOへの影響を実務目線で解説で扱っているため、本記事は多段になった場合に絞ります。

まとめ：リダイレクトチェーンの要点

• Googlebotは一般のウェブクロールで最大10ホップを追跡します。「5回で諦める」といった説は公式の記述と食い違います。
• ただしGoogleの推奨は最終的な宛先へ直接で、やむを得ない場合も5個未満（理想は3個以下）です。
• 301などの永続リダイレクトでPageRankの損失は生じないとGoogleが明記しています。チェーンでリンク評価が目減りするという前提で設計する必要はありません。
• 問題が出るのは速度と、上限を超えたときの取りこぼしです。TTFBには転送時間が含まれ、2ホップのチェーンで約0.46秒を消費する実測例があります。
• ブラウザ側の上限は20回（Fetch Standard、Chromiumの定数も20）。これを超えると「リダイレクトが多すぎます」のエラーになります。
• 検出はcurl -sILと-wの書式指定子、Search Consoleの「ページにリダイレクトがあります」「リダイレクト エラー」で足ります。

リダイレクトチェーンとは何か：単一のリダイレクトとの違い

リダイレクトは、サーバーが3xxのステータスコードとLocationヘッダーを返し、クライアントに別のURLへ行き直させる仕組みです。この転送が1回で終わるのが単一のリダイレクト、2回以上連鎖するのがリダイレクトチェーンです。Googleは公式ドキュメントで、チェーンを「複数のリダイレクトの『チェーン』（例: ページ 1 > ページ 2 > ページ 3）」と説明しています。

転送先がいずれ元のURLへ戻ってきて無限に回り続ける状態は、チェーンの極端な形であるリダイレクトループです。チェーンには最終的な到達先があり、ループは同じ経路を循環します。ただし、長いチェーンもループも追跡上限を超えると同じエラーになるため、表示だけでは区別できません。

wikipedia.orgの2ホップの計測例

チェーンは特殊な設定ミスでだけ起きるものではありません。HTTPS化とホスト名の統一を別々のルールで書いた場合、誰のサイトでも自然に2段になります。2026年9月16日にcurlで計測したところ、http://wikipedia.orgは2ホップのチェーンでした。

$ curl -sIL http://wikipedia.org | grep -i -E "^HTTP/|^location:"
HTTP/1.1 301 Moved Permanently
location: https://wikipedia.org/
HTTP/2 301
location: https://www.wikipedia.org/
HTTP/2 200

1段目でスキームをHTTPSへ、2段目でホスト名をwww付きへ寄せています。それぞれのルールは正しく、どちらも301です。それでも合計すると2ホップになります。一方http://github.comは1ホップでhttps://github.com/に着きました。この観測から確認できるのは、当該URLがHTTPSの最終URLへ1回で転送されたことまでで、サーバー内部のルール構成までは分かりません。

チェーン経由と直接アクセスの所要時間比較

同じ2026年9月16日に、macOS上のcurl 8.7.1で、チェーン経由を5回、最終URLへの直接アクセスを3回計測しました。以下はこの環境での測定範囲であり、他の回線やブラウザで同じ値になることを示すものではありません。time_redirectは「最終的な通信が始まるまでの、すべてのリダイレクト処理にかかった秒数」を示すcurlの書式指定子です。

合計時間のおよそ半分を転送そのものが占めています。この計測では2ホップの転送時間を平均すると1ホップあたり約0.23秒ですが、各段の時間やDNS参照・接続・TLS処理の内訳は測定していません。モバイル環境での差は今回測定しておらず、通信の往復遅延やキャッシュ、接続条件によって変わります。

Googlebotのリダイレクト追跡上限と推奨回数

Googlebotの追跡上限について、Googleは「HTTPステータス コード、ネットワーク エラー、DNS エラーをGoogleがどう処理するか」のドキュメントで、3xxの扱いをこう書いています。

By default, Google’s crawlers follow up to 10 redirect hops. However, specific products’ crawlers may have different limits. For example, Googlebot generally follows 10 redirect hops when crawling for general web content, but Google Inspection Tools doesn’t follow redirects.

既定で最大10ホップ、ただし製品ごとに上限は異なる、という内容です。「Googleは5回程度で諦める」という説明を見かけますが、公式の記述は10ホップです（出典：Google検索セントラルHTTPステータス コード、ネットワーク エラー、DNS エラーの処理）。

末尾の「Google Inspection Tools doesn’t follow redirects.」は、チェーンの調査で読み違えやすい箇所です。URL検査ツールのヘルプは、同じツールの挙動を用途別に分けて説明しています。インデックス登録情報については「If the URL redirects to another URL, the results reflect the tested URL in the index, not the redirect target in the index.」＝検査したURL自体の情報であって、転送先の情報ではありません。一方、公開URLテストについては「The test first follows any redirects implemented by the page, then tests the page. However, the test does not indicate that it has followed a redirect, nor will it display the final URL that was tested.」＝転送を辿って検査はしますが、辿ったことも検査した最終URLも画面には出ません。転送先のインデックス状況を知りたい場合は、最終的な宛先のURLを直接検査してください。Search Console全般の使い方はサーチコンソールとは？できること・設定手順とSEO改善への使い方【2026年時点】で解説しています。

Googleが推奨する最終URLへの直接転送

10ホップまで追跡されるからといって、9段まで許されるという意味ではありません。URLの変更を伴うサイト移転のガイドはこう記しています。

リダイレクトのチェーンを避ける。Googlebot は複数のリダイレクトの「チェーン」（例: ページ 1 > ページ 2 > ページ 3）に含まれる最大 10 個のホップをたどることができますが、最終的な宛先に直接リダイレクトすることをおすすめします。直接リダイレクトできない場合は、チェーン内のリダイレクトの数を 5 個未満（理想的には 3 個以下）に抑えてください。リダイレクトのチェーンを使用すると、ユーザーにとってはレイテンシが増大します。また、一部のユーザー エージェントとブラウザは長いリダイレクト チェーンに対応していません。

目標は直接転送、許容は5個未満、理想は3個以下。理由として挙げられているのはクロールの打ち切りではなく、レイテンシの増大と、長いチェーンに対応しないクライアントの存在です。SEO評価の減点ではなく、ユーザー側の実害が根拠になっている点は押さえておく価値があります。

永続リダイレクトによるPageRankの扱い

「301を重ねるとリンクジュースが15%失われる」という俗説が長く流通しました。同じサイト移転のガイドに、明確な否定があります。

リンク クレジットについては要件を設けない。301 やその他の永続的なリダイレクトによって PageRank の損失が生じることはありません。

英語版では「Don’t worry about link credit. 301 and other permanent redirects don’t cause a loss in PageRank.」です。減衰率を見積もってチェーンの段数を決める、といった設計は不要です。チェーンを畳むべき理由は速度と確実性であって、リンク評価の保全ではありません。

3xxごとのGoogleの扱いとRFCの規定

ステータスコードの選び方は、Googleの扱いとRFC 9110 15.4節のメソッド規定の両方で決まります。

RFC 9110は301と302の項に「For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.」という注記を置き、その挙動が望ましくない場合は308（301の代わり）や307（302の代わり）を使うよう案内しています。フォーム送信を転送する経路では、301ではなく308を選ぶ判断がここから出てきます。

検索結果にどちらのURLが出るかも、恒久か一時かで変わります。Googleは「Permanent redirects: Show the new redirect target in search results. Temporary redirects: Show the source page in search results.」としています。移転後に新URLを検索結果へ出したいなら、恒久的なコードを選ぶ必要があります。

なおGoogleは、301と308、302と307をそれぞれ同等に扱うと明記したうえで「While Google treats these status codes the same way, keep in mind that they’re semantically different.」と付け加えています。Googleにとって同じでも、他のクライアントにとっては違うコードです。

ブラウザ側の上限とリダイレクトループ

Googlebotの10ホップとは別に、ブラウザやHTTPクライアントにも独自の上限があります。ここを超えると、ユーザーにはページではなくエラー画面が出ます。

ブラウザ側の20回は、Fetch Standardの「HTTP-redirect fetch」に「If request’s redirect count is 20, then return a network error.」「Increase request’s redirect count by 1.」というステップとして規定されています。Chromiumはこれを実装しており、net/url_request/url_request.hにstatic constexpr int kMaxRedirects = 20;という定数と、Fetch Standardを参照するコメントが置かれています。Firefoxも既定値は同じ20で、modules/libpref/init/all.jsに「Maximum number of consecutive redirects before aborting.」というコメントとともにpref("network.http.redirection-limit", 20);が置かれています。curlは--max-redirsのドキュメントで「By default the limit is set to 50 redirects. Set this option to -1 to make it unlimited.」としており、既定は50回です。

Chromeで「このページは動作していません」「ERR_TOO_MANY_REDIRECTS」、日本語環境で「リダイレクトが多すぎます」と表示されるのは、この上限に達したときです。このエラーだけでは、循環するループなのか、最終URLに着くまでの転送が長すぎるのかは判別できません。よくある組み合わせは次の3つです。

• サーバー設定でHTTPS化し、CDNやロードバランサーの側でもHTTPS化していて、オリジンには常にHTTPで届く。Cloudflareは暗号化モードがFlexibleの場合について「Redirect loops will occur if your origin server automatically redirects all HTTP requests to HTTPS.」と明記しています
• 末尾スラッシュを付けるルールと外すルールが別々に存在し、互いを打ち消し合う
• アプリケーション側のログイン判定とサーバー側のリダイレクトが、互いに相手を条件にしている
• CMSの正規化とサーバーの正規化が二重に走っている。なおWordPressコアのredirect_canonical()には// Protect against chained redirects.というコメントとともに、転送先URLをもう一度正規化にかけて追加の転送が必要になるなら転送しない、という実装が入っています。CMS側で正規化を止めたつもりでも、この処理が動いている前提で切り分けてください

表示速度への影響：TTFBに含まれる転送時間

リダイレクトの遅延は、体感だけでなく指標にも直接載ります。web.devのTTFB（Time to First Byte）の定義は次のとおりです。

TTFB is the sum of the following request phases: Redirect time, Service worker startup time (if applicable), DNS lookup, Connection and TLS negotiation, Request, up until the point at which the first byte of the response has arrived.

先頭に「Redirect time」が入っています。リダイレクトに費やした時間は、そのままTTFBに加算されるということです。同じドキュメントは「Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.」としており、良好とされる基準は0.8秒以下です。

前掲の実測では、2ホップのチェーンだけで0.455〜0.466秒を消費していました。0.8秒という目安の半分以上に相当する時間を転送に費やしています。ただし、curlの転送時間はブラウザのTTFBそのものではなく、TTFBもCore Web Vitalsや検索順位の直接の評価指標ではありません。Lighthouseには多段リダイレクトを扱うredirects監査が今も含まれていますが、既定の設定ファイルでは重み0のhiddenグループに置かれており、レポート上はdocument-latency-insight（Document request latency）の側で扱われます。「複数のページ リダイレクトの回避」という旧来の項目名で検索しても現行のレポートに見当たらないのは、このためです。

リダイレクトチェーンの確認方法

専用ツールを導入しなくても、手元のコマンドとSearch Consoleで十分に把握できます。

curlによる転送経路とホップ数の確認

-sで進捗表示を止め、-Iでヘッダーのみ、-Lでリダイレクトを追跡します。各段のステータスコードとLocationを抜き出すと、HEADリクエストでの転送経路を確認できます。通常の閲覧に相当するGETで確認する場合は、-Iを外し、-D -と-o /dev/nullを指定してください。

curl -sIL https://example.com/old-page/ | grep -i -E "^HTTP/|^location:"

本数と時間を数値で取りたい場合は-wの書式指定子を使います。num_redirectsは「Number of redirects that were followed in the request.」、url_effectiveは「The URL that was fetched last.」、time_redirectは前述のとおり全リダイレクト処理の合計秒数です。

curl -sL -o /dev/null \
  -w 'hops=%{num_redirects} final=%{url_effective} t_redirect=%{time_redirect} t_total=%{time_total}\n' \
  https://example.com/old-page/

複数URLを一括で調べる場合は、URLを1行ずつ記したファイル（LF区切り）をループで処理できます。ただし、到達確認にはホップ数と最終URLだけでなく、最終HTTPステータスとcurlの終了コードも記録してください。-sだけでは通信の失敗が画面に出ず、404と正常到達も区別できないためです。

while IFS= read -r u || [ -n "$u" ]; do
  [ -n "$u" ] || continue
  curl -sSL -o /dev/null --connect-timeout 5 --max-time 20 \
    -w "%{num_redirects}\t%{http_code}\t%{exitcode}\t%{url_effective}\t$u\n" "$u"
done < urls.txt

手元で同じコマンドに3件（正常な2ホップ／404を返すURL／存在しないホスト）を流したときの出力は、それぞれ「2 / 200 / 0」「0 / 404 / 0」「0 / 000 / 6」でした。http_codeが000でexitcodeが6なら名前解決の失敗です。ホップ数だけを見ていると、この3件はどれも「転送なし」に見えてしまいます。

なお--max-redirsを小さく指定すると、上限に達した時点で止まります。そのときはredirect_urlに「a redirect *would* have gone to」次のURLが入るため、長いチェーンやループの途中経過を切り出すのに使えます。

Search Consoleの転送通知とリダイレクトエラーの違い

ページのインデックス登録レポートでは、正常な転送元の除外を示す「ページにリダイレクトがあります」と、転送の問題を示す「リダイレクト エラー」を区別します。

「ページにリダイレクトがあります」は、転送元のURLがインデックスされていないというだけの通知で、エラーではありません。旧URLを301で新URLへ寄せていれば、旧URL側にこの表示が出るのが正常な状態です。件数が増えたこと自体を問題視して転送を外すと、かえって評価を分散させます。URLの正規化をどう設計するかはcanonicalタグとは？SEOでのURL正規化の目的・書き方・設定方法を解説を参照してください。

対処が必要なのは「リダイレクト エラー」のほうです。列挙されている4条件のうち2つ（チェーンが長すぎる、ループ）が、そのままこの記事の主題です。

チェーンが生まれる原因と解消の手順

チェーンは、1つの大きなミスではなく、それぞれ正しいルールの積み重ねで生まれます。

HTTPS化・URL変更・正規化によるチェーンの発生原因

• HTTPS化とホスト名統一を別ルールで書いた：前掲のwikipedia.orgと同じ構図です。HTTP→HTTPSで1段、www無し→www有りでもう1段になります。
• サイトリニューアルを繰り返した：旧URLから中間URLへの転送を残したまま、中間URLから新URLへの転送を追加すると、旧URLからの経路が2段になります。3回目のリニューアルで3段です。
• 末尾スラッシュやパラメータの正規化が後付けされた：CMS側の正規化と、サーバー側の転送が二重に走ります。
• CDNやプラグインが1段足している：オリジンの設定を見ても見つからないタイプで、curlで各段のLocationを見ないと特定できません。

旧URLと最終URLのマッピング表・転送ルールの修正

個々の転送ルールを直す前に、旧URLと最終URLの対応表を作り直します。中間URLを経由させず、旧URLから最終URLへ1本で結ぶのが原則です。リニューアル全体の進め方はサイトリニューアルの進め方｜SEO評価を落とさない6ステップと注意点にまとめています。

Apacheで書く場合、RedirectディレクティブはRedirect [status] [URL-path] URLという構文です。注意点は既定値で、公式ドキュメントは「If no status argument is given, the redirect will be ‘temporary’ (HTTP status 302).」としています。恒久的な移転ではpermanent（301）を必ず明示してください。

# 悪い例：2段になる
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]

# 良い例：ドキュメントルートの.htaccess用
# Apache自身がTLSを終端する構成を想定
# www.example.comは実際の正規ホスト名へ変更
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,END]

悪い例でhttp://example.com/pageにアクセスすると、1つ目のルールがhttps://example.com/pageへの301を返します。ブラウザが新しいリクエストを送り直すと、今度はHTTPSなので1つ目の条件には合わず、2つ目のルールがhttps://www.example.com/pageへの301を返します。ルール自体はどちらも正しいのに、転送は2回発生します。良い例は条件を[OR]で束ね、どちらに該当しても最終形のURLへ1回で送ります。

フラグの指定にも落とし穴があります。[R]について公式は「Any valid HTTP response status code may be specified, using the syntax [R=305], with a 302 status code being used by default if none is specified.」と述べています。[R]だけ書くと302になるため、恒久的な転送では[R=301]と明示します。

そして[L]です。サーバー設定ファイルでは「以降のルールを処理しない」で済みますが、.htaccessでは挙動が変わります（出典：Apache HTTP Server RewriteRule Flags）。

In per-directory context, [L] stops the current pass through the ruleset, but the rewritten request may be re-processed from the top — which can cause loops. Use the [END] flag to prevent this

.htaccessで書いたルールは、書き換え後のリクエストがルールセットの先頭から再処理される可能性があり、それが内部書き換えのループの原因になります。[END]はこの再処理を止めます。ただし同じページには「This does not apply to new requests resulting from external redirects.」ともあり、[R=301]のように外部リダイレクトを返した後の新しいリクエストには効きません。ブラウザにERR_TOO_MANY_REDIRECTSが出る循環は外部リダイレクト側の問題なので、まず各応答のLocationを並べ、どの条件とどの条件が互いを打ち消しているかを特定してください。

HSTSによるHTTP転送の省略と適用条件

HTTPからHTTPSへの転送は、HSTS（HTTP Strict Transport Security）で削れます。MDNは、HSTSホストとして記録済みのドメインについてブラウザがどう振る舞うかをこう説明しています。

Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case-insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https. If the URL specifies port 80, the browser changes it to 443.

リクエストを送る前にブラウザ自身がHTTPSへ書き換えるため、ネットワーク上の転送が1本減ります。MDNは同じページで「future attempts to load an http URL will use HTTPS immediately, without requiring a redirect」とも書いています。ただし、HSTSポリシーを未取得で、プリロードや親ドメインのincludeSubDomainsの対象でもない場合、初回のHTTPアクセスではサーバーによる転送が必要です。プリロード対象なら初回からHTTPSで接続できます。HSTSの設定と、逆に解除したい場合の手順はHSTSが使用されているためアクセスできない原因と解除方法｜HSTSの仕組み・設定・無効化までで扱っています。

内部リンクとサイトマップの参照先URLの更新

Googleのサイト移転ガイドも、内部リンクとcanonical等の注釈を新URLへ更新し、新URLを収録したサイトマップを準備するよう案内しています。サーバー側のルールを1本にしても、サイト内のリンクやXMLサイトマップが旧URLを指していれば、そのリンクをたどるユーザーとクローラーは毎回転送を踏みます。転送ルールは保険であって、正解は最終URLを直接参照することです。マッピング表ができた時点で、本文中のリンク、ナビゲーション、サイトマップ、正規URLの指定をまとめて最終URLへ更新してください。

よくある質問

リダイレクトチェーンは何回までなら許容されますか？

Googlebotが追跡するのは最大10ホップですが、Googleの推奨は最終的な宛先への直接転送です。直接にできない場合の目安として、公式ドキュメントは「5 個未満（理想的には 3 個以下）」を挙げています。上限の10まで使ってよいという意味ではありません。

301リダイレクトを重ねるとリンク評価は減りますか？

減りません。Googleはサイト移転のガイドで「301 やその他の永続的なリダイレクトによって PageRank の損失が生じることはありません」と明記しています。「1回につき15%失われる」といった数値は公式の記述に基づくものではありません。チェーンを畳む理由は、評価の目減りではなく、速度の悪化と上限超過による取りこぼしです。

Search Consoleに「ページにリダイレクトがあります」と出たら対処が必要ですか？

意図した転送であれば対処は不要です。この項目の公式説明は「これは別のページにリダイレクトする非正規 URL です。そのため、この URL はインデックスに登録されません。」で、エラーではなく未登録の理由を示すものです。旧URLを新URLへ301で寄せていれば、旧URL側にこの表示が出るのが正常な状態です。対処が必要なのは「リダイレクト エラー」のほうです。

「httpのリダイレクトが多すぎます」と表示されるのはなぜですか？

リダイレクトの回数がブラウザの追跡上限を超えるためです。Fetch Standardでは20回追跡した後にさらに転送が必要な場合にネットワークエラーを返すと規定しており、Chromiumも定数kMaxRedirectsを20として実装しています。このエラーだけでは、循環するループなのか、最終URLに着くまでの転送が長すぎるのかは判別できません。各応答のLocationを並べて経路を確認したうえで、サーバーとCDNの両方でHTTPS化している、末尾スラッシュの付与と除去が両方設定されている、HTTPS化とホスト名統一の条件が互いに逆を向いている、といった重複を疑ってください。

URL検査ツールでリダイレクト先の状態を確認できますか？

用途によって分かれます。インデックス登録情報は検査したURL自体のもので、転送先のものではありません。公開URLテストは転送を辿って検査しますが、転送したことも検査した最終URLも表示されません。転送先のインデックス状況を確認したい場合は、そのURLを直接検査してください。

リダイレクトを一括でチェックする方法はありますか？

調査対象のURLを1行ずつ書いたファイルを用意し、curlの-wでnum_redirectsとurl_effectiveを出力させれば、ホップ数と最終URLの一覧がそのまま得られます。サイト全体を機械的に洗い出す場合はクローラー型のツールが向きますが、リニューアル直後に旧URLの棚卸しを確認する程度であれば、マッピング表のURLをそのまま流し込むこの方法で足ります。

関連記事

• リダイレクトとは？301・302の違いと設定方法・SEOへの影響を実務目線で解説
• canonicalタグとは？SEOでのURL正規化の目的・書き方・設定方法を解説
• サイトリニューアルの進め方｜SEO評価を落とさない6ステップと注意点
• サーチコンソールとは？できること・設定手順とSEO改善への使い方【2026年時点】
• HSTSが使用されているためアクセスできない原因と解除方法｜HSTSの仕組み・設定・無効化まで