サイトマップの検出されたURLが0のときに見る5つの実測

送信は通っている。ステータスも緑のまま。なのに「検出されたURL」は0から動かない。

このとき最初に手を動かす先は、レポートの画面ではありません。送信したサイトマップのURLそのものと、URL検査ツール（特定のURLをGoogleがどう認識しているかを個別に調べる機能）です。数字が増えるのを待つより、対象のURLがいまどう扱われているかを1本ずつ確かめたほうが、原因まで速く着きます。

送信したURLは、指定した文字列のまま扱われる

Search Console のサイトマップ レポートについて、Google のヘルプにはこう書かれています。

Sitemap URL The exact URL specified when the sitemap was submitted. Redirects are not followed. （サイトマップのURL: サイトマップの送信時に指定されたとおりのURL。リダイレクトは追跡されません。）

追跡されない。ここが最初の落とし穴です。

https://example.com/sitemap.xml を送ったつもりでも、サーバー側が https://www.example.com/sitemap.xml へ転送している構成は珍しくありません。httpからhttpsへの転送、末尾スラッシュの正規化、CDNのルール。転送は運用のどこにでも潜んでいます。公式が「リダイレクトは追跡されません」と書いている以上、転送のかかるURLを送信欄に入れておくのは避けたほうが安全です。

確認はコマンド1本で済みます。

curl -sSI https://example.com/sitemap.xml | head -n 5

HTTP/2 200 と content-type: application/xml（または text/xml）がそのまま返れば、送信したURLがファイルに直結しています。301 や 302 が返ってきたら、location ヘッダーに出ている転送先のURLを、送信欄に入れ直します。

同じことをサイトマップの中身にもやります。<loc> に書いたURLが転送される状態だと、Googleに渡している住所と、実際にページが置いてある住所がずれたままになります。数十本あるなら、まとめて叩いてしまうのが速い方法です。

grep -o '<loc>[^<]*</loc>' sitemap.xml | sed 's/<[^>]*>//g' \
  | while read -r u; do printf '%s\t' "$u"; curl -o /dev/null -sS -w '%{http_code}\n' "$u"; done

200以外が並んだら、そこが先に直す場所です。

Googlebotはリンクをたどって来る

サイトマップは入口のひとつであって、唯一の入口ではありません。Googleはこう説明しています。

Googlebot and other web crawlers crawl the web by accessing URLs found in previously crawled pages. （Googlebotなどのクローラーは、すでにクロールしたページで見つけたURLにアクセスすることでウェブを巡回します。）

同じページには、サイトマップが役立つ状況として次の条件も挙がっています。

Your site is new and has few external links to it. （サイトが新しく、外部からのリンクがほとんどない。）

つまり、外部リンクがまだ育っていない新しいサイトほど、リンク経由の発見に頼れません。逆に言えば、内部リンクが行き渡っていて既存ページからたどれる構造なら、サイトマップの数字が伸びなくてもページ自体は見つかっている、という状況があり得ます。レポートの数字とインデックスの状況は、別々に確かめたほうが判断を誤りません。

そもそもサイトマップが要らない規模かもしれない

同じ公式ドキュメントには、要らない場合の目安も書かれています。

You might not need a sitemap if: Your site is "small". By small, we mean about 500 pages or fewer on your site. （次の場合はサイトマップが必要ないこともあります: サイトが「小規模」である。ここでの小規模とは、サイト内のページがおよそ500ページ以下であることを指します。）

500ページ以下で、トップから数クリックで全ページにたどり着ける。その条件なら、検出されたURLの数字を追いかけること自体の優先度は下がります。時間の使い先を、リンク構造とページの中身に移す判断ができます。

別ホストに置いたサイトマップは、権限で詰まる

サイトマップを本体と別のホストに置いている構成では、送信のしかたが変わります。公式の手順には、robots.txt に書く形式がそのまま載っています。

# robots.txt file of https://example.com/
sitemap: https://sitemaps.example.com/sitemap-example-com.xml

Search Console から送る場合には、関係するすべてのサイトについて所有権を確認しておく必要がある、と同じページに書かれています。だから、所有権の確認が済んでいないホストのURLが混ざっていないかを先に見ます。ステージング用のドメインや、旧ドメインのURLが1本だけ残っている。よくある混入です。

URL検査を1本通す。ただし「はい」を鵜呑みにしない

ここからが切り分けの本体です。インデックスさせたいURLを1本選び、URL検査に入れます。見るのは3か所。

1つめは「ユーザー宣言の正規URL」です。ページが明示的に正規URL（canonical）を宣言していれば、URL検査に表示されます。サイトマップに載せたURLと、そのページ自身が宣言している正規URLが食い違っていないか。ずれているなら、どちらを正とするのかを決めて片方に寄せます。

2つめは、クロールがブロックされていないかです。ここに、知らないと引っかかる仕様があります。

then Indexing allowed? will always be "Yes" because Google can't see and respect any noindex directives. （その場合、「インデックス登録は許可されていますか?」は常に「はい」になります。Googleがnoindexディレクティブを認識して従うことができないためです。）

