Bing Webmaster UrlCount Stuck at 1: the sitemap-index Trap

Conclusion first

This blog (tech.rebounder.jp) publishes 3-4 posts a day. If it took search engines days to weeks to come crawl, anything written would just sit unread until they showed up. Two mechanisms close that gap: IndexNow, which tells Bing and Yandex “this changed” the instant it happens, and the Bing Webmaster API, which proactively registers the sitemap and individual URLs.

But “registered” and “verified” turned out not to mean “indexed.” Bing treated this site as a single-page site for three days. The cause: only sitemap-index.xml — the table of contents for the sitemaps — had ever been submitted.

IndexNow alone isn’t enough

IndexNow is a free protocol that only requires publishing one key file to instantly tell Bing, Yandex, and others “this URL changed.” No account, no cost. tech.rebounder.jp pulls its recent changes from git log (which files were committed) and notifies on exactly the URLs whose Markdown actually diffed.

The catch: Google doesn’t support it. IndexNow only speeds things up on the Bing/Yandex side; Google still has to discover pages the old way, through sitemaps and internal links. Since ChatGPT’s search runs on Bing’s index, IndexNow ends up mattering less for Google and more directly for LLM exposure.

Bing Webmaster counts UrlCount as 1 and stops

IndexNow is a notification, not a registration. For Bing to understand the site’s overall structure, the sitemap still has to be registered separately through Bing Webmaster.

tech.rebounder.jp registered with Bing Webmaster on 2026-09-01 and showed IsVerified: true. But GetCrawlStats and GetQueryStats stayed empty, and impressions sat at zero.

The cause was that only sitemap-index.xml — the index file that just links out to the child sitemaps — had been registered. When Bing fetches that index through the API, it records UrlCount: 1 and stops there. The index file is itself just one XML file, so from Bing’s side it looks like “a site with one URL registered.” IsVerified: true only meant “we confirmed you own this site” — it never meant “we know what’s on it.”

The fix was to submit the child sitemaps (the ones that actually list article URLs, like sitemap-0.xml) directly via SubmitFeed. The moment that happened, UrlCount jumped from 1 to 203, and the site was crawled that same day. For three days, Bing had effectively believed this was a one-page site.

Day-to-day operation: register the sitemap and submit URLs, both

There’s no need to redo everything from scratch each time. A script called push:bing automates two things:

1. Incremental sitemap registration — diffs the already-registered feed list (GetFeeds) against the child sitemap URLs listed in the post-build dist/sitemap-index.xml, and calls SubmitFeed only for the ones not yet registered.
2. Submitting recent URLs individually — builds URLs from Markdown files committed within git log --since=<N> days, and sends them with SubmitUrlbatch, checking Bing’s daily quota (GetUrlSubmissionQuota) first so submissions don’t exceed it.

The result gets checked against reality at the end. It re-fetches the feed list with GetFeeds and treats anything whose Status isn’t Success as a failure. It also treats the total number of URLs Bing knows about as a failure if it’s 1 or fewer — a guard against quietly treating 0 or 1 as a success, which is exactly the “only the index got through” state that caused the original problem. This is a mechanical check for the same failure mode that started it all.

A second trap: treating a rename as delete-plus-add

Both IndexNow and the Bing Webmaster API decide which URLs to submit by pulling “recently changed Markdown files” from git log --name-only. That command has a quirk: it reports a file rename as a delete-plus-add pair.

On the day an article slug actually got renamed, the old slug (which 404s in production) got swept into the submission batch right alongside the new one. One out of 15 URLs submitted that day pointed to something that didn’t exist. Sending 404s doesn’t just waste quota — it also erodes how much a search engine trusts the submission feed as a whole.

The fix was straightforward: keep only the paths from git log that actually exist in the working tree, checked with existsSync. “Was committed” and “currently exists” are different facts, and only the first one had been checked. The fix also logs how many files were dropped this way, so a silent reduction doesn’t go unnoticed.

Cost

Both IndexNow and the Bing Webmaster API are free — no account fee, no monthly charge. URL submissions stay well within the daily quota of 100 and the monthly quota of 2,700, so tech.rebounder.jp’s publishing pace (3-4 posts a day) runs with no billing risk at all. The only real cost is operational care: keeping the API key in .env.local and out of both build artifacts and the repository’s public surface.

Summary

“Registered the site” and “confirmed as owner” turned out not to be the same thing as “the search engine knows what’s on it.” Bing Webmaster treated a table-of-contents file (sitemap-index.xml) as UrlCount: 1 and stayed there until the child sitemaps were submitted directly. On top of that, deciding which URLs to submit mechanically is fragile against an everyday operation like a rename. Both problems were only visible by checking the actual resulting numbers against the assumption that registering something means the search engine understood it.