Bing WebmasterのUrlCountが1のまま止まっていたsitemap-indexの罠

結論から

このブログ（tech.rebounder.jp）は1日3〜4本のペースで記事を出している。検索エンジンがそれを見に来るまで数日〜数週間かかると、書いたものが読まれる場所に載るまでただ待たされることになる。そこで2つの手を使っている。IndexNowでBing・Yandexに「更新した」と即時通知し、Bing Webmaster APIでサイトマップとURLを能動的に登録する。

だが「登録した」「Verified になった」で終わりだと思っていたら、Bingは3日間このサイトを1ページのサイトとしてしか扱っていなかった。原因は、渡していたのが sitemap-index.xml（サイトマップの目次）だけだったことだ。

IndexNowだけでは足りない

IndexNowは鍵ファイルを1つ公開するだけで使える無料のプロトコルで、Bing・Yandexなどに「このURLが変わった」と即座に知らせられる。アカウント登録も費用も要らない。tech.rebounder.jpでは直近の変更を git log の実績（コミットされたファイル）から拾い、Markdownの差分が出た記事だけをURLに変換して通知している。

ただしGoogleは対応していない。IndexNowで速く届くのはBing・Yandex側だけで、Googleへはこれまで通りsitemapと内部リンクで拾われるのを待つしかない。ChatGPTの検索はBingの索引を使うため、IndexNowはGoogle向けというよりLLM露出に直結する施策になる。

Bing WebmasterはUrlCountを1と数えて止まる

IndexNowは「通知」であって「登録」ではない。サイト全体の構造をBingに把握させるには、別途Bing Webmasterでサイトマップを登録する必要がある。

tech.rebounder.jpは2026-09-01にBing Webmasterへサイトを登録し、IsVerified: true になった。ところがその後、GetCrawlStats も GetQueryStats も空のままで、表示回数は0が続いた。

原因は、登録したのが sitemap-index.xml（子サイトマップへのリンクが並ぶ目次ファイル）だけだったことだ。BingはこのindexをAPI経由で取得すると UrlCount: 1 と記録し、そこで止まる。indexファイル自体は1個のXMLファイルでしかないため、Bing側からは「1件のURLが登録されたサイト」にしか見えない。つまりIsVerified: trueは「サイトの所有者だと確認できた」ことを意味するだけで、「サイトの中身を知らせた」ことにはならなかった。

対策は、子サイトマップ（実際の記事URLが並ぶ sitemap-0.xml など）をSubmitFeedで直接登録することだった。これを行った瞬間、UrlCount が 1 → 203 に変わり、同日中にクロールされた。Bingは3日間、このサイトを事実上1ページのサイトだと思っていたことになる。

日々の運用: サイトマップの登録とURL送信を両方やる

毎回ゼロから全部をやり直す必要はない。push:bing というスクリプトを作り、次の2つを自動化している。

1. サイトマップの差分登録 — すでに登録済みのフィード一覧(GetFeeds)と、ビルド後の dist/sitemap-index.xml に載っている子サイトマップURLを突き合わせ、未登録のものだけSubmitFeedする
2. 直近URLの個別送信 — git log --since=<N>日前 でコミットされたMarkdownファイルからURLを組み立て、SubmitUrlbatchで送る。送信件数はBing側の日次クォータ（GetUrlSubmissionQuota）を超えないよう事前に確認する

最後に結果を実測で確かめている。送信後のフィード一覧をGetFeedsで取り直し、StatusがSuccessでないサイトマップがあれば失敗として扱う。さらにBingが知っているURLの合計が1件以下なら「子サイトマップが渡っていない」と判定して失敗にする。0件や1件を成功扱いにしないための歯止めで、まさに最初にハマった「index しか渡っていない」状態を機械的に検知するためのものだ。

もう一つの罠: リネームを削除+追加と誤認する

IndexNowとBing Webmaster APIの両方で、送信対象のURLは「直近で変更されたMarkdownファイル」をgit log --name-onlyで拾って決めている。ところがこのコマンドは、ファイルのリネームを「削除＋追加」のペアとして出力する。

実際に記事スラッグを改名した日、旧スラッグ（本番では404を返す）が新スラッグと一緒に送信対象へ入り込んだ。その日の送信15件のうち1件が、実在しないURLだった。404を送るのはクォータの無駄であるだけでなく、検索エンジン側から見た送信フィードの信頼性を落とす。

対策は単純で、git logが返したパスのうち、作業ツリーに実際に存在する（existsSyncで確認できる）ものだけを送信対象として残すようにした。「コミットされた」ことと「いま存在する」ことは別物であり、前者だけを見ていたのが原因だった。対策後は、消えたファイルがあった場合に件数をログへ出すようにして、黙って減らさないようにしている。

費用

IndexNow・Bing Webmaster APIともに無料で、アカウント開設料や月額費用は発生しない。URL送信は日次100件・月次2700件のクォータ内に収まっており、tech.rebounder.jpの更新頻度（1日3〜4本）であれば課金の心配なく運用できる。唯一のコストは、APIキーを.env.localに保管し、ビルド成果物やリポジトリの公開範囲に含めないという運用上の注意だけだ。

まとめ

「サイトを登録した」「所有者として確認された」は、検索エンジンにとって「中身を知っている」こととイコールではなかった。Bing Webmasterは sitemap-index.xml という目次だけを渡された状態をUrlCount: 1としか認識せず、子サイトマップを直接渡すまでそこから動かない。加えて、URLの送信対象を機械的に決める処理は、リネームのような普段意識しない操作で簡単に壊れる。どちらも「登録した」という事実と「検索エンジンが実際に何を知っているか」を結果の数値で突き合わせることでしか気づけなかった。