サイトマップ送信後もインデックスされないときの確認手順

サイトマップを送信しても、そこに含まれるURLのインデックス登録が保証されるわけではありません。送信後も特定のURLが登録されないときは、サイトマップ全体の状態と、そのURL自体の状態を分けて確認する必要があります。

サイトマップの取得エラーがあれば、ファイルの配信や生成を確認します。正常に読み込まれているなら、対象URLをURL検査で調べます。そこで表示される過去の情報と現在のページを比べると、まだ修正が必要なのか、Googleの再取得を待つ状態なのかを区別できます。

ここから示すのは、AdRegionで問題を切り分けるときの実務上の順序です。Googleが定めた唯一の確認手順ではありません。

サイトマップ全体の処理状況だけでは対象URLの掲載まで分からない

最初に見るのは、Search Consoleのサイトマップレポートです。このレポートでは、送信日や最終読み込み日時を確認できます。ファイルを取得できたか、何件のページを検出したかも表示されます。ただし、ここで分かるのはサイトマップ全体の処理状況です。

レポートに「成功」と表示されていても、個別URLのクロールやインデックス登録まで成功したという意味ではありません。検出ページ数も登録ページ数ではないため、その数字から対象URLの状態を推測しない方がよいです。Googleのサイトマップレポートに関する説明でも、レポートの対象は送信したサイトマップの処理状況として案内されています。

次に、現在公開されているXMLを開きます。対象URLが完全な形で含まれているかを確かめてください。まず、HTTPとHTTPSが一致しているかを見ます。続いて、wwwの有無と末尾のスラッシュを照合します。

サイトマップレポートの最終読み込み日時が古い場合は、Search Consoleが保持する結果と現在のXMLにも時点差があります。掲載する予定のURLが現在のXMLにない場合は、サイトマップの生成処理を確認します。ただし、Googleはページ間のリンクからもURLを発見するため、XMLへの掲載漏れだけでは未登録の原因と断定できません。XMLには載っているものの取得時にエラーが出ていれば、ファイルの配信や送信先を確認するのが先です。

サイトマップは、Googleに把握してほしい正規URLを伝えるために使います。Googleのサイトマップ作成ガイドでも、その役割が説明されています。サイトマップ全体を確認したら、次は対象URLの状態へ進みます。

ページのインデックス登録レポートでは影響範囲をつかめる

サイトマップ側に明確な問題がなければ、ページのインデックス登録レポートで同じ状態のURLがどの程度あるかを見ます。ここでの目的は、対象URLだけの問題なのか、複数のURLに共通する状態なのかを知ることです。

同じ状態が多数のURLに見られるなら、共通するテンプレートや公開設定を確認するきっかけになります。一つのURLだけなら、そのページに固有の設定へ早めに進めます。ただし、レポートに表示されるURLは例示であり、該当URLをすべて網羅するものではありません。ページのインデックス登録レポートの案内でも、特定URLの確認にはURL検査を使うよう示されています。

この段階では、状態名だけで原因を決めません。たとえば未登録を示す状態が表示されていても、それだけを根拠に「内容が薄い」「品質が低い」と断定することはできません。集計レポートでは影響範囲をつかみ、個別の原因は次の確認で切り分けます。

URL検査の登録済み情報と公開URLテストでは確認時点が異なる

影響範囲を確認したら、診断の単位を対象URLへ移します。ここで注意したいのは、URL検査を開いたときの情報と、公開URLテストの結果では対象と時点が異なることです。

URL検査にはGoogleが保持する直近の情報が表示される

URL検査を開いたときに表示されるのは、Googleインデックスが保持している直近の情報です。現在公開されているページを、その場で取得した結果ではありません。前回クロール日時を修正の公開日時と照合すると、変更がそのクロールより後に行われたかが分かります。取得できたかどうかは、ページ取得の結果で確認します。

