Submit your site to Bing, measured: five ways in, and what reached the Bing index

Most guides to submitting a site to Bing stop where the interesting part begins. You click Submit, Bing says Success, and the guide congratulates you. What happens after that is what you actually care about, and it is also what those guides cannot show, because it only exists in two places: the access log of the server that hosts the site, and Bing’s own reports about it.

This site has both. It went live on this server on August 28, 2026, was added to Bing Webmaster Tools on September 15, and has since been announced to Bing in every way Bing documents for a site like this one: a sitemap, IndexNow, two batches through the URL Submission API and a manual request for indexing. Below is what each of them did, measured two ways: from the server log, counting every request from an address that Bing’s own verification method confirms, between August 28 and October 22, 2026; and from the Bing Webmaster API, read on October 22 with the site’s own account. Where the two disagree, and they do, both answers are shown.

How to submit your site to Bing: five ways in

Bing documents several ways to tell it about a site or a page, and these are the five I used. They are less alternatives than layers. The first is required. The second and third are the ones Bing recommends for everyday use. The last two are meant for single pages. The table puts what Bing says each one does next to what it did here, and the sections after it go through them one by one.

1. Add and verify the site in Bing Webmaster Tools

Everything else depends on this step, because Bing’s reports, its URL Submission tool and its quota all belong to a verified site. Bing offers two ways to add one. The first is an import from Google Search Console: if a site is already verified there, Bing reads it along with its sitemaps, and “the selected sites will be added and get automatically verified in Bing Webmaster Tools.” Bing then keeps checking that connection; its help page says it will “periodically validate the site ownership status by accessing your Search Console account,” importing any new sitemap it finds there.

The second way is to add the site by hand and prove ownership with one of what Bing calls “four methods of ownership verification”: a DNS record that Domain Connect adds for you, a file named BingSiteAuth.xml at the root of the site, a meta tag on the home page, or a CNAME record you add yourself. The file and the tag are the ones that break quietly. A theme change or a cleanup of the web root can remove them without anyone noticing. Nothing on this site carries either of them today. On October 22, /BingSiteAuth.xml returned a 404 through the CDN, the home page had no msvalidate.01 tag, the SEO plugin’s field for Bing’s code was empty, and no request from Bing for that file appears anywhere in the server’s log. The proof of ownership lives outside the pages, where an edit to the site cannot delete it.

Once a site is added, Bing says “it usually takes 48 hours for our system to generate analytics and data.” That sentence is about reports, not indexing, and it is easy to read as a promise it is not. It also helps to know that Bing may have met your domain before you did. According to its API, Bing discovered this home page on July 26, 2019, and last crawled it on August 15, 2026, about two weeks before this site’s server log begins. The domain had a previous life, and in September Bingbot still asked for two paths that never existed here: /password and the address of an online store’s admin settings. If your domain was used before, Bing’s records may start with someone else’s site.

2. Submit a sitemap

A sitemap is the list of URLs you want crawled. Bing accepts an XML sitemap, an RSS 2.0 or Atom feed, or a plain text file with one URL per line, and there are two ways to tell it where yours lives: submit it in Webmaster Tools, or add a Sitemap: line to robots.txt. This site does both. Its sitemap is an index generated by the SEO plugin that points to one sitemap for posts, one for pages and one for categories.

The submission is acknowledged at once. On the evening of September 15 (UTC), Bingbot read the index and the two sitemaps it listed at the time within two minutes of each other, and Bing has shown the sitemap as processed successfully since that day. From then on, Bing’s help says, sitemaps “are typically read once per day.” My log shows 56 reads of a sitemap file by Bingbot in the 38 days from September 15 to October 22, spread over 22 of those days, with a longest gap of five days. Those numbers are a floor, not a count. The CDN in front of this site keeps a copy of the sitemap for half an hour, and a request it answers from that copy never reaches the server. I measured that blind spot in 60 requests to my own site, of which the access log recorded 6.

Bing’s report about the sitemap trails its crawler, too. On October 17 the Webmaster API listed the sitemap as last read on October 14, while my log had Bingbot reading the same sitemap index on October 15, 16 and 17. A sitemap tells Bing what exists. It does not tell Bing to fetch any of it, and as the rest of this note shows, most of what this one listed waited weeks.

3. Turn on IndexNow