robots.txt でブロックされているとき、「インデックス登録は許可されていますか?」の欄は常に「はい」になる。ブロックされているのに、許可の表示だけを見ると問題なしに読めてしまいます。ここで安心すると、原因を素通りします。

ブロックしているルールの特定と直し方も、公式に書かれているとおりです。

To avoid being indexed, remove the robots.txt block and use 'noindex'. If you do not want to block this page, update your robots.txt file to unblock your page. You can use the robots.txt tester to determine which rule is blocking （インデックス登録を回避するには、robots.txt のブロックを解除して「noindex」を使用します。このページをブロックしたくない場合は、robots.txt ファイルを更新してページのブロックを解除してください。どのルールがブロックしているかは、robots.txt テスターで確認できます。）

3つめは、そのURLがすでにインデックスされているかどうかです。

if Search Console says a URL is indexed, but it doesn't turn up in your search results, you can assume that it is indexed and eligible to appear in search results. （Search Console でURLがインデックスに登録されていると表示されているのに検索結果に出てこない場合は、そのURLはインデックスに登録されていて検索結果に表示される資格があると考えて差し支えありません。）

検索してもヒットしないから未登録だ、とは限りません。検索結果は検索履歴や地域などの条件で変わります。判定に使うのは、自分で検索した結果ではなくURL検査の表示です。

5ステップにまとめる

1. 送信したサイトマップURLに curl -sSI を打ち、200が直接返るか確認する。301/302 なら転送先のURLで送信し直す。
2. サイトマップ内の <loc> のURLをまとめて叩き、200以外が混ざっていないか確認する。混ざっていたら、そのURLを直すか一覧から外す。
3. <loc> のホストが、送信先のプロパティと一致しているか確認する。別ホストが混ざるなら robots.txt の sitemap: 行を使うか、そのホストの所有権を確認しておく。
4. インデックスさせたい代表URLを1本、URL検査に入れる。ユーザー宣言の正規URL・クロールのブロック・インデックス済みかどうかの3点を読む。
5. 代表URLが「インデックスに登録されています」なら、検出されたURLの数字は保留にして、リンク構造とページの中身に時間を移す。未登録なら、4で見えたブロックや正規URLのずれを直す。

順番に意味があります。1と2で「Googleに渡している住所が実在するか」を潰し、3で「そもそも受け取ってもらえる立場か」を潰す。ここを飛ばして4のURL検査から入ると、表示の解釈だけで悩む時間が長くなります。

自分のケースを当てはめる判定表

表の1行目は、さきほどの curl -sSI がそのまま答えになります。4行目は、URL検査の「はい」を根拠にしないという話。5行目は、Search Console の表示を信じてよいという公式の記述に対応します。6行目だけは性質が違って、直す作業ではなく「追うのをやめる」判断です。

ワークスルー: wwwなしを送っていたケース

具体的に1本通してみます。https://example.com/sitemap.xml を送信済み、検出されたURLは0のまま2週間。

まず1本目のコマンドを打ちます。返ってきたのが HTTP/2 301 と location: https://www.example.com/sitemap.xml。サイト本体はwwwありに統一されていて、サイトマップも例外ではなかった、という構成です。送信欄に入っていたのはwwwなしのURLでした。公式が「リダイレクトは追跡されません」と書いている条件に、そのまま当てはまります。

対処は単純です。wwwありのURLで送信し直す。ついでに <loc> の中身も確認したところ、こちらもwwwなしで出力されていました。サイトマップの生成側でホスト名を直します。

ここで数字が増えるのを待たずに、代表URLを1本URL検査に入れます。「インデックスに登録されています」と表示されました。リンクからは見つかっていた、ということです。つまり急ぐ話ではなくなります。この時点で、優先度は「サイトマップの数字」から「生成側のホスト名を直して再発を止める」に移ります。

もし逆に「インデックスに登録されていません」だったら、同じ画面でクロールのブロックと正規URLの宣言を読みます。読む場所は決まっているので、迷う余地はありません。

つまずきやすいところ

数字が0でも、失敗とは限らない。 URL検査で「インデックスに登録されています」と出ているなら、Googleは表示される資格があるものとして扱っています。レポートの数字とインデックスの状況は、それぞれ別に確かめるほうが安全です。

noindexを外す前にrobots.txtを見る。 ブロックされたままでは、noindexの指定が読み取られない状態が続くことがあります。公式が書いているのは「ブロックを解除して noindex を使う」という順番です。この順で入れ替えます。

サイトマップを何度も送り直しても、そこは動かせない。 送信の操作で変えられるのは、渡す住所の正しさまでです。リンクがたどれない構造や、外部からのリンクが少ない状態は、送信の回数では変わりません。手動リクエストの限界についてはインデックス登録をリクエストしても早くならない理由に整理しています。

載せるURLの選び方は別問題。 そもそもどのURLをサイトマップに載せるべきかで迷っているなら、「サイトマップに送信されていません」と出たときの判断が先です。更新日時の扱いはlastmodはいつ更新するかにまとめてあります。

最後にもう一度だけ。検出されたURLの数字は、原因を教えてくれません。教えてくれるのは、curl が返すステータスコードと、URL検査の3行です。