ページにリダイレクトがあります：問題が隠れているケース

Search Console の「ページにリダイレクトがあります」（英語版では "Page with redirect"）は、Google が URL をリクエストしたところサーバーが別の場所に転送したため、リストに表示されている URL ではなく転送先がインデックス登録の対象として検討されていることを意味します。ほとんどの場合、これは HTTPS への移行、www の有無の統一、URL の変更などの後に、リダイレクトが設計どおりに動いている状態です。問題になるのは、転送先が誤っているかインデックスに登録されていない場合や、自サイトのサイトマップ、リンク、canonical タグが Google を古いアドレスに送り続けている場合です。

Google によるこのステータスの説明

Google のページ インデックス登録レポートのドキュメント（2026 年 10 月に確認）は、これを「別のページにリダイレクトする正規以外の URL」と説明し、この URL は「インデックスに登録されません」と付け加えています。そして転送先については、「その URL に対する Google の評価によって、インデックスに登録される場合も、登録されない場合もあります」としています。

この説明から、2 つのことが言えます。

• このステータスは転送元の URL についてのものであり、転送先についてのものではない。 リストに http://example.com/pricing があっても、https://www.example.com/pricing がインデックスに登録されているかどうかは何もわかりません。転送先は別途確認します。
• リダイレクトの種類が重要。 Google のリダイレクトに関するドキュメント（2026 年 10 月に確認）は、リダイレクトを 2 つのグループに分けています。恒久的なもの（HTTP 301 と 308、0 秒に設定された meta refresh または HTTP refresh、JavaScript の location によるリダイレクト）は、転送先を正規 URL にすべきだというシグナルとして使われ、検索結果には転送先が表示されます。一時的なもの（302、303、307、遅延のある meta refresh または HTTP refresh）は、たどられはするもののそのシグナルとしては使われないため、検索結果には転送元の URL が表示されます。JavaScript によるリダイレクトは、Google がページを正常にレンダリングできた場合にしか認識されません。

これは「リダイレクト エラー」とは別のステータスです。「リダイレクト エラー」は、ループ、長すぎるチェーン、URL の最大長を超えたリダイレクト URL、チェーン内の不正な URL や空の URL など、Google が完了できなかったリダイレクトに使われます。

リダイレクトする URL はどこから生まれるのか

健全なサイトでは、このリストの URL の大半は次のような正常な発生源から生まれます。

1. プロトコルとホストの正規化。 http:// から https:// へ、apex ドメインから www へ、またはその逆。
2. 末尾のスラッシュの正規化。 プラットフォームやサーバーの既定値による、/blog から /blog/ への転送。
3. 移行と URL の変更。 新しいドメイン、新しいパスの体系、名称を変えた商品など。たとえば WordPress では、投稿のスラッグを編集すると、古いスラッグから新しいパーマリンクへ 301 が送られます。
4. 後継ページに統合された古いページ。 古いガイドを新しいガイドに統合した場合など。

問題のあるパターンは、いずれも自サイトが行っていることです。

1. サイトマップにリダイレクトする URL が掲載されている。 2026 年 5 月から 10 月に SEOReport がサイトマップのページを取得した外部ウェブサイト 29 件のうち、6 件（21%）が、別の場所にリダイレクトする URL を XML サイトマップに掲載していました。
2. 内部リンク、canonical タグ、hreflang アノテーションが古い URL を指している。 ナビゲーションのテンプレート、本文中の古いリンク、http:// でハードコードされた canonical タグが、Google にリダイレクトするアドレスを与え続けています。
3. リダイレクトの転送先が誤っている。 Google のサイト移転に関するガイダンス（2026 年 10 月に確認）は、多数の古い URL をホームページなど無関係な 1 つのページにリダイレクトすると、「ソフト 404 エラーとして扱われる可能性があります」と警告しています。
4. リダイレクトがチェーンになっている、または恒久的であるべきなのに一時的になっている。 転送先に着くまでに何度も経由している、あるいは元に戻す予定のない移行の後に 302 が残っている状態です。

このサンプルでは、3 つの矛盾したシグナルのうちリダイレクトが最も多く見られました。そのどれもが、本当の URL ではないと Google にすでに伝えた URL を、インデックスに登録するよう求めていることになります。

問題なのか：放置、修正、経過観察

