Google Search Console の「リダイレクト エラー」：原因と修正方法

Search Console の「リダイレクト エラー」の意味

「リダイレクト エラー」は、Google Search Console の「ページのインデックス登録」レポートにある「ページがインデックスに登録されなかった理由」の表に表示される理由の 1 つです。Googlebot が URL のリダイレクトをたどったものの、クロールできる転送先にたどり着けなかった場合に表示されます。その経路では、元の URL も転送先もインデックスに登録されません。

「ページにリダイレクトがあります」と混同しやすいので、はっきりさせておきましょう。こちらは正常なステータスです。リダイレクトが機能したことを意味し、その URL は別の場所を指しているためインデックスに登録されず、Google は転送先を単独で評価します。一方の「リダイレクト エラー」は、リダイレクトそのものが失敗したことを意味します。

このステータスはインデックス作成 › ページにあります。「リダイレクト エラー」の行をクリックすると対象の URL が表示され、エクスポートで全リストをダウンロードできます。

「リダイレクト エラー」のよくある原因

Google の「ページのインデックス登録」レポートのドキュメントには、このステータスの背景となる 4 つの状況が挙げられています。実際には、さらに 2 つのケースもよく見られます。

1. 長すぎるリダイレクト チェーン

別の URL にリダイレクトする URL があるたびに、ホップが 1 つ増えます。Google のクロールに関するドキュメントによると、Google のクローラーがたどるリダイレクトは最大 10 ホップです。それを超えると Googlebot は追跡をあきらめ、Search Console にリダイレクト エラーが表示されます。チェーンは時間とともに長くなるのが普通です。HTTP から HTTPS へのルール、次に www のルール、さらに末尾スラッシュのルール、その上にサイト移行が重なる、といった具合です。

2. リダイレクト ループ

URL A が URL B にリダイレクトし、URL B が URL A（または A に戻るいずれかの URL）にリダイレクトします。チェーンが終わらないため、どのページにもたどり着けません。ループは、末尾スラッシュを付けるルールと削除するルールのように、互いに矛盾する 2 つのルールから生まれることがよくあります。

3. 最大長を超えるリダイレクト URL

リダイレクトのルールがホップのたびにパラメータやパスの一部を付け足していくと、URL が伸び続けて最大長を超え、チェーンが失敗します。

4. チェーン内の不正な URL または空の URL

http:// を htp:// と書くようなタイプミス、誤った場所に解決される相対パス、空の Location ヘッダーがあると、そのホップでリダイレクトが途切れます。

5. Google がクロールできない転送先

最終的な URL が robots.txt でブロックされていると、Googlebot はそのページを取得できません。各リダイレクトの転送先が存在するかだけでなく、クロール可能かどうかも確認しましょう。

6. 複数の場所で矛盾するリダイレクト ルール

CMS、プラグイン、ウェブサーバー、CDN で設定したリダイレクトは、積み重なったり競合したりします。ある層に追加したルールが、別の層のルールに URL を送り返すこともあります。チェーンやループの多くは、こうして生まれます。

「リダイレクト エラー」の診断方法

まず Search Console が指摘している URL を確認し、それぞれをリクエストしたときに何が起きるかを追跡します。

URL 検査を使う

対象の URL を Search Console 上部の検査バーに貼り付けます。ページのインデックス登録のセクションに、Google が最後にクロールした日時と、ページの取得に成功したかどうかが表示されます。レポートは修正の反映が遅れることがあるので、公開 URL をテストをクリックして現在の動作を確認しましょう。

リダイレクトの経路をすべて追跡する

URL をリクエストし、すべてのホップをたどります。ターミナルから実行する場合は次のとおりです。

curl -sIL https://example.com/old-page | grep -iE "^(HTTP|location)"

出力には、各ステータスコードと Location ヘッダーが順番に表示されます。ホップが 2 つ以上ないか、同じ URL が 2 回出てこないか（ループ）、Location の形式が不正でないか、最後のレスポンスが 200 以外になっていないかを確認します。

ターミナルを使いたくない場合は、SEOcrawl AI の Crawler のページにある無料の SEO 監査で、任意の URL のリダイレクトのホップ数を確認できます。また、SEOcrawl AI の MCP サーバーの fetch_url ツールを使えば、最終 URL、ステータスコード、リダイレクト チェーン全体を Claude、ChatGPT、Cursor で直接取得できます。

最終的なレスポンスコードを確認する

経路の最後の URL が、別の 3xx や 4xx、5xx ではなく 200 を返すことを確認します。チェーンがエラーで終わる場合、問題は転送先にあります。「見つかりませんでした（404）」やその他の 4xx エラーによるブロックのガイドをご覧ください。

原因別の修正方法

修正の考え方はほぼいつも同じで、元の URL を、きれいな 1 ホップで最終的な転送先に送ることです。

• ›チェーンが長すぎる： 最初の URL を最終的な 200 の URL に直接向け、途中のホップを削除します。複数の古い URL が同じチェーンにつながっている場合は、そのすべてを更新しましょう。
• ›リダイレクト ループ： 互いを指し合っている 2 つのルールを見つけ、どちらかを削除または修正して、経路が実在するページで終わるようにします。
• ›URL が長すぎる： URL に付け足し続けるルールを修正し、転送先が読み込まれることを確認します。
• ›転送先が不正または空： タイプミスや空の Location の値を修正し、絶対 URL を使います。
• ›転送先が robots.txt でブロックされている： 転送先のクロールを許可するか、ブロックされていない URL にリダイレクトします。
• ›ルールの競合： リダイレクトを 1 か所にまとめ、CMS、サーバー、CDN が互いに上書きしないようにします。

