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

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

確認はサイトマップ全体から始め、最後に一つのURLへ絞ります。その過程では、Googleがすでに保持している情報と現在公開されているページを分けて読みます。この順序で証拠を残すと、最初に直す場所を一つ選べます。問題が見つからない場合も、何を根拠に待つのかを決められます。

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

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

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

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

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

サイトマップレポートの最終読み込み日時が古い場合は、Search Consoleが保持する結果と現在のXMLにも時点差があります。現在のXMLに対象URLがなければ、先にサイトマップの生成処理を直します。XMLには載っているものの取得時にエラーが出ていれば、ファイルの配信や送信先を確認するのが先です。

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

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

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

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

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

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

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

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

URL検査を開いたときに表示されるのは、Googleインデックスが保持している直近の情報です。現在公開されているページを、その場で取得した結果ではありません。判定だけを見るのではなく、前回クロール日時やページ取得の結果も一緒に記録します。

ページを修正した日時が前回クロールより新しければ、Googleがまだ古い版を見ている可能性があります。反対に、修正後の日時でクロールされているなら、単なる時点差だけでは説明できません。この違いが、次に現在のページを調べる理由になります。

URL検査では、ユーザーが指定した正規URL（canonical）と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テストの結果を使って、この欄を埋めてはいけません。

期待する最終URLを基準に、現在のページが指定するcanonicalとGoogleが選択したcanonicalを比べます。不一致があれば、類似ページやリダイレクトを含めて正規化の設計を確認します。Googleのcanonicalに関する説明でも、運営者の指定とは別にGoogleが代表URLを選ぶことが示されています。この記事では不一致を見つけるところまでとし、実装の変更は正規化を担当する作業へ分けた方が安全です。

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

HTTP応答や公開設定に明確な問題がないときに、初めて類似URLとページ内容を比べます。クロールや登録を妨げる設定が残ったまま内容を直すと、何が未登録の原因だったのか分からなくなるためです。

候補となる類似URLを並べたら、それぞれがどの問いへ答えるページなのかを一文で書きます。対象ページだけが担う内容も説明できるか確かめてください。同じ問いに同じ答えを返すページが複数あるなら、どのURLを残すかという正規化の判断が必要です。

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

確認結果には情報を得た時刻も一緒に残す

確認結果は、対象URLごとに一つの記録へまとめます。未確認の欄を埋めることよりも、どの時点の情報を見たのかを残す方が大切です。Search Consoleの実データや対象URLがない状態で、架空の結果を記入する必要はありません。

次の記録は、サイトマップ全体から一つのURLへ絞り、最初の修正または待つ判断までつなげるためのものです。確認していない欄は空欄のままにし、推測で補わないでください。

対象URL:
期待する最終URL:
Search Consoleプロパティ:
確認開始日時:
最新修正の公開日時:

[サイトマップ全体]
サイトマップURL:
送信日:
最終読み込み日時:
サイトマップの状態:
検出ページ数:

[現在のXML]
公開XMLの取得日時:
対象URLの掲載有無:

[ページのインデックス登録レポート]
レポートの状態:
レポート確認日時:
同じ状態の影響URL数:

[URL検査で確認したGoogleインデックス上の情報]
URL検査の確認日時:
URL検査の判定:
前回クロール日時:
クロールしたユーザーエージェント:
ページ取得:
クロール許可:
インデックス登録許可:
ユーザーが指定した正規URL（canonical）:
Googleが選択した正規URL（canonical）:

[公開URLテスト]
実行日時:
ユーザーエージェント:
クロール許可:
ページ取得:
インデックス登録許可:

[現在のHTTP応答と公開設定]
HTTP応答の確認日時:
リダイレクト履歴:
最終到達URL:
最終ステータス:
公開robots.txtの取得日時:
対象URLに適用されるrobots.txtルール:
robots meta要素:
X-Robots-Tag:
現在のページが指定する正規URL（canonical）:

[重複とページ固有の内容]
類似URL:
各ページが答える問い:
対象ページだけが担う内容:

[次の対応]
インデックス登録リクエスト日時:
最初に修正する箇所:
判断根拠:
修正担当:
修正の公開予定日時:
待つ理由:
再確認条件:
再確認予定日:

登録済み情報と公開URLテストの結果が違っても、どちらかを誤りとして上書きしないでください。確認日時を残せば、Googleが保持する過去の状態と現在の公開状態を比較できます。最初に修正する箇所は一つに絞ると、次回の確認で何が変わったかを追いやすくなります。

明確な問題がなくGoogleが修正後のページをまだ見ていなければ待てる

待つ前に、現在のXMLに対象URLがあることを確かめます。意図した最終URLが2xxを返し、クロールやインデックス登録を妨げる指定がないことも必要です。ページのcanonicalが設計と一致しているかも確認します。公開URLテストで取得上の問題が見つからず、類似ページとは異なる役割を説明できれば、待つための前提がそろいます。

そのうえで、最新修正の公開日時がURL検査の前回クロールより後なら、Googleがまだ修正後の版を取得していないという時点差を待つ理由にできます。再確認のきっかけは、前回クロールが修正公開後の日時へ更新されたときです。Googleが選択したcanonicalやインデックス登録状態が先に変わった場合は、その時点で見直します。変化がなくても、記録した再確認予定日が来たら同じ項目を確認します。

登録までの日数は、対象URLを確認せずに約束できません。インデックス登録リクエストも即時の登録を保証せず、同じURLへ繰り返してもクロールが早まるわけではありません。意味のある修正を公開した後に一度リクエストするか、通常のクロールを待ちます。この制限は再クロールのリクエストに関するGoogleの説明でも案内されています。

待つための条件を一つでも確認できていないなら、まだ待つ段階ではありません。結論を左右する未確認項目を一つ選び、確認または修正へ戻ります。最後に「どこを直すか」か「何を待つか」のどちらかが具体的に残れば、サイトマップを送信したという事実だけで立ち止まらず、次の作業へ進めます。