「ページにリダイレクトがあります」は放置していい？直すべきURLの見分け方と直し方

この記事のポイント

• 「ページにリダイレクトがあります」はエラーではなく、転送を検出したという報告であり、大半は放置して問題ありません。
• 放置か修正かは「意図した転送か」と「転送先が登録済みか」の2軸で決まり、サイトマップ内のURLに出た分だけが直す対象です。
• リダイレクトチェーンは5ホップ未満に統合し、302の放置は301へ直し、旧URLの転送は最低1年は維持するのが定石です。
• 広告の最終ページURLが転送元だとGCLIDやUTMが消えて計測が壊れるため、修正当日に実URLで確認してください。

Search Consoleを開いたら「ページにリダイレクトがあります」の件数が増えていた。赤くもなければ警告マークもないのに、インデックスされていないURLとして数百件並んでいる。放置していいのか、それとも何か壊れているのか。ここで手が止まる担当者は少なくないと思います。

先に方向性だけ言うと、「ページにリダイレクトがあります」は放置してよいものが大半です。ただし、ごく一部に本当に直すべきURLが紛れています。問題は、その一部をどう見つけるかです。

この記事では、Google Search Consoleの表示の意味、放置してよいURLと直すべきURLの仕分け方、URL検査ツールでの確認、原因別の直し方、修正後の待ち方までを順に整理します。最後に、広告を出しているサイト特有の落とし穴として、リダイレクトが広告計測を壊すケースも扱います。

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

Search Consoleの「ページにリダイレクトがあります」は、Googlebotがそのタイムに転送を検出したので、転送元URLはインデックスに登録しない、という状態を示す報告であり、エラーではありません。転送先のURLが代わりに評価されるため、転送が意図どおりであれば何も起きていないのと同じです。

Search Consoleがこのステータスを付ける仕組み

ページインデックス登録レポートとは、Search Console上でサイト内のURLがなぜインデックスされた／されていないのかを理由別に一覧するレポートです。「ページにリダイレクトがあります」はその「インデックス未登録」側の理由の1つとして並びます。

仕組みは単純です。Googlebotがクロールしたところ、そのURLが別URLへ転送していた。Googleは転送先を正とみなすので、転送元は登録対象になりません。レポートは、この振る舞いをそのまま件数として見せているだけです。

だから「インデックスされない」という言葉の印象ほど深刻ではありません。むしろ、登録されていない状態が正しい姿です。

HTTPS化・www統一・URL移転で出るのは正常

典型は次の3パターンです。

• http→httpsの統一で、旧httpのURLが転送されている
• wwwありなしの統一で、片方が転送されている
• サイトリニューアルやURL変更で、旧URLが新URLへ301リダイレクトされている

いずれも運用として正しい転送です。サイトを整えるほど、この表示は増えます。件数が多いこと自体は、健全に管理されているサイトでも普通に起きます。

一方で、似た名前の別ステータスと混同しないでください。同じレポートには、「クロール済み - インデックス未登録」の放置してよいURLと直すべきURLの判断基準や、「代替ページ（適切なcanonicalタグあり）」の意味と対処といった姉妹ステータスがあり、原因も対処も別物です。

放置してよいURLと直すべきURLはどう見分ける？

放置してよいのは「自分で意図した転送」で「転送先が登録済み」のURLだけで、それ以外の組み合わせが修正候補です。判断軸は2つで足ります。

判断表：意図した転送か×転送先が登録済みか

	転送先が登録済み	転送先が未登録・エラー
意図した転送	放置してよい（正常）	転送先側の問題を調べる（内容が薄い、noindex、404など）
意図していない転送	転送の原因を特定して外す	最優先で修正（転送設定とサイトマップの両方）

左上以外はすべて何らかの対応が要ります。ただ、右下に当たるものは実際には少ないはずです。

サイトマップ照合で問題URLだけを抽出する方法

数百件を1件ずつ目視する必要はありません。Onelyの解説記事「How To Fix “Page with redirect” in Google Search Console」では、レポートを「サイトマップ内のURLのみ」で絞り込み、そこに出たURLを問題候補とみなす診断法が紹介されています。

考え方はこうです。XMLサイトマップは「インデックスさせたいURLの一覧」です。そこに載せたURLが転送されているなら、自分で登録を望んだURLが登録されない状態なので、矛盾しています。日本の運用でも、そのまま使える基準だと思います。

手順は次のとおりです。

