Search Console の「リダイレクトのあるページ」：どの URL を確認する？

サービスページを /old-service から /services/design に移動したとします。その後、Search Console で古いアドレスが「リダイレクトのあるページ」に表示されました。新しいページはブラウザで開けます。古いアドレスもインデックスに登録する必要があるのでしょうか。

通常、確認すべきなのは、古いアドレスが、実際に見つけてもらいたいページに利用者を導いているかどうかです。Google はこのステータスを、別のページにリダイレクトする非正規 URL と説明しています。このステータスの元 URL はインデックスに登録されません。移動先は登録される場合も、されない場合もあります。別のレポート項目である「リダイレクト エラー」は、ループや長すぎるチェーンなど、Google がリダイレクトをたどる際に遭遇した問題を示します。

上の例は説明用であり、顧客サイトの調査結果ではありません。サイト全体のリダイレクトを変更する前に、重要な URL を一つ確認する方法を見ていきます。

元の URL と意図した移動先を記録する

Search Console でページのインデックス登録レポートを開き、「リダイレクトのあるページ」を選んで URL を一つ選びます。http または https、ホスト名、パス、末尾のスラッシュ、クエリパラメータを含む完全なアドレスをコピーします。レポートに Google の最終クロール日が表示されていれば、その日付も記録します。

次に、報告された URL（元の URL）と、訪問者を到達させたいアドレス（移動先）の両方を書き留めます。古いサービスページから代替ページへの移動は意図したものかもしれません。一方、有料キャンペーンの URL が無関係なホームページに訪問者を送る場合は、詳しい確認が必要かもしれません。

このレポートに URL があることだけでは、移動先がインデックスに登録されたことも、リダイレクトが順位を損なったことも証明できません。また、どの設定がリダイレクトを作成したかも分かりません。

ログインせずにアドレスをたどる

プライベートブラウザで元の URL を開き、アドレスバーに最後に表示されたアドレスを記録します。期待したページと内容にたどり着きますか。ログイン画面、別の言語、無関係なサービス、エラーに移動する場合は、何がいつ起きたかを記録します。プライベートブラウザが示すのはその訪問者の経路です。たとえばユーザーエージェントによってルールが変わる場合、Googlebot が異なる応答を受け取ることもあります。

最終アドレスが予想と異なる場合は、ホスティングサービスのリダイレクトツールか、各応答とその Location ヘッダーを表示するウェブデバッグツールで経路を確認します。チェーンの例は次のとおりです。

/old-service → /services → /services/design

このチェーンはあくまで例です。途中の段階が前のアドレスに戻る場合や、無効または空の移動先を指す場合は、その段階を調べます。Google は「リダイレクト エラー」の例として、ループ、長すぎるチェーン、無効または空の URL、最終的に長くなりすぎる URL を挙げています。「リダイレクトのあるページ」という項目があるだけで、そのいずれかのエラーが起きたとは限りません。

プラットフォームを利用している場合、リダイレクトは管理画面、プラグイン、ウェブサーバー、CDN など別の層で設定されていることがあります。異なる層のルールが競合することもあるため、変更する前に経路を追い、各ルールがどの層にあるか確認します。非公開 URL、アクセストークン、顧客情報を公開デバッグサービスに貼り付けないでください。

移動先を別の URL として検査する

URL 検査で元の URL のインデックス登録済みデータとクロール日を確認します。その後、意図した移動先を別の URL として検査します。元の URL のレポートでは、移動先のインデックス登録状況は確定しません。移動先が検査できるプロパティの外にある場合は、公開状態でアクセスできるかを確認し、適切であれば所有者に尋ねます。Search Console の登録状況を確認できない場合もありますが、検査結果がないことは未登録の証拠ではありません。