IndexNow is a protocol for telling search engines, in one request, that a URL was added, changed or deleted, and Bing now ranks it above every other method. Its URL submission page opens with “Bing recommends using IndexNow for faster, automated URL submission across participating search engines,” and its IndexNow page says the protocol leads “to much faster crawling and indexing times.” One notice reaches every participating engine, because those engines “agree that submitted URLs will be automatically shared with all other participating search engines.” Google is not one of them, which is the subject of my note on turning on IndexNow to fix a Google problem.

On this site the SEO plugin, Rank Math, sends a notice whenever a post or page is published or updated. The protocol is precise about what a successful answer means: “The HTTP 200 response code only indicates that the search engine has received your set of URLs.” The first notice, sent on September 13, brought Bingbot to the key file 13 seconds later. That visit is the engine checking that the sender controls the site, and the documentation explains why it happens once: engines “crawl the key file to verify ownership and use the key until you change the key.” In the 39 days since, Bingbot has asked for a key file exactly twice: for the real one that first time, and on October 20 for a made-up one, when I sent notices with an invented key on purpose to see which errors come back. What those errors mean is in the reasons behind “Error submitting page to IndexNow”, along with the afternoon my own site sent the same page four times.

The key check tells you nothing about when the pages will be fetched. That first notice listed 20 URLs. Bingbot fetched the home page within two minutes; the next page on the list waited 16 days. Since then the plugin has announced each of the 22 notes published here at the moment it went live. None of the 22 was fetched within a day of its notice. Eight were fetched in normal crawling between 21 and 34 days after publication, one only by a test I ran from Webmaster Tools, and 13 had not been fetched by October 22, some of them only days old. My log cannot see a fetch the CDN answered from its copy, so a visit in the first half hour after publication could be missing from it; Bing’s API, which dates when it first recorded each page, puts those first records weeks after publication as well.

The plugin’s own history, which keeps the last 100 notices, shows the same pattern over a shorter stretch. From October 20 to 22 it logged notices for 39 different URLs, plus one batch of 45, and every one was answered with a 200. Bingbot fetched none of them within an hour of the first notice, and two within a day. IndexNow’s FAQ describes this honestly once you read past the headline: after a notice, “the search engine evaluates whether it should crawl the URL based on its crawl quota, scheduling logic, and quality signals,” and “Submitting a URL does not guarantee immediate indexing.” It also says that “Every URL submitted through IndexNow counts toward your site’s crawl quota,” which makes repeated notices for an unchanged page a cost rather than a nudge. And a notice cannot be taken back. When two scheduled posts of mine went live by mistake, both had been announced before I could pull them, as I described in the scheduled post that published itself.

4. Send URLs through URL Submission

URL Submission is Bing’s older way to push individual URLs: a box in Webmaster Tools, or an API that takes up to 500 URLs per request. Unlike IndexNow, it “only submits URLs to Bing (does not notify other search engines),” and Bing now says URL Submission and its Content Submission API “may be deprecated in the future as IndexNow adoption expands.” The help page states the allowance plainly: “Submit up to 10,000 URLs per domain per day.” Further down, the same page explains why yours may be lower: “The Submit URL quota is set based on multiple parameters and may be revised over time.”

For this site, the quota the API reports is 100 URLs a day, not 10,000. I used it twice. On October 15, 38 URLs went in, and between that batch and the next my log shows Bingbot fetching at most two pages, which is what it had been doing for weeks. On October 17, at about 11:35 UTC, I resubmitted the sitemap and sent 25 URLs, followed by 12 more submissions over the next 80 minutes, two of them for pages published that day. The first page fetch came eight hours later, and by the same time the next day Bingbot had fetched ten pages. Of the 25 URLs, Bingbot fetched 6 within 24 hours, 9 within two days and 11 by October 22. The other 14 had not been fetched at all.

That second batch is the only event in this whole record that was followed by a lasting change in how much Bing crawled, and it would be convenient to call it the cause. I can’t. The same day I also added internal links from pages Bing had already crawled to pages it had not, published two new pages, and the site picked up its first inbound links. Any of those, or Bing’s own schedule, could explain the change, and the first batch of 38, which came with none of them, changed nothing visible. Bing’s guidelines, in their section on notifying Bing of changes, say “Avoid batch submissions when possible,” which is the opposite of what I did with URL Submission on two days in October, and with IndexNow on September 13 and October 21. The URL submission page adds one more line worth reading before you send the same URLs again: “Repeated manual submissions do not accelerate indexing.”