1. ページインデックス登録レポートを開き、画面上部の対象範囲のプルダウンを「サイトマップ内のURLのみ」に切り替える（表記は画面更新で変わることがあります）
2. 「ページにリダイレクトがあります」の行を開き、出てきたURLを書き出す
3. 0件なら、その表示はすべて放置で構いません
4. 1件以上あれば、そのURLが今日の修正対象です

サイトマップを自動生成しているサイトで、旧URLがそのまま残っているケースは、一般にありがちな原因です。

302のまま放置しているURLは要注意

SEOTestingの「How to Fix the “Page with Redirect” Error in Google Search Console」では、302を長く放置すると、Googleが実質的に301として扱い、旧URLが意図せずインデックスから外れる可能性があると指摘されています。一時的な転送のつもりだったURLほど危険です。

日本の広告運用の現場に引き寄せると、キャンペーンLPの一時転送を302で設定し、終了後も戻し忘れる、という形で起こりやすいと考えられます。転送が生きているURLを一度棚卸しし、恒久か一時かを決め直してください。

URL検査ツールで確認するにはどうすればいいか

転送元と転送先を1件ずつ検査する

URL検査ツールとは、Search Console上部の検索窓にURLを入れて、Googleがそのページをどう認識しているかを1件ずつ確かめる機能です。判断表の「転送先が登録済みか」は、この機能で確認できます。

リダイレクト元URLの検査で見る項目

対象の転送元URLを検査窓に入れ、次を確認します。

• 「ページのインデックス登録」欄に「ページにリダイレクトがあります」と出ているか
• 「ページの取得」が成功しているか
• 「ライブテスト」を実行し、転送先URLが自分の意図と一致するか

ライブテストは、今この瞬間の状態を見る機能です。設定を直した直後は、保存されている過去の結果ではなく、こちらで確認するのが確実です。

リダイレクト先URLが登録済みかの確認

転送先URLも、同じ手順で検査します。「URLはGoogleに登録されています」と出ていれば、判断表の左上に該当します。

登録されていない場合、理由は転送先側にあります。noindexが付いている、canonicalが別URLを指している、404を返している、といった具合です。実務でつまずくのは、転送元ばかり調べて転送先を見落とす点です。転送元がどれほど正しくても、行き先が登録されなければ、そのページは検索結果に出てきません。

直すべきリダイレクトの原因と直し方は？

直すべきリダイレクトは、チェーン・ループ・302の恒久化・意図しない転送・サイトマップの残骸の5類型に分けられ、原因ごとに対処が決まっています。ループは転送先が自分に戻る設定ミスなので、設定を1本に整理すれば直ります。

リダイレクトチェーンは5ホップ未満に統合する

リダイレクトチェーンとは、A→B→C→Dのように、転送が何段も連なる状態です。Search Engine Journalの記事「Google’s John Mueller Recommends Less Than 5 Hops Per Redirect Chain」によれば、Google（John Mueller）は、1本のチェーンを5ホップ未満に抑えるよう推奨しています。Googlebotは1回のクロールで追う転送数に限りがあり、通算10ホップを超えるとリダイレクトエラーとして扱われる、という説明です。

要注意なのは、http→https→www→末尾スラッシュ付き、と機械的に積み上がるパターンです。1つ1つは正しくても、リニューアルを重ねると気づかないうちに伸びます。

直し方は、途中を飛ばして最初のURLから最終URLへ直接転送することです。

# 修正前
/old → /old-2 → /old-3 → /new

# 修正後
/old → /new
/old-2 → /new
/old-3 → /new

301リダイレクトの.htaccessでの書き方と設計は、301リダイレクトの.htaccessでの書き方と設計にまとめています。

302を301に直すケース

恒久的に移したURLが302のままなら、301に書き換えます。302とは一時的な転送を示すステータスで、301は恒久的な移転を示します。逆に、期間限定のキャンペーンLPだけは302のままで構いません。ただし終了日を決め、外す日を運用メモに残すことをおすすめします。

WordPressやプラグインが作る意図しないリダイレクト

自分で設定していないのに転送されているなら、CMS側を疑ってください。

• パーマリンク設定の変更で、旧URLから自動転送が入る
• リダイレクト管理プラグインに、過去の設定が残っている
• SEOプラグインが、投稿名の変更時に転送を自動生成する
• 末尾スラッシュやカテゴリベースの正規化が働く

転送の出どころは、サーバー設定（.htaccessなど）、プラグイン、テーマ、CDNの4か所に分散しがちです。どこが転送しているかは、curlなどで応答ヘッダーを見れば手がかりになります。