flowchart TD
    A["「ページにリダイレクトがあります」と表示された URL"] --> B{"意図してリダイレクトしたか"}
    B -->|いいえ| C["リダイレクトを削除するか、ページを復元する"]
    B -->|はい| D{"転送先は正しい後継ページか"}
    D -->|いいえ| E["最も近い同等のページに転送するか、404 か 410 を返す"]
    D -->|はい| F{"経由は 1 回で、恒久的か"}
    F -->|いいえ| G["1 回の 301 または 308 にまとめる"]
    F -->|はい| H{"サイトマップ、リンク、canonical が古い URL を指しているか"}
    G --> H
    H -->|はい| I["すべての参照を最終 URL に更新する"]
    H -->|いいえ| J{"転送先はインデックスに登録されているか"}
    I --> J
    J -->|はい| K["放置する"]
    J -->|いいえ| L["転送先自身のステータスを確認する"]

どの原因に当てはまるかを確認する方法

サイトマップ フィルタから始める。 ページ インデックス登録レポートの上部で、フィルタを「すべての既知のページ」から「送信されたすべてのページ」に切り替え、もう一度「ページにリダイレクトがあります」を開きます。そこに残っている URL は、いずれかのサイトマップが送信している、リダイレクトする URL です。例の表は 1,000 行までに制限されているため、大規模なサイトでは、サイトマップ自体も直接テストしてください（下記参照）。

いくつかの URL を検査する。 Google の URL 検査ツールのドキュメントによると、インデックス登録済みの結果は、リダイレクトの転送先ではなく入力した URL を反映しています。問題の発生源を示す欄が 2 つあります。「参照元ページ」には Google が URL を見つけるのに使った可能性のあるページが、「サイトマップ」にはその URL を掲載しているサイトマップが表示されます。参照元ページが自サイトにあれば、更新すべき内部リンクがあるということです。他のサイトにあれば、リダイレクトは役目を果たしています。

経由を自分でたどる。 同じドキュメントによると、公開 URL のテスト（「公開 URL をテスト」）は、何も示さずにリダイレクトをたどり、テストした最終 URL を表示しません。ターミナルなら、すべての経由が表示されます。

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

301 か 308 が 1 つあり、その後に 200 が 1 つ続けば、きれいなリダイレクトです。リダイレクトの行が 2 つ以上あればチェーンであり、恒久的な移転で 302 や 307 を使っているなら変更すべきです。

転送先は別に検査する。 最終 URL を URL 検査ツールに貼り付けます。インデックスに登録されていなければ、問題はそのページにあり、そのページ自身のステータスがどこを見るべきかを教えてくれます。転送先に noindex がある場合は「URL に noindex が指定されています」で、Google が取得したもののインデックスに登録しなかった場合は「クロール済み - インデックス未登録」で扱っています。

古い URL を指したままの自サイトのファイルを見つける

Search Console に表示されるのは、検出元のサンプルです。自サイトのファイルを調べれば、すべてがわかります。サイトマップに掲載されたすべての URL をテストし、200 を返さないものを出力します。

curl -s https://www.example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' | sed -e 's/<loc>//' -e 's/<\/loc>//' -e 's/&amp;/\&/g' \
  | while read -r url; do
      code=$(curl -s -o /dev/null -w '%{http_code}' "$url")
      [ "$code" != "200" ] && echo "$code $url"
    done

出力に 301、302、307、308 があれば、それはリダイレクトする項目です。ファイルがサイトマップ インデックスの場合は、そこに掲載された子サイトマップごとに同じループを実行し、.xml.gz ファイルは先に解凍してください。次に、すべてのページが共有するテンプレートを確認します。ヘッダーのリンク 1 つがすべての URL で繰り返されるからです。

curl -s https://www.example.com/ \
  | grep -oE '(href|content)="[^"]+"' \
  | grep -E 'http://|//example\.com'

最後のパターンは、移行前の古いプロトコル、ホスト、パスに置き換えてください。WordPress では、古い絶対 URL はたいてい投稿の本文に残っています。WP-CLI を使えば、何かを変更する前にその数を数えられます。

wp search-replace 'http://example.com' 'https://www.example.com' --dry-run

実際に実行するときは、先にデータベースのバックアップを取り、--skip-columns=guid を付けて、投稿の GUID が元の値のまま残るようにしてください。

原因ごとの修正方法

サイトマップの項目。 最終 URL だけでサイトマップを生成し直します。各項目は 200 を返し、自分自身を canonical として指定している必要があります。Google のサイトマップに関するドキュメント（2026 年 10 月に確認）は、検索結果に表示させたい URL を含めるよう求めており、リダイレクトする URL はそれに当たりません。Google の正規化に関するドキュメントには、サイトマップに掲載されたページはすべて正規 URL の候補として提案されるとも書かれています。きれいなサイトマップのその他の要件は、XML サイトマップのガイドで解説しています。