5. Inspect a URL and request indexing

The last door is in the URL Inspection tool, which shows for one URL “when and where the URL was discovered, crawled, and indexed.” If a page is not indexed, you can request indexing “based on the availability of URL submission quota, and action will be taken up on priority by our systems.” The same tool has a Live URL test, which “sends requests to Bingbot” and shows what it receives.

On October 20 I inspected a guide published three days earlier, which the tool reported as discovered but not crawled, ran the live test and requested indexing. The live test is easy to find in the log. At 18:03 UTC a verified Bing address fetched the page as a desktop browser and as a phone, then made ten more requests for its images, fonts and style sheet over the next two minutes, all answered with a 200. Bing describes the test as a way to see whether a page “is crawled without request for indexing,” and that is what it was. The request for indexing left no trace: in the two days that followed, Bingbot did not come back for the page, and on October 22 the API still had no record of it.

What Bingbot did after each submission

Every number in this section comes from the server’s access log, and the first job was deciding which lines were Bing. A user agent proves nothing, because anyone can send one; Bing’s own crawler page warns that “user agent strings are easy to spoof.” Bing documents two checks that do prove it. One is DNS: the address must resolve to a name ending in search.msn.com, and that name must resolve back to the same address. The other is a list of address ranges that Bing publishes as a JSON file, with the instruction to “Refresh this list daily as we can change this list any time.” I used both, the same way I checked AI crawlers in 346 requests that said they were AI crawlers, against their owners’ IP ranges.

Between August 28 and October 22, 2026, the log has 175 requests from 106 addresses inside Bing’s published ranges, and all 106 pass the DNS check as well. The list I downloaded on October 22 is dated January 2024 and still covered every one of them. Nine more requests claimed to be Bingbot from two addresses outside the ranges; both resolve to Google Cloud machines and fail both checks, so they are left out. Two details matter for reading what follows. Bing’s snapshot fetcher, BingPreview, uses the same user agent strings as Bingbot, so these are requests from Bing’s crawlers rather than strictly from one of them. And because the CDN answers some requests from its copy without reaching the server, every count here is a floor.

Two things stand out. Before October 17, Bing spent most of its visits on robots.txt and the sitemap: 63 of the 86 requests, against 19 fetches of an actual page in 33 days. Afterward, page fetches outnumbered everything else. The change also came in a single step, eight hours after the second batch, rather than as a slow climb. In five days Bing made almost as many requests as in the 33 before. What the wave did not do is reach most of the site. By October 22, 26 of the 47 URLs in the sitemap had been fetched at least once and 21 had not, among them the notes index, the methodology page and 13 of the notes.

What Bing’s API said about the same pages

The Bing Webmaster API offers two views of crawling from Bing’s side. GetCrawlStats returns daily totals for the site: pages crawled, pages in the index and response codes. GetUrlInfo returns the record of one URL, with a discovery date and a last-crawled date. Microsoft’s reference describes the second method in six words, “Get index details for single page,” and leaves its fields without descriptions. I read both on October 22, for every URL in the sitemap, with pauses between calls, because the per-URL method starts answering “Throttled” after about ten quick ones.

The per-URL records disagree with the log in a specific way. Eight pages that a verified Bing address fetched with a 200 between October 17 and October 21 had no record at all on October 22: no discovery date and no crawl date, the same empty record the API returns for pages Bing has never fetched. Two more gaps are understandable, since one page was fetched only by my live test and one only that afternoon. Across the 47 URLs, 16 appear in both places, 10 only in my log, 1 only in the API and 20 in neither.

The dates in the records behave the same way. For the 15 pages other than the home page that appear in both places, the API’s date falls between zero and five days after the first fetch in my log, and it does not move when Bingbot comes back. The privacy policy was fetched on October 5, 14, 17 and 20, and the API dates its last crawl to October 8. The home page was fetched five times between September 13 and October 4, and the API still dates its last crawl to August 15, two weeks before this site was online. Read as a crawl log, the per-URL report is wrong. Read as what Microsoft calls it, index details, it may be exactly right: a record of what Bing’s index pipeline has processed, which trails the crawler and ignores repeat visits. Bing does not say which, so I can only put the two instruments side by side.