次に、内部リンクを更新して、リダイレクトする URL ではなく最終 URL を指すようにし、XML サイトマップにも最終 URL だけを載せます。Crawler は、3xx を返す内部リンクと、リダイレクトする URL を載せたサイトマップの両方を、サイト全体で検出します。サイトマップだけを確認したい場合は、無料のサイトマップチェッカーを使えば、載っているすべての URL のステータスコードとリダイレクト チェーンを検証できます。

リダイレクトのベストプラクティス

次の習慣を守れば、リダイレクト エラーのほとんどは未然に防げます。

• ›正しいステータスコードを使う。 301 リダイレクト（または 308）は、転送先をインデックスに登録すべきだという強いシグナルです。恒久的な移転に使いましょう。302 リダイレクト（または 307）は、元の URL を検索結果に残す弱いシグナルです。一時的な移転の場合だけに使います。
• ›サーバー側のリダイレクトを優先する。 Google は即時の meta refresh や JavaScript のリダイレクトもたどりますが、JavaScript はサーバー側のリダイレクトや meta refresh が使えない場合に限るよう推奨しています。
• ›チェーンを短く保つ。 理想は 1 ホップです。ホップが増えるたびにユーザーの待ち時間が延び、クロールバジェットを消費し、失敗の原因が 1 つ増えます。
• ›必ず 200 を返す URL にリダイレクトし、別のリダイレクトには向けない。
• ›内部リンクとサイトマップを最終 URL に更新し、Google と訪問者がリダイレクトを経由せずに済むようにする。
• ›サイト移行のたびに、また CMS、サーバー、CDN のルールを変更するたびに再確認する。新しいチェーンやループが生まれるのは、まさにそのタイミングです。

修正を検証する方法

リダイレクトが 1 ホップで 200 のページに到達するようになったら、次の手順を実行します。

1. ›対象の URL で URL 検査を実行し、公開 URL をテストをクリックして、Google が転送先にたどり着けるようになったことを確認します。
2. ›特に重要な URL については、インデックス登録をリクエストをクリックします。
3. ›「ページのインデックス登録」レポートで「リダイレクト エラー」の問題を開き、修正を検証をクリックして、対象のすべての URL を Google に再クロールしてもらいます。
4. ›検証のステータスを確認します。数日から 2 週間ほどかかることがあり、URL は再クロールされた順に問題の一覧から外れていきます。

リダイレクト エラーに先回りする

リダイレクト エラーは、自分から存在を知らせてはくれません。「ページのインデックス登録」レポートに表示されるだけで、大規模なサイトでは、トラフィックが落ちるまで誰にも気づかれないこともあります。すべてのプロパティの Search Console を手作業で確認するのは時間がかかり、つい後回しにしがちです。

SEOcrawl AI の Indexation ビューでは、URL を Search Console のカバレッジ状態ごとにまとめて表示するので、どの URL がエラー状態にあるかを把握し、その件数の推移を追跡できます。対象の URL には、ルール、手動、または MCP サーバー経由でタグを付け、1 件ずつ解決するまで対応を進められます。AI アシスタントを使っているなら、Google Search Console 監査で 1 つのプロンプトからインデックスのカバレッジを確認し、修正ごとにタスクを作成できます。

よくある質問

Google Search Console で「リダイレクト エラー」が発生する原因は何ですか？

Google は 4 つの原因を挙げています。長すぎるリダイレクト チェーン、リダイレクト ループ、最終的に URL の最大長を超えるリダイレクト URL、チェーン内の不正な URL または空の URL です。 いずれの場合も、Googlebot は正常に表示される最終ページにたどり着けません。

「リダイレクト エラー」はどう修正すればよいですか？

元の URL を、1 ホップで最終的な転送先に送ります。途中のリダイレクトを削除し、ループを解消して、最後の URL がステータス 200 を返すようにしましょう。内部リンクを転送先に向けてから URL 検査を実行し、「ページのインデックス登録」レポートで「修正を検証」をクリックします。

リダイレクト チェーンとリダイレクト ループとは何ですか？

リダイレクト チェーンとは、URL A から B、B から C というように、最終ページに着くまでリダイレクトが連続する状態です。リダイレクト ループとは、URL どうしが互いを指し合っているために終わらないチェーンです。どちらも、Google がインデックスに登録するページにたどり着けない原因になります。

301 と 302 はどちらを使うべきですか？

恒久的な移転には 301（または 308）を使います。Google はこれを、転送先をインデックスに登録すべきだという強いシグナルとして扱います。302（または 307）は一時的な移転の場合だけ、つまり元の URL を検索結果に残したいときだけに使いましょう。

「ページにリダイレクトがあります」と「リダイレクト エラー」は同じですか？

いいえ。「ページにリダイレクトがあります」は、リダイレクトが正常に機能したことを意味します。 その URL は別のページを指しているため、インデックスに登録されていないだけです。「リダイレクト エラー」は、Google がリダイレクトをたどろうとしたものの、正常なページにたどり着けなかったことを意味します。

「リダイレクト エラー」が解消されるまでどのくらいかかりますか？

修正を検証をクリックすると、Google はその後の数日間、場合によっては最長 2 週間かけて対象の URL を再クロールします。URL が処理されるごとにステータスが更新されるので、すべての URL について手動でインデックス登録をリクエストする必要はありません。