本文へ移動
リライトレーダーRewrite Radar
メニュー

公開

サーチコンソールのリダイレクトエラーとは、転送が重なって行き先が決まらない状態

サーチコンソールのリダイレクトエラーは、Googlebotが転送をたどり切れなかった状態です。公式が挙げる条件はチェーンが長すぎる・ループ・最大長超え・空のURLの4つ。ブラウザでは表示できる理由と、道筋の確認手順を整理しました。

この記事のまとめ

サーチコンソールの「リダイレクト エラー」とは、Googlebot が転送を追いかけた結果、行き先のページにたどり着けなかった状態です。公式ヘルプが挙げている条件は「リダイレクト チェーンが長すぎる」「リダイレクト ループが発生している」「リダイレクト URL が最終的に URL の最大長を超えた」「リダイレクト チェーンに不正または空の URL がある」の4つで、多くは転送が複数重なった結果ですが、転送先が空のルールのように1本の設定ミスだけで起きるものもあります(Googleのクローラーは「最大 10 回のリダイレクト ホップを追跡します」)。 自分のブラウザは最終ページしか見せず、しかも公式は「Google の検査ツールはリダイレクトを追跡しません」と書いているため、公式ヘルプ自身が Lighthouse などの外部ツールでの確認を案内しています。

転送の道筋を外部ツールで確認する
図は左右にスクロールして読めます。

サーチコンソールの「ページ」を開いたら、「リダイレクト エラー」という行にURLが並んでいた。

そのURLをブラウザで開くと、普通に新しいページが表示されます。転送は効いているように見えるのに、エラーだと言われている。ここで話が通じません。

結論を先に書きます。リダイレクトエラーは「転送が効いていない」という意味ではありません。Googlebot が転送を追いかけていって、途中で追うのをやめた——それがこの行の意味です。

つまり指摘されているのは、多くの場合1本のルールではなく、リダイレクトが重なった結果の道筋です。 だから設定を1本ずつ見直すだけでは見つからないことがあります(転送先が空のルールのように、1本で完結する原因もあります)。

先に1つ。全件を今日中に直す必要はありません。急ぐのは読ませたい記事のURLがこの行に入っているときだけです(理由は後述します)。

次に直す記事を自分のデータで調べる

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

リダイレクトエラーとは何か

リダイレクトエラーとは、Googlebot が転送をたどった結果、最終的な行き先を決められなかった状態です。ページのインデックス登録レポートの公式ヘルプは、この行に入る条件を4つだけ挙げています。

次のいずれかのリダイレクト エラーが発生しました。リダイレクト チェーンが長すぎる/リダイレクト ループが発生している/リダイレクト URL が最終的に URL の最大長を超えた/リダイレクト チェーンに不正または空の URL がある
— Google公式ヘルプ

公式ヘルプが挙げている条件は、この4つだけです。だから「なぜエラーなのか分からない」という状態は、正確には「4つのうちどれが起きているのか分からない」という状態です。ここまで絞れているのは、この行の数少ない救いです。

混同しやすい行がもう1つあります。同じレポートには「ページにリダイレクトがあります」という行もありますが、こちらはエラーではありません。公式は「これは別のページにリダイレクトする非正規 URL です。そのため、この URL はインデックスに登録されません」と説明しています。転送が意図どおりなら、転送元が登録されないのは説明文どおりの結果で、転送元について直すことはありません。

「リダイレクト エラー」が出ているのか、「ページにリダイレクトがあります」が出ているのかを先に確かめてください。後者なら、この記事を読む必要はありません。そちらは「ページにリダイレクトがあります」は転送元が登録されない報告、確認は行き先の1点で、転送元を直す必要が無い理由と、代わりに確認するのが行き先の1点だけで済む根拠を、公式の原文から整理しています。

なぜ起きるのか——多くは「1本ずつは正しい」が重なって壊れる

4つの条件は、必要な段数が同じではありません。「チェーンが長すぎる」は、定義からして転送が複数重なったときにしか成立しません。ループも、サーバー側の設定とプラグインの設定が互いを指し合う形が典型です(ただし、自分自身へ転送する1本のルールでも成立します)。 一方で「URLの最大長超え」と「不正または空のURL」は、1本の設定ミスだけでも起きます。

つまりこの行には、1本のルールを直せば終わるものと、道筋を出さないと正体が見えないものが混ざっています。個人ブログで多いのは後者です。ここがこの行の厄介さを決めています。

Googleのクローラーが何本まで追うかは、HTTPステータスコードの公式ドキュメントに書かれています。

デフォルトでは、Google のクローラーは最大 10 回のリダイレクト ホップを追跡します。ただし、特定のプロダクトのクローラーでは制限が異なる場合があります。
— Google公式ドキュメント