内部リンク、canonical タグ、hreflang。 転送先の URL に更新します。Google の正規化に関するドキュメント（2026 年 10 月に確認）は、重複ではなく正規 URL にリンクするよう勧めています。リダイレクトする URL を指定した canonical タグは、ページの存在しないアドレスにシグナルを統合するよう Google に求めることになります。これらのシグナルがどう組み合わさるかはcanonical タグのガイドで、ホストやプロトコルのバリエーションがまったくリダイレクトされていないケースは「重複していますが、ユーザーが正規ページとして選択していません」で扱っています。

誤った転送先。 古い URL を、それぞれ最も近い同等のページに向けます。後継ページがない場合は、404 か 410 を返すのが正直な答えです。そうすれば、無関係なページへのリダイレクトについて Google が説明しているソフト 404 としての扱いも避けられます。

チェーンと一時的なリダイレクト。 入口の URL から最終 URL へ直接転送する 1 つのルールを、301 か 308 で書きます。リダイレクト チェーンが生じる仕組みと平坦化する方法では 4 回経由する例を詳しく扱っており、リダイレクトと URL 正規化のガイドでは、プロトコル、ホスト、スラッシュのルールをまとめて解説しています。

リダイレクト自体は残しておく。 Google のサイト移転に関するガイダンスは、リダイレクトはできるだけ長く、一般的には少なくとも 1 年間は維持するよう求めています。自サイトの参照をすべて修正した後も、外部リンクやブックマークからは長い間古い URL へのアクセスが続きます。

修正を検証する方法

1. サイトマップのループを再実行する。 何も出力されないはずです。
2. 古い URL のサンプルで経由の確認を再実行する。 恒久的な経由が 1 回、その後に 200 が返り、正しいページに着くはずです。
3. Search Console のサイトマップ レポートでサイトマップを再送信し、Google にもう一度読むよう依頼します。
4. 「送信されたすべてのページ」フィルタを見守る。 Google がサイトマップを読み直し、それらの URL を再クロールすれば、リダイレクトする URL はこのフィルタから消えるはずです。Google の再クロールに関するドキュメントによると、クロールには数日から数週間かかることがあり、そのスケジュールを決めるのはあなたではなく Google です。
5. 「修正を検証」は、削除したリダイレクトにだけ使う。 検証では影響を受けた URL が再クロールされ、それぞれにまだ問題があるかどうかが確認されますが、意図的なリダイレクトは設計上リダイレクトし続けます。Google のドキュメントによると、検証には通常最長で約 2 週間かかり、場合によってはさらに長くかかります。

Search Console では、どの URL がリダイレクトしているかがわかります。SEOReport の完全な診断では、サイト自体を監査し、告知すべきでないリダイレクトを特定します。サイトマップに掲載されたページの中のリダイレクトする URL（転送先付き）、リダイレクトするホームページの canonical の指定先や別言語版の指定先、そして送信したアドレスが 2 回以上経由する場合のすべての経由です。内部リンクのリダイレクトはテストしないので、それについては上記のテンプレートの確認を実行してください。

よくある質問

リダイレクトする URL がレポートから消えることはありますか？

「すべての既知のページ」の表示には、長い間残ることがあります。Google は、他のサイトからリンクされている URL も含め、すでに把握している URL を再クロールし続けるからです。リダイレクトが意図どおりで転送先がインデックスに登録されていれば、それが正しい最終状態です。減らすべきなのは、そのうち自サイトのサイトマップが送信している URL の数です。

ホームページが「ページにリダイレクトがあります」に表示されています。問題ですか？

表示されている URL は通常、http://example.com/ のようなバリエーションで、優先する https://www.example.com/ にリダイレクトしています。優先するホームページの URL を検査してください。インデックスに登録されていれば、バリエーションは正しく動作しています。優先する URL そのものがリストに表示されている場合は、ホームページが意図しない場所にリダイレクトしているので、修正が必要です。

リダイレクトの代わりに canonical タグを使うべきですか？

古い URL で誰にもそのページを見せる必要がないなら、リダイレクトを使います。同じ商品一覧の絞り込み表示のように、両方の URL が機能し続ける必要があるなら、canonical タグを使います。別の URL を指す canonical を持ったまま公開され続ける URL は、Google がその canonical を受け入れれば通常「代替ページ（適切な canonical タグあり）」として報告され、対応は不要です。