ページを修正した日時が前回クロールより新しければ、Googleがまだ古い版を見ている可能性があります。反対に、クロール日時が修正後でも、修正済みの内容を取得したとは限りません。取得したHTMLを表示できる場合は変更箇所を確認し、現在のページや公開URLテストの結果と比べます。

URL検査では、ユーザーが指定した正規URL（canonical）とGoogleが選択した正規URLも確認できます。二つが異なる場合は、Googleが選んだURLが意図したものかを見ます。ただし、現在のページが指定しているcanonicalまで同じだとは決めつけません。

公開URLテストは実行時点の取得状態を調べる

公開URLテストは、実行した時点でGoogleの検査用クローラーがページを取得できるかを調べる機能です。登録済み情報を上書きする検査ではないため、二つの結果が違っていても矛盾とは限りません。

テストが通れば、現在の取得を妨げる問題が見つからなかったことは確認できます。しかし、インデックス登録の保証にはなりません。GoogleがどのURLをcanonicalとして選ぶかも、公開URLテストからは確定できません。URL検査ツールの公式ヘルプには、公開URLテストが確認しない項目や登録を保証しないことも示されています。

テストがリダイレクトをたどった場合は、最終的にどこへ到達したかを別の方法で確かめます。公開URLテストだけでは、リダイレクトの経路や最終到達URLを診断しきれないためです。

現在のHTTP応答と公開設定を分けると修正箇所が見える

Search Consoleの情報を時点ごとに分けたら、現在の公開状態を直接確認します。まずHTTP応答を調べ、ブラウザから到達するURLを確定します。ページへ到達できることが分かったら、Googlebotがクロールできるかを見ます。その後にインデックス登録を止める指定とcanonicalを確かめると、役割の異なる設定を混同せずに済みます。

HTTP応答は最終到達URLまで見て判断する

対象URLへアクセスしたときは、最初の応答だけでなくリダイレクト後の到達先まで確認します。意図した最終URLが2xxを返していれば、HTTP応答の点ではGoogleがインデックス登録を検討できる状態です。ただし、2xxだから登録されるとは限りません。

3xxで別のURLへ移る場合、Googlebotが転送をたどれれば、リダイレクト元の本文ではなく最終的な転送先のコンテンツが処理されます。期待していないURLへ転送されている場合は、登録を待つ前にリダイレクト設計を見直します。

Googleは、429を除く4xxを返すURLをインデックスに登録しません。5xxと429が続くとクロール頻度が下がり、登録済みURLも最終的にインデックスから削除されることがあります。どちらもページ内容を直す前に、意図したURLが適切なHTTP応答を返すよう修正します。GoogleによるHTTPステータスコードの説明では、応答ごとの基本的な扱いを確認できます。

robots.txtとnoindexでは制御する対象が異なる

robots.txtは、主にクローラーがURLへアクセスできるかを制御します。一方のnoindexは、取得したページをインデックスへ登録しないよう伝える指定です。名前が似た設定でも、確認している段階は異なります。

現在公開されているrobots.txtを取得し、対象URLに適用されるルールを確かめます。その後で、HTMLのrobots meta要素とHTTPレスポンスのX-Robots-Tagを別々に見ます。意図しないnoindexがどちらかにあれば、サイトマップの再送信より先にその指定を直す必要があります。

robots.txtでクロールを止めても、noindexの代わりにはなりません。Googleがnoindexを認識するには、ページをクロールできる必要があります。そのため、クロールを止めたままnoindexを読ませる設定では意図どおりに除外できません。この違いは、robots.txtの概要とnoindexの実装方法で確認できます。

ページのcanonicalとGoogleの選択が一致するとは限らない

現在のページにあるrel="canonical"は、運営者が希望する正規URLを伝えるシグナルです。Googleの選択を確定する命令ではないため、別のURLが選ばれる場合があります。

現在のHTMLにある指定は、URL検査に表示された「ユーザーが指定した正規URL」とは別の時点の情報です。Googleが選択したcanonicalは、URL検査のGoogleインデックス側で確認します。公開URLテストでは、GoogleがどのURLを選ぶかは分かりません。