Even the daily totals disagree on the timing. GetCrawlStats counted 5 and 3 pages crawled on October 17 and 18, then 16 and 17 on October 19 and 20. My log has Bing fetching 5, 9, 11 and 4 pages on those four days, not counting the live test. Both show a jump; they do not agree on when it started.

The conclusion I had to take back

This matters because the per-URL report is the obvious place to look, and I looked there first. On October 20 my own notes said that none of the 25 URLs sent on October 17 had been crawled in three days, so the brake had to be the site’s authority rather than the submission. The API itself already showed one of the 25 as crawled. My log, which I had not checked, showed nine. The second half of that conclusion may still be right, and the next section is about why. The first half was a reading of the wrong instrument.

What reached the Bing index, and what did not

The number that answers the question people actually ask is the count of pages in the Bing index, which GetCrawlStats reports per day as InIndex. For this site it was zero until October 1, one on October 2, three on October 3 and eight from October 4. It reached ten on October 17 and eleven on October 20, the latest day the API had on October 22. That is 11 of the 47 URLs in the sitemap, 18 days after the first one appeared and five weeks after the site was added.

The API counts the pages in the Bing index; it does not say which ones. For that there is the URL Inspection tool, one URL at a time, and the url: search operator, which Bing’s help suggests for checking a single address. When I looked in Webmaster Tools on October 20, the About page was indexed and the guide I inspected was not. The same day, Webmaster Tools showed zero clicks and zero impressions for the site over three months, and its AI Performance report had no data at all.

Google got the same sitemap from the same server. On October 22 its URL Inspection API reported 40 of the 42 URLs it was asked about as “Submitted and indexed.” The two it had never seen are the services page and a note, both of which Bing has crawled, so neither engine holds a strict superset of the other. The gap is still wide, and nothing on the server explains it. Every page in the sitemap that Bing asked for was answered with a 200, robots.txt lets Bingbot in, and the API recorded no page blocked by it.

Bing’s help page on missing pages lists the ordinary reasons, and two of them fit a site like this one. The first is time: even if you submit sitemaps or pages “directly to us via your Webmaster Tools account,” Bing writes, “we still need to crawl and assess it before it appears in the index.” The second is links: “A common problem for new websites is the lack of links pointing to it from other places on the web,” and Bing would “prefer to see a few links from quality, authoritative websites pointing at you, rather than see hundreds of new links from random sites.” On October 17, the API counted no inbound links to this site at all. That is consistent with links being the brake, and it is not proof. Bing decides page by page, does not publish its reasons, and says as much in one line of the URL submission page: “Bing may choose not to index specific URLs if they do not meet its selection criteria.”

If Copilot is the reason you care about Bing, the connection is documented. Bing’s guidelines say that “Bing and Copilot search experiences rely on the same core crawling, indexing, and ranking foundation as traditional search.” That makes the Bing index the first thing to check. It does not make a page in the index a page Copilot will cite, and I do not promise citations to readers or to clients. The report that would show them, AI Performance, “does not measure rankings, authority, performance, or importance. It simply shows which content was cited,” and for this site it had nothing to show. Working out which pages are indexed, which are excluded and which of the two you meant is where the technical SEO work I do usually begins, on the server and the CDN as much as in the CMS.

Step by step: submit a site to Bing, then measure what happens

This is the order I would follow on a new site today, with the check that tells you whether each step worked. The commands run against this site as published; replace the domain with yours.

1. Verify the site in a way an edit cannot undo

If the site is already in Google Search Console, import it, and Bing verifies it in the same step. Otherwise use one of the DNS methods. Both keep the proof of ownership outside the pages, where a theme change cannot delete it. Then give it two days, because Bing’s reports start empty and the first numbers you see will be zeros.

2. Submit one sitemap, and request it through your CDN

Submit the sitemap index rather than each child sitemap, and list the same address in robots.txt. Then request it from outside the server, the way Bingbot will, and check the status and the type:

$ curl -s -o /dev/null -w '%{http_code} %{content_type}\n' https://visibleorigin.com/sitemap_index.xml
200 text/xml; charset=UTF-8