サイトマップと内部リンクを最終URLに張り替える

転送自体が正しくても、サイトマップと内部リンクが旧URLのままだと、転送のたびにクロールが余計に使われ、表示も減りません。Ahrefsの「301 Redirects Explained: How They Impact SEO」でも、内部リンクを最終URLへ張り替えることが定石として挙げられています。

サイトマップは、最終URL（200を返す正規URL）だけに整理します。ナビゲーションやフッター、記事内リンクも、一括置換で最終URLへ揃えてください。

修正後どのくらいでインデックスに反映される？

修正後の反映は一般に数日から数週間かかるので、待つ間にURL検査から登録をリクエストし、旧URLの転送は最低1年は残す運用が基本です。

インデックス登録リクエストと待ち方

流れは次のとおりです。

1. URL検査で転送先（最終URL）を検査する
2. 「インデックス登録をリクエスト」を押す
3. レポートの該当ステータスを開き、「修正を検証」を押す
4. 以降は待つ

インデックス登録リクエストは順番待ちの合図であり、即時反映の保証ではありません。同じURLに何度も送っても、早くなるわけではないので、1回で十分です。検証は数日から数週間かかることがあり、途中で「検証中」のまま動かない時期もあります。待つ間に設定を再度いじると、Googleの再クロールと噛み合わなくなるため、直したら触らないほうが安全です。

リダイレクトはいつ外していいか（1年ルール）

Ahrefsの記事では、Googleが旧URLの評価を新URLへ引き継ぐ処理を終えるまで、リダイレクトを最低1年間は維持するよう推奨されています。日本の運用でも、この基準は保持の目安として採用しやすいと思います。

1年経ったからといって、すぐ外す必要はありません。外部サイトからのリンクや、ブックマーク、広告の古い設定が旧URLを指している間は、転送を残すほうが安全です。外すなら、アクセスログで旧URLへの流入が十分に減ってからにしてください。

広告を出しているサイトの盲点：リダイレクトは計測も壊す

広告の計測が消えていて焦る

リダイレクトは、転送の仕方によってはGCLIDやUTMパラメータを落とすため、SEOの問題である前に広告CVの計測を壊す問題にもなります。Search Consoleの件数だけを見ていると、この被害は見つかりません。

広告の最終ページURLがリダイレクト元になっていないか

GCLIDとは、Google広告が自動タグ設定で最終ページURLへ付与するクリックIDです。広告のリンク先が転送元URLだと、転送の途中でクエリ文字列が剥がれ、着地したページにGCLIDが残らない場合があります。

確認の順番は次のとおりです。

1. Google広告の管理画面で、広告と、そのキャンペーンLPの最終ページURLを書き出す
2. Search Consoleで「ページにリダイレクトがあります」に出ているURLと突き合わせる
3. 重なったURLは、リンク先を最終URLへ直接差し替える

キャンペーンLPの一時転送を302で組んだまま、広告のリンク先が旧URLのまま、という状況は、業界で起こりうる典型だと考えられます。

パラメータ引き継ぎの確認方法

実際にパラメータ付きのURLで試すのが最も確実です。

curl -sIL "https://example.com/old?utm_source=test&gclid=test123"

応答のLocation:ヘッダーに、utm_sourceやgclidが残っているかを見ます。ブラウザで開き、転送後のアドレスバーを確認する方法でも構いません。

パラメータが消えていた場合は、サーバー設定でクエリ文字列を引き継ぐ形に直します。GCLIDが消える原因と対処は、GCLIDがリダイレクトで消える原因と対処手順で扱っています。アクセス解析側では、リダイレクトでutmパラメータが消えて(not set)になる原因も合わせて確認してください。

よくある質問

Q：「ページにリダイレクトがあります」は放置しても大丈夫ですか？

意図した301で、転送先がインデックス登録済みなら放置して問題ありません。判断は「意図した転送か」と「転送先が登録済みか」の2軸で行い、サイトマップ内のURLに出ているものだけを修正対象にします。詳しい仕分けは、本記事の判断表を使ってください。

Q：「リダイレクトエラー」と「ページにリダイレクトがあります」の違いは何ですか？

「リダイレクトエラー」は、ループや過剰なホップ数のために転送を最後まで追えない異常です。一方「ページにリダイレクトがあります」は、転送を正常に検出したという報告にとどまり、異常を示すものではありません。前者は修正が必要で、後者は多くが放置できます。

Q：修正してからインデックスに反映されるまでどのくらいかかりますか？