Google によると、ライブテストはリダイレクトをたどって最終 URL を検査しますが、リダイレクトをたどったことや最終的にどのアドレスを検査したかは表示しません。したがってライブテストは現在のアクセス確認には役立ちますが、元の URL から移動先までの経路確認の代わりにはなりません。ライブ結果はインデックス登録も保証せず、Google が選ぶ正規 URL も予測しません。Google に記録されたインデックス情報と日付を比較し、別々の観察として扱います。

移動先がインデックス未登録なら、その移動先に報告された理由を検査します。たとえば、移動先に意図的に設定された noindex は、元のアドレスが正しくリダイレクトしていることとは別の問題です。移動先自身のインデックス登録理由に対処します。元の項目を消すためだけに正常なリダイレクトを削除しても、移動先の noindex は解決しません。

残すか修正するかを決める

古いアドレスが意図どおり関連する代替ページに確実に移動し、その代替ページこそ訪問者に見つけてほしいページなら、ステータスだけを理由にリダイレクトを削除する必要はありません。古いアドレスを使える状態に保つことは、既存リンクをたどる人の助けにもなります。Google はリンクやその他の発見元を通じて古いアドレスに引き続き出会うことがあります。レポートに項目が残っていても、発見元は特定できず、現在のサイトマップにまだ含まれる証拠にもなりません。

重要なページが予期せず間違った移動先にリダイレクトする場合は、原因のルールを探して修正します。商品ページが無関係なホームページに移動する場合と、古い URL が代替ページに移動する場合は異なります。削除したページに適切な代替がなければ、404 Not Found または 410 Gone の応答が適切な場合があります。無関係な削除済みページをホームページにリダイレクトすると、ソフト 404 として扱われることがあります。

恒久的な移動について、Google のガイドは 301 や 308 などの恒久リダイレクトを、移動先を正規 URL とすべきだというシグナルとして扱います。302 や 307 などの一時リダイレクトは意味が異なります。Google は正しく解釈できる可能性が高い方法の先頭にサーバー側リダイレクトを挙げています。移動を長期間続ける意図があるかに基づいて選びます。Google が選ぶ正規 URL は希望と異なる場合があります。

自分で管理するリンクを意図したページに向ける

現在のサイトマップや内部リンクがまだ古い URL を使っている場合は、適切な箇所を意図した移動先に更新します。たとえば /old-service から /services/design への移動後、自分で管理するナビゲーションリンクを /services/design に直接向けられます。更新できない古いリンクのためにリダイレクトは残します。自分のナビゲーションを変更しただけで削除しないでください。

この整理は訪問者に直接の経路を提供し、優先するアドレスを Google により明確に伝えます。インデックス登録を約束するものではなく、ウェブ上の古いリンクをすべて置き換える理由にもなりません。Search Console には、現在のサイトマップ以外から見つかった URL が表示されることもあります。

一つの経路を再確認し、結果を記録する

修正後、元の URL から移動先までの確認を繰り返し、移動先をもう一度検査します。元の URL、最終 URL、確認した応答やリダイレクトの段階、行った変更、日付を記録します。実際の問題を修正した場合、Search Console には Google に再確認を依頼する検証機能があります。検証は移動先のインデックス登録や、レポートが特定の日に更新されることを保証しません。

ホームページを別途確認する場合、SEOHabit のウェブサイト SEO チェッカーは登録後、ホームページに範囲を限定した初回チェックを提供します。この初回チェックにサイト所有権の確認は不要ですが、継続的なチェックには必要です。Google が特定のリダイレクト先を選んだ理由をこのツールで判断することはできません。その確認には Search Console と実際のリダイレクト経路を使ってください。

リダイレクトは不具合ではなく、意図した経路の場合があります。レポートの正確なアドレスから始め、どこに移動するか確認し、実際に見つけてもらいたいページを検査しましょう。

参照：Google のページ インデックス登録レポート（https://support.google.com/webmasters/answer/7440203）、URL 検査のヘルプ（https://support.google.com/webmasters/answer/9012289）、リダイレクトのガイド（https://developers.google.com/search/docs/crawling-indexing/301-redirects）。