Bingbot also guesses. In this log it asked for /sitemaps.xml, /sitemap.xml.gz and /sitemap.txt, none of which exist here, so a 404 on those is harmless. The address in your robots.txt and in Webmaster Tools is the one that must answer with a 200.

3. Turn on IndexNow and check the key file from outside

Many content management systems and CDNs can send IndexNow notices on their own; on this site the SEO plugin does it whenever a post or page is published or updated. The key file must be reachable at the root of the site. Fetch it from outside the server, put your own key in the address, and compare what comes back with the key in your settings:

$ curl -s -o /dev/null -w '%{http_code} %{content_type} %{size_download}\n' https://visibleorigin.com/YOUR-KEY.txt
200 text/plain;charset=UTF-8 32

After that, send notices only for pages that really changed, and expect nothing quick. Here, none of 22 new notes was fetched within a day of its notice. IndexNow gets the URL in front of Bing; it does not move it up a queue you can see.

4. Check the URL Submission quota before you spend it

Look at the quota first. Webmaster Tools shows it on the Submit URLs page, and the API returns it from GetUrlSubmissionQuota. Bing’s 10,000 a day is a ceiling, and this new site got a small fraction of it: 100. Send the pages that matter most, once, and write down when you sent them. Without that note you will not be able to tell, a week later, whether a visit in your log was Bing reacting to you or Bing on its own schedule.

5. Count Bingbot by address, not by name

Download Bing’s list of crawler addresses and match your log against it. This short script prints Bing’s requests per day and the number of addresses they came from. It reads the usual access log format, so it works on Apache and Nginx logs as well as this server’s:

import ipaddress, json, re, sys

nets = [ipaddress.ip_network(p.get("ipv4Prefix") or p.get("ipv6Prefix"))
        for p in json.load(open("bingbot.json"))["prefixes"]]
line = re.compile(r'^"?(\S+) \S+ \S+ \[(\d+/\w+/\d+):')
days, ips = {}, set()
for raw in open(sys.argv[1], errors="replace"):
    m = line.match(raw)
    if not m:
        continue
    try:
        ip = ipaddress.ip_address(m.group(1))
    except ValueError:
        continue
    if any(ip in n for n in nets):
        days[m.group(2)] = days.get(m.group(2), 0) + 1
        ips.add(m.group(1))
for day, n in days.items():
    print(day, n)
print(len(ips), "addresses")

Run against this site’s current log on October 22, the last lines of its output were these:

$ curl -s -o bingbot.json https://www.bing.com/toolbox/bingbot.json
$ python3 bingbot_days.py /path/to/access_log
...
17/Oct/2026 17
18/Oct/2026 16
19/Oct/2026 17
20/Oct/2026 23
21/Oct/2026 5
22/Oct/2026 13
85 addresses

For any address the list does not cover, or for a sample of those it does, use the DNS check. The name has to end in search.msn.com, and it has to point back to the same address:

$ dig +short -x 52.167.144.205
msnbot-52-167-144-205.search.msn.com.
$ dig +short msnbot-52-167-144-205.search.msn.com
52.167.144.205

Then remember what the log cannot see: requests your CDN answered from its own copy. And a request you send yourself with Bingbot’s user agent shows how your site treats that name, not what Bing receives, which is the limit I measured in what running my free check from a datacenter costs it.

6. Read each of Bing’s numbers for what it measures

Use the daily Bing index count to follow the trend, the URL Inspection tool to check a single page, and your own log to see the crawl. Do not take a missing per-URL record as proof that Bing never came: on this site, eight pages had been fetched and still had none. Repeat the reading weekly rather than daily, because the API’s records trail the crawler by days. If you would rather have that routine run for you, checking the sitemap against what the server returns and following index coverage every week is part of the ongoing care I offer.

Bing index: frequently asked questions

How do I submit my site to Bing?

Add the site to Bing Webmaster Tools and verify it, or import it from Google Search Console, which verifies it in the same step. Submit your sitemap there and list it in robots.txt, and turn on IndexNow in your CMS or CDN so that changes are announced as they happen. Keep URL Submission and Request indexing for a few important pages. Each of these is acknowledged within seconds. Crawling and indexing come later, on Bing’s schedule, and none of the steps changes that schedule in a way you can see.

How long does it take Bing to index a new site?