数日から数週間が目安です。URL検査から最終URLの登録をリクエストし、レポートで「修正を検証」を押したら、再クロールを待ってください。何度もリクエストしても、反映は早まりません。

Q：リダイレクトの件数が増え続けていますが問題ですか？

サイトマップ内のURLに出ていなければ、多くは無害です。増える要因は、パラメータ付きURLや旧URLが、外部リンクや内部リンクから引き続き発見されることです。サイトマップ照合で、直すべきURLだけを確認してください。

「ページにリダイレクトがあります」は、慌てて全件を消しにかかる表示ではありません。サイトマップ照合で直すべきURLを絞り、そこだけを直せば足ります。真策堂では、SEOと広告計測をまたいだ観点で、こうしたリダイレクトの棚卸しの相談を受けています。転送の設計や計測への影響を整理したいときは、お気軽にご相談ください。

「リダイレクトエラー」と表示されたときは何を調べる？

同じレポートに「リダイレクトエラー」と出ている場合は、放置できる報告ではなく、Googlebotが転送を最後まで追えなかったという扱いになります。Search Consoleヘルプのページインデックス登録レポートの説明では、原因として次の4つが挙げられています。

• リダイレクトチェーンが長すぎる
• リダイレクトループが発生している
• リダイレクトURLが最終的にURLの最大長を超えた
• リダイレクトチェーンに不正なURLまたは空のURLがある

チェーンとループは本文の直し方で対処できますが、見落としやすいのは後ろの2つかなと思います。転送のたびにパラメータが付け足されてURLが伸び続ける設定や、転送先を変数で組み立てていてLocation:ヘッダーが空や相対パスの崩れた形になっているケースが当てはまります。

切り分けは、該当URLにcurl -sILを実行し、各段のLocation:を上から順に読むのが早いです。同じURLが2回出てくればループ、段を追うごとにURLが長くなっていればパラメータの付け足し、Location:が空ならテンプレートや変数の不具合、と見当がつきます。

meta refreshやJavaScriptの転送でも同じ表示になる？

サーバーの301や302だけでなく、HTML側で行う転送もGoogleはリダイレクトとして扱います。Google検索セントラルの「リダイレクトとGoogle検索」では、meta refreshは待ち時間0秒の即時転送なら恒久的、秒数を置いた遅延転送なら一時的な転送として解釈されると説明されています。

JavaScriptによる転送も認識はされますが、同じドキュメントで、サーバー側の転送やmeta refreshが使えない場合に限って使うよう案内されています。Googleがページをレンダリングして初めて転送に気づく仕組みなので、レンダリングに失敗すると転送として扱われない可能性があるためです。

ここで困るのは、サーバー設定をいくら探しても転送が見つからないパターンだと思います。curl -sIの応答が200なのにブラウザでは別URLへ飛ぶなら、HTML内の<meta http-equiv="refresh">か、location.hrefなどを書き換えるスクリプトを疑ってください。タグマネージャー経由で配信したスクリプトや、A/Bテストツールの振り分けが転送元になっていることもあります。恒久的な移転であれば、サーバー側の301へ置き換えるほうが確実かなと思います。

ブラウザでは転送されないのに表示が消えないのはなぜ？

自分のブラウザで開くと普通に表示されるURLが「ページにリダイレクトがあります」に入っている場合、アクセス元の条件で転送が出し分けられている可能性があります。Googlebotは主にスマートフォン用のユーザーエージェントでクロールし、Googleのドキュメントによればアクセス元は主に米国のIPアドレスです。そのため、次のような転送は手元のPCでは再現しません。

• スマートフォンだけを別URL（m.やsp/など）へ送る振り分け
• IPアドレスやブラウザの言語設定で、国別・言語別ページへ送る自動転送
• 未ログインのアクセスを、ログイン画面や年齢確認ページへ送る転送

確認には、URL検査ツールのライブテストで取得されたページを見るのが近道です。手元で試すなら、curl -sIL -Aでスマートフォン用Googlebotのユーザーエージェントを指定すると、PCとは違う応答が返ってくるかを比べられます。

国や言語による自動転送は、Googleが全言語版をクロールできなくなる恐れがあるとして、多地域・多言語サイト向けのドキュメントでも避けるよう案内されています。強制的に転送するより、hreflangで各言語版を示し、ページ上に切り替えリンクを置く形のほうが安全だと思います。ログイン画面への転送は意図どおりの挙動なので、そのURLがサイトマップに載っていないかだけ確認すれば足ります。