個人ブログで転送が重なる原因は、たいてい「別々の時期に、別々の場所で足された」ことです。常時SSL化のときに http から https への転送を入れ、サーバーの管理画面で www の有無をそろえ、あとからスラッグを英語に直し、さらにプラグインでも転送ルールを1つ入れた。それぞれの担当者は自分ひとりで、それぞれの判断は正しい。にもかかわらず、1本のURLから見ると4段の階段になっています。

そして、ここからが厄介です。この階段は、自分では見えません。理由が3つあります。

① ブラウザは最終ページしか見せない

ブラウザはアドレスバーに最終的なURLだけを表示します。途中に何段あったかは画面に残りません。「開いたら表示された」は、チェーンが短いことの証拠になりません。

② URL検査では、リダイレクトの道筋が見えない

これは公式に明記されています。同じHTTPステータスコードのドキュメントの続きです。

たとえば、Googlebot は通常、一般的なウェブ コンテンツをクロールする際に 10 回のリダイレクト ホップを追跡しますが、Google の検査ツールはリダイレクトを追跡しません。
— Google公式ドキュメント

ここは線を引いておきます。転送が効いて最終ページに着くかどうかは、URL検査でも確かめられます。同じ公式ヘルプは「一般公開 URL 検査テストは、リダイレクトをたどり、最終ページ URL をテストします。ただし、ライブテストでは、リダイレクトをたどっていることは確認できません」と書いています。つまり分からないのは「効いているか」ではなく「途中に何段あったか」のほうです。旧URLから新URLへ転送されること自体の確認は301リダイレクトのやり方、SEO評価の引き継ぎは3つのレイヤーに分かれるのとおりURL検査でできますが、この行の正体である「道筋」はそこには出てきません。

実際、公式ヘルプはこの行の対処として「Lighthouse などのウェブ デバッグツールを使用して、リダイレクトに関する詳細情報を入手してください」と、サーチコンソールの外を案内しています。他の多くの行と違って、サーチコンソールの中だけでは終わらない行です。

なお公式は「公開 URL の検査では、ページ インデックス登録レポートでチェックされるすべての問題がテストされるわけではありません」とも書いています。 URL検査の表示ごとの読み方はサーチコンソールでインデックスを確認する方法、URL検査の表示ごとに次の一手が違うにまとめています。

③ 起点のURLを、もう誰も使っていない

エラーになっているのは、たいてい何年も前のURLです。自分では踏まないので、壊れていても気づく機会がありません。Googlebot だけが、まだそのURLを覚えていて叩き続けています。

4つの条件は、個人ブログでは何をやると起きるのか

条件ごとに、実際に起きやすい形を並べます。自分の心当たりを探すための表です。

公式の条件個人ブログで起きやすい形
リダイレクト チェーンが長すぎるhttp から https、www の有無、末尾スラッシュの有無、旧スラッグから新スラッグ——別々の時期に入れた転送が1本のURLで直列につながっている
リダイレクト ループが発生しているサーバー側の設定とプラグインの設定が互いを指している。 www 無しへ寄せる設定と www 有りへ寄せる設定が両方生きている場合が典型
リダイレクト URL が最終的に URL の最大長を超えた転送のたびに元のURLをパラメータとして抱え込む作り。 ログイン後の戻り先や言語切り替えの仕組みで、URLの中にURLが入れ子で積まれていく
リダイレクト チェーンに不正または空の URL がある転送先を空欄のまま保存したルール、書き間違えた相対パス、 プラグインの設定を移行したときに値が入らなかった行

「URLの最大長」が何文字なのかは、書かれていません。今回確認したのはページのインデックス登録レポートのヘルプ・HTTPステータスコードのドキュメント・URL構造のドキュメントの3ページで、この3ページには具体的な文字数の記載が見当たりませんでした(2026年9月8日に全文を取得して確認)。文字数を数えて安心するより、URLの中にURLが入れ子になっていないかを見るほうが早いです。

パラメータ付きURLとSEOの関係はURLパラメータとSEO、utmを付けると重複コンテンツになるのかに書いています。

直す記事と作業内容を決める

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

何を解決すべきか——「件数」ではなく「道筋」を見る

やることは1つです。エラーになっているURLを1本選んで、そのURLが最終的にどこへ着くまでに何段あるかを、段ごとに書き出すこと。4つの条件のどれに当たっているかは、道筋を出せば見た瞬間に分かります。

  • 10段を超えても着地していなければ、チェーンが長すぎる。 公式は「デフォルトでは、Google のクローラーは最大 10 回のリダイレクト ホップを追跡します」としているので、5段や6段はまだ追われる範囲です(それでも公式が勧める本数は超えています。後述)
  • 同じURLが2回出てくれば、ループ
  • 段を進むごとにURLが長くなっていれば、最大長
  • 途中の行き先が空、または明らかに存在しない文字列なら、不正または空のURL

