サイトマップを送信したのにページがインデックスされないと、送信方法が間違っていたのではないかと考えたくなります。まず切り分けるのは、GoogleがURLを見つけられているか、取得できているか、登録を妨げる指定がないかです。
送信済みという事実だけで判断を止めず、サイトマップの取得、対象URLの取得、登録指定、ページの独立した価値へ順番に進みます。この順番で見ると、待つページと直すページを分けやすくなります。
サイトマップ送信はURLを見つけてもらうための入口です
Googleのサイトマップに関する説明では、サイトマップは検索エンジンにサイト内のURLを知らせるファイルとして扱われています。特に新しいページ、内部リンクから見つけにくいページ、更新されたページを伝える入口になります。
ただし、サイトマップに載せたURLがすべてクロールされるわけではありません。クロールされたとしても、必ずインデックス登録されるわけでもありません。登録されない理由は、サイトマップの失敗だけではありません。URLを取得できない、noindexやcanonicalが意図と違う、内容の重複や不足がある、内部リンクが弱いといった原因もあります。
最初に分けたい状態は三つあります。サイトマップが読まれていないなら、URL一覧をGoogleへ渡せていない可能性があるため、Search Consoleのサイトマップ レポートを見ます。
サイトマップは読まれているのに対象URLが登録されない場合は、ページ取得や登録指定で止まっている可能性があります。この段階ではURL検査ツールで個別URLを確認します。技術的には見えるのに登録されない場合は、ページの独立性、価値、重複の問題が残っているかもしれません。本文、内部リンク、類似URLを見直します。
この順番で見ると、「待つべき状態」と「直すべき状態」を混同しにくくなります。
先にサイトマップがGoogleに読まれているかを確認する
Search Consoleのサイトマップ レポートでは、送信したサイトマップの取得状況や解析エラーを確認できます。ここで成功していない場合は、個別URLの品質を見る前に、サイトマップ自体を直す必要があります。
よくある確認点は、サイトマップURLの間違い、サーバーエラー、robots.txtによるブロック、XMLの構文エラーです。ブラウザでサイトマップが開ける場合でも、Search Consoleでエラーが出ているなら、その内容を優先して確認します。
サイトマップが成功している場合でも、そこで安心しきらないことが大切です。成功は、Googleがサイトマップを取得できたという意味です。サイトマップ内のすべてのURLが登録されたという意味ではありません。
確認結果ごとに動き方を変えます。取得できない場合は、Googleがサイトマップへ到達できていない状態です。サイトマップURL、サーバー応答、robots.txtを確認します。
解析エラーがある場合は、XMLとして正しく読めていません。構文、URL形式、不要な文字を確認します。成功している場合は、サイトマップ自体は読まれている状態です。そこで止まらず、個別URLをURL検査ツールで見ます。
ここまでで見るのは、あくまでURL一覧を渡せているかです。個別ページの登録可否は、次の段階で切り分けます。
URL検査ツールで取得と登録阻害要因を切り分ける
対象URLがサイトマップに含まれているのに登録されない場合は、Search ConsoleのURL検査ツールで個別に確認します。URL検査ツールでは、インデックス登録状況やライブURLの取得可否を確認できます。
公開ページがブラウザで見えていても、検索エンジンにとって登録しにくい状態になっていることがあります。たとえば、noindexやX-Robots-Tagが付いている、canonicalが別URLを指している、認証やリダイレクトで実質的に別ページになっている、robots.txtで取得を妨げている、といったケースです。
個別URLでは、次の順番で見ます。
- ライブURLを取得できるか。
- robots.txtやサーバー応答でクロールを妨げていないか。
noindexまたはX-Robots-Tagで登録を拒否していないか。- canonicalが意図したURLを指しているか。
- サイト内からそのURLへ自然にリンクされているか。
この段階で問題が見つかれば、待つより先に修正します。取得できないURLやnoindexが残っているURLは、サイトマップを再送信しても根本的には解決しません。
技術的に見えるページでも登録されないことがある
サイトマップも成功し、URL検査でも大きな技術問題が見つからない。それでも登録されない場合は、ページ自体の役割を見ます。
Googleはインデックス登録を保証していません。似たページが多い、本文が薄い、サイト内から見つけにくい、読者の問いに固有の答えがないページは、サイトマップに載っていても登録されにくい場合があります。
この確認は、検索エンジン向けに文章を増やすためではありません。そのURLを検索結果に出す意味があるかを見直すためです。内容が既存ページと重なっているなら統合が向いていることがあります。サービスページの一部で足りる内容なら、独立記事にしないほうが読みやすい場合もあります。
ページの役割を見るときは、登録されない理由を文章の量だけに求めないことが大切です。同じ問いへ答えるページが他にあるなら、統合またはcanonicalの整理を検討します。本文が一般論だけで固有の答えが少ないなら、読者の状況、判断基準、具体例を補います。
サイト内からリンクされていない場合は、関連ページから自然な導線を作ります。検索結果に出すほど独立した役割がない場合は、FAQ、用語集、サービスページ内の補足へ移すほうが読者にとって分かりやすいことがあります。
技術的に問題がないことと、登録される価値が十分にあることは別です。ここを分けて考えると、サイトマップの再送信を繰り返すだけの状態から抜けやすくなります。
待つURLと直すURLを同じ扱いにしない
公開直後のURLは、すべてをすぐに直す必要はありません。サイトマップが読まれていて、URLも取得でき、noindexやcanonicalの問題もないなら、クロールと処理を待つ判断になります。
一方で、取得エラー、noindex、canonical不整合があるなら、待つ前に直すべきです。内部リンク不足や内容の重複がある場合も同じです。問題が残ったまま時間を置いても、登録されない理由が解消されるとは限りません。
最後は、対象URLを次の三つに分けます。サイトマップ、取得、登録指定、内容の独立性を見た後で同じ軸にそろえると、待つべきURLと直すべきURLを混同しにくくなります。
| 処遇 | 条件 | 次の行動 |
|---|---|---|
| 待つ | サイトマップ、取得、登録指定に問題が見当たらない | 次回の月次確認で状態を見る |
| 直す | 技術指定や内部リンクに明確な問題がある | 修正後にURL検査で再確認する |
| 統合する | 内容が既存ページと重なり、独立した役割が弱い | 代表URLを決め、内部リンクやcanonicalを整理する |
サイトマップ送信後は、URLが見つかり、取得され、登録候補として扱える状態になっているかを見ます。そこまで分けて確認すると、待つべきページと手を入れるべきページを落ち着いて判断できます。