期待する最終URLを基準に、現在のページが指定するcanonicalとGoogleが選択したcanonicalを比べます。不一致があれば、類似ページやリダイレクトを含めて正規化の設計を確認します。Googleのcanonicalに関する説明でも、運営者の指定とは別にGoogleが代表URLを選ぶことが示されています。意図した別URLが正規ページとして登録されているなら、重複側のURLが未登録でも問題はありません。

技術設定に問題がなければ重複とページ固有の内容を確認する

HTTP応答や公開設定に明確な問題がなければ、類似URLとページ内容も確認対象になります。意図しないnoindexなどが見つかっている場合は、内容を変えてもその指定は解消されないため、設定の修正が先です。

説明用の例として、同じ製品仕様をURLだけ変えて掲載した二つのページを考えます。本文がほぼ同じなら、Googleが一方を正規ページにまとめる可能性があります。一方、同じ製品でも「対応する機器」と「導入後の保守費用」を具体的に説明するページは、読者の疑問が異なります。製品名が同じというだけで重複とは判断できません。

重複していなくても、BtoBの見込み顧客が読後に判断を進められないページには、固有の説明を補う余地があります。これは公開内容を人が読んで行う編集上の判断です。Search Consoleの状態名だけで、品質が原因だと決めることはできません。ユーザー第一のコンテンツに関するGoogleの質問も、原因を自動判定する基準ではなく、読者にとって十分な内容かを見直す観点として使います。

修正前の結果が残っているときは前回クロール日時を見る

たとえば、誤って付いていたnoindexを9月18日に外したとします。URL検査の前回クロールが9月17日なら、そこに残るnoindexの判定は修正前の状態を示している可能性があります。同じ18日の公開URLテストで取得とインデックス登録が許可されていれば、修正がGoogleの保持する情報へまだ反映されていないと考えられます。これは時点差を説明する仮定例であり、実際の診断結果ではありません。

反対に、前回クロールが修正公開後なのにnoindexが検出されているなら、別の指定が残っていないかを確認します。HTMLから外しても、HTTPヘッダーのX-Robots-Tagに残っている場合があるためです。公開URLテストの成功だけで、過去の判定を読み替えることはできません。

後日比較する場合は、対象URLと修正の公開日時に加えて、前回クロール日時と公開URLテストの実行日時・結果があると経過を追えます。記録はこの時点差を取り違えないための補助です。

明確な不具合がなければ登録を待つ判断もできる

現在も取得エラーや意図しないnoindexが残っているなら、その修正が先です。一方、修正済みのページをGoogleがまだ取得していない場合は、再クロールを待つ理由があります。サイトマップへの掲載は発見を助けますが、待つための必須条件ではありません。GoogleがすでにURLを認識していれば、掲載の有無だけで調査を最初からやり直す必要はありません。

まだ一度もクロールされていないURLと、取得後も未登録のURLでは、待っている処理が異なります。「検出 - インデックス未登録」は、GoogleがURLを把握したものの、まだクロールしていない状態です。「クロール済み - インデックス未登録」は取得済みですが、今後登録される場合も、そのまま登録されない場合もあります。Googleの状態別の説明では、後者についてクロールのリクエストを再送信する必要はないとしています。未登録という表示だけを理由に、修正箇所を無理に作る必要はありません。

新規公開や修正の反映には時間がかかり、登録までの日数は約束できません。必要に応じてURL検査からインデックス登録をリクエストできますが、即時の登録を保証するものではありません。同じURLへ繰り返してもクロールは早まりません。この制限は再クロールのリクエストに関するGoogleの説明でも案内されています。

修正後のページがクロールされたのに未登録が続く場合は、古い版を見ているという理由では説明できなくなります。その段階では、Googleが選んだ正規URLや、ページ固有の内容を見直す意味があります。取得前なのか取得後なのかが分かれば、再確認で見る場所も変わります。