逆に言えば、チェーンやループが原因のときは、道筋を出さないまま設定ファイルを眺めても分かりません。設定ファイルには1本ずつのルールしか書かれていないからです。壊れているのがルール単体ではなく組み合わせなら、1本ずつの画面には映りません。

そしてもう1つ。全件を1本ずつ調べる必要はありません。個人ブログで起きるチェーンは、常時SSL化やドメイン統一のように、サイト全体に一度だけ適用したものが原因になっていることが多いためです。1本たどれば、残りも同じ形をしている可能性が高い。

道筋を出す手段は、大きく4つ

どれか1つで足りますし、無料でできるものが3つあります。

① ブラウザの開発者ツール

ネットワークのタブを開き、ログを保持する設定にしてからURLを開くと、転送の段が1行ずつ残ります。インストールが要らないので、まずここからで十分です。ただし、ブラウザが途中で諦めたときの挙動は Googlebot と同じとは限りません。

② コマンドラインで転送を追う

curl などのコマンドで、転送を追いながらヘッダーだけを表示させると、段ごとのステータスコードと行き先が並びます。サイト移転の公式ドキュメントも、多数のURLを調べるときはコマンドラインツールやスクリプトを使うよう案内しています。

③ Lighthouse などのウェブデバッグツール

公式ヘルプがこの行の対処として名前を挙げているのは Lighthouse です。Chrome に組み込まれているので、追加の契約は要りません。

④ サイト全体をクロールするツール

サイト内のURLをまとめてたどるクローラーを使うと、チェーンの一覧を一度に出せます。記事が数百本ある場合や、原因が1種類ではなさそうな場合に向きます。個人ブログで、心当たりが1つに絞れているなら、ここまでは要りません。

道筋が分かったあと、どう直すか——転送先を1段にまとめる書き方や、301の設定手順は301リダイレクトのやり方、SEO評価の引き継ぎは3つのレイヤーに分かれるの領分です。公式がチェーンを「5 個未満(理想的には 3 個以下)」に抑えるよう求めている件も、あちらで扱っています。

そもそもそのURLを残すのか消すのかで迷う場合は記事の削除で404と410どちらを返すか、301・noindexとの使い分けを、スラッグを変えるかどうかで迷う場合はURLを変えるとSEO評価は切れる、スラッグ変更の前に301を用意するを先に読んでください。

件数を0にする作業ではない

この行の件数を0にすることが目的ではありません。リダイレクトエラーはページのインデックス登録レポートの「未登録」側の理由で、公式は未登録について「ページはインデックスに登録されていませんが、必ずしもエラーによるものではありません。具体的な説明を読んで、対処する必要があるエラーかどうかを確認してください」と書いています。

判断はこう分かれます。並んでいるのが何年も前の旧URLや、消したカテゴリのURLだけなら、検索から来る読者はもともとそのURLを踏んでいません。読ませたい記事の現在のURLが入っているときだけ、急ぐ理由があります。その記事は検索結果に出ていないからです。

直した直後に件数が減らないのも、失敗ではありません。公式は、レポートにエラーが残る理由をこう説明しています。

Google が最後にクロールした後に、エラーが出た URL が修正された可能性があります。URL のクロール日を確認し(略)、ページのクロール以降に修正が行われていないか確認してください。
— Google公式ヘルプ

インデックスされない原因の全体像はインデックスされない原因は2系統に分かれる、確認できるものから潰すに、同じレポートの別の行についてはソフト404は「200を返しているのに中身が無い」状態ですに整理しています。

よくある質問

サーチコンソールのリダイレクトエラーとは何ですか

リダイレクトエラーとは、Googlebot が転送をたどった結果、行き先を決められなかった状態です。公式ヘルプが挙げている条件は「リダイレクト チェーンが長すぎる」「リダイレクト ループが発生している」「リダイレクト URL が最終的に URL の最大長を超えた」「リダイレクト チェーンに不正または空の URL がある」の4つだけです。

ブラウザで開くと普通に表示されるのに、なぜエラーなのですか

ブラウザは最終的なURLしか表示しないため、途中に何段の転送があったかが画面に残らないからです。公式ドキュメントは「デフォルトでは、Google のクローラーは最大 10 回のリダイレクト ホップを追跡します」としており、ブラウザで表示できることは、段数が少ないことの証拠になりません。

URL検査では問題が出ないのに、レポートにはエラーが出ます