Bing does not publish a time. Its help says reports take about 48 hours after a site is added, which is a different thing. On this site, added on September 15, 2026, the first page entered the Bing index on October 2, by the API’s count, and the count was 11 of 47 on October 20. Bing names the lack of links from other sites as a common problem for new websites, so a site with a few good links may move faster than this one did.

Is IndexNow the same as Bing URL Submission?

No. IndexNow is an open protocol, and one notice is shared with every participating engine, which does not include Google. URL Submission is Bing’s own tool and API, and it only submits URLs to Bing. Their limits are separate: URL Submission has a daily quota that you can see in Webmaster Tools, while the IndexNow FAQ says each engine sets its own thresholds and does not publish them. Bing recommends IndexNow and says URL Submission may be deprecated.

Can I import my site from Google Search Console into Bing Webmaster Tools?

Yes. Bing lists the verified sites in your Search Console account with their sitemaps, and the ones you select are added and verified automatically. Up to 100 sites can be imported at once. Bing then checks ownership through that connection from time to time and imports new sitemaps it finds there, so the link to Search Console is part of how the site stays verified.

Why is Bing not indexing my site when Google does?

Each engine decides for itself; the IndexNow FAQ puts it as “each engine makes its own decision about whether to index it.” Bing’s help lists the usual reasons for a new site: it has not crawled and assessed the pages yet, few or no links point to the site, or the pages fall short of its quality threshold. Rule out the technical causes first: look for verified Bingbot requests in your log and their status codes, and check that robots.txt and noindex are not involved. On this site, Google had indexed 40 of 42 URLs while the Bing index held 11, with no technical block on either side.

How do I check whether a page is in the Bing index?

For one page, use the URL Inspection tool in Bing Webmaster Tools, or search Bing with the url: operator followed by the address. For the whole site, the index count in Webmaster Tools, which the API returns as InIndex, tells you how many pages are in, not which ones. Do not read a missing record in the API’s per-URL report as proof that Bing never crawled a page; check your server log before drawing that conclusion.

The general shape of this

Submitting a site to Bing is a notification, not an instruction. Every way in that I used was accepted within seconds, and none of the acknowledgments said anything about what would happen next. What happened next took weeks, arrived in one step I cannot attribute to any single cause, and so far has put about a quarter of the site’s URLs in the Bing index.

The useful work is in the measuring: counting Bingbot by address, knowing what the CDN hides from the log, and reading each of Bing’s numbers as what it is, not as what its label suggests. The submission is the easy part. Every figure above will change as Bing gets to the rest of the site; the way to check it will not.

Sources

• Bing Webmaster Tools, Adding a site: the import from Google Search Console, the four ownership verification methods and the 48 hours before reports appear.
• Bing Webmaster Tools, Sitemaps: accepted formats, and the sitemap line in robots.txt.
• Bing Webmaster Tools, URL submission: the 10,000-a-day allowance and how quotas are set, repeated submissions, sitemaps read about once a day, and the recommendation of IndexNow.
• Bing Webmaster Tools, IndexNow: what Bing says IndexNow does for crawling and indexing.
• Bing Webmaster Tools, URL inspection: request indexing, its quota, and the Live URL test.
• Bing Webmaster Tools, Why is my site not in the index?: crawling and assessment after submission, links, and the url: operator.
• Bing Webmaster Tools, Verifying Bingbot and Bing’s list of crawler addresses: reverse and forward DNS, and the published ranges.
• Bing Webmaster Tools, Overview of Bing crawlers: Bingbot’s user agents, shared with BingPreview, and the warning that they are easy to spoof.
• Bing Webmaster Guidelines: the common foundation of Bing and Copilot, and the advice on batch submissions.
• Bing Webmaster Tools, AI Performance: what the citation report counts and what it does not.
• Microsoft Learn, IWebmasterApi.GetUrlInfo: the API method behind the per-URL records.
• IndexNow documentation and IndexNow FAQ: what a 200 means, the key file, sharing between engines, crawl quota and indexing decisions.
• My own measurements: this site’s access log from August 28 to October 22, 2026, checked against Bing’s address list and DNS; the Bing Webmaster API (GetCrawlStats and GetUrlInfo) on October 20 and 22; Google’s URL Inspection API on October 22; and the IndexNow history kept by the site’s SEO plugin, October 20 to 22.