URL検査で分かるのは最終ページまでで、途中に何段あったかという道筋は出ないからです。公式ヘルプは「一般公開 URL 検査テストは、リダイレクトをたどり、最終ページ URL をテストします。ただし、ライブテストでは、リダイレクトをたどっていることは確認できません」としており、公式ドキュメントも「Google の検査ツールはリダイレクトを追跡しません」と書いています。そのため公式ヘルプ自身が「Lighthouse などのウェブ デバッグツールを使用して、リダイレクトに関する詳細情報を入手してください」と外部ツールを案内しています。

リダイレクトエラーは全部直さないといけませんか

全件を直す必要はありません。公式ヘルプは未登録の理由について「必ずしもエラーによるものではありません。具体的な説明を読んで、対処する必要があるエラーかどうかを確認してください」としています。読ませたい記事の現在のURLが入っている場合だけ、優先して見てください。

「ページにリダイレクトがあります」と同じものですか

別の行で、こちらはエラーではありません。公式ヘルプは「これは別のページにリダイレクトする非正規 URL です。そのため、この URL はインデックスに登録されません」と説明しています。転送が意図どおりなら、転送元が登録されないのは説明文どおりの結果です。(この項目に「正しく作動しています」のような言い切りは付いていないので、公式が正常だと宣言しているとまでは読みません。)

直したのに、まだリダイレクトエラーに出ています

レポートは、Googleがそのページを再クロールしてから更新されます。公式ヘルプは「Google が最後にクロールした後に、エラーが出た URL が修正された可能性があります。URL のクロール日を確認し」と案内しています。直した直後に件数が変わらないのは、失敗ではありません。

まとめ

  • リダイレクトエラーは、Googlebot が転送をたどった結果、行き先を決められなかった状態。 転送が効いていないという意味ではない
  • 公式が挙げる条件はチェーンが長すぎる・ループ・URLの最大長超え・不正または空のURLの4つだけ。チェーンは複数段が重なって初めて成立し、ループも別々の設定が互いを指す形が典型。最大長超えと不正または空のURLは、1本の設定ミスだけでも起きる
  • 重なる原因は常時SSL化・www の統一・スラッグ変更・プラグインの転送が別々の時期に足されたこと。 1本ずつのルールは正しいまま壊れる
  • 気づけないのは①ブラウザは最終ページしか見せない ②URL検査は最終ページまでで、公式いわく「Google の検査ツールはリダイレクトを追跡しません」 ③起点のURLをもう誰も踏んでいないから
  • やることは1本のURLについて、着地までの段を書き出すこと。 手段は開発者ツール・コマンドライン・Lighthouse・クローラーの4つで、公式が名前を挙げているのはLighthouse
  • 件数を0にする作業ではない。並んでいるのが旧URLだけなら読者への影響は無く、読ませたい記事の現在のURLが入っているときだけ急ぐ

ここから先は、私が作ったツールの話です。

リライトレーダーは、この記事の最後で書いた「読ませたい記事」の側だけを扱います。 Search Console のエクスポートをZIPのまま落として貼るだけで、掲載順位4.0〜20.5位・表示回数100回以上のページを拾い、改善余地スコアの大きい順に並べます。判定と候補の数値、そのうち1記事分の診断カードまでは無料で、診断カード3記事分が2,980円(税込)の買い切りです。月額課金や自動更新はありません。ログインも不要です。CSVファイルそのものはブラウザの外に出ません(送るのは、診断カードを出すときは選んだ1ページのURL・数値・入力したキーワード、「ページタイトルを取得する」を押したときは判定に出たページのURL最大10件です)。

⚠️ ただし、向かない人がいます。リダイレクトやインデックスの問題を片付けたい人には向きません。転送の道筋もクロールもインデックス登録も扱っていません。読むのは、すでに検索結果に出ているページの4つの数字だけです。 また、表示回数が2桁で止まっているサイトにも向きません。判定の条件が表示回数100回以上なので、対象になるページが1つも出ないからです。

Search ConsoleのZIPで無料判定する

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

この記事の内容をツールにしています

Search Console の「ページ」CSVを貼ると、改善余地のある記事を順番に出します。 判定とご自分の記事1件分の診断カードは無料です。ログイン不要。CSVファイルはアップロードせず、ブラウザ内で解析します。

リライトレーダーで無料診断する

関連する記事

この記事を書いた人

みやこし

ブログのリライトで「どの記事を直すか」を数字で決めるSEOライター向けツールを作っています。 掲載順位ごとの平均クリック率、AI Overviewによるクリック減の補正、タイトルの直し方など。

noteQiitaZenn

ブログの一覧に戻る