IndexNow and Bing: on by default, and what it does

What is switched on

Bing is one of the two engines that receive submissions without being asked.

In practice that means fewer moving parts than people expect. There is no second key to place for it, no separate credential to hold, and no per-engine account to connect. Submissions travel as an ordinary HTTPS request, and verification happens against the same /<key>.txt file published on your own hostname that every participant checks, so the setup that covers one participant covers this one too.

The scope is narrower than the word "automatic" usually implies, and it is worth having in the exact words: automatic submission covers discovered and changed URLs only; enabling it imports no history; full-site submission is manual. Turning it on is not a backfill, and a site enabling it today does not thereby announce everything it published last year.

The other default participant is Yandex, and the two are on for the same reason rather than for anything specific to either. Which of them matters to you is a question about your readers, and it is covered on the engines overview.

What a submission asks for

An announcement, not a request, and the distinction is the whole subject.

A submission says that an address changed. It does not say the page is worth indexing, does not ask for it to be indexed, and carries no argument about where it should appear. Whether to fetch it, whether to index what it finds, and how to treat the result afterwards are three separate decisions the engine makes on its own criteria and its own schedule, exactly as it would have made them without any announcement at all.

The name the industry has settled on works against this. "Instant indexing" is how the technique is usually searched for, and every word of that phrase overstates what happens: nothing is instant, and nothing here indexes anything. What genuinely changes is that the engine can learn about a change sooner than by revisiting the page on its own rhythm. The mechanics of that are set out on how it works.

The check that misleads people

Almost everybody checks the same way, and that way answers a different question than the one being asked.

The instinct is to search for the page and see whether it is there. That result folds together three decisions, only the first of which involves your site at all: whether the submission was delivered, whether the engine chose to fetch the address, and whether it chose to index what it found and show it for that query. An absence tells you which of the three failed, which is to say nothing.

The check that answers something is about delivery. Was the submission accepted, and is the key file reachable at your own hostname from outside your network? Both are questions with definite answers, they are the only part of the chain you control, and when they are both fine, the rest is the engine's decision rather than a fault to hunt for. The failure modes worth knowing are gathered under troubleshooting.

Where the engine's own tools sit

Bing offers its own tooling for site owners, and it is separate from this.

Those tools belong to the engine, are documented by it, and change when it decides they change, so describing their behaviour here would mean going stale without notice. What can be said accurately is the relationship: the protocol does not replace them, using one does not require the other, and neither is a substitute for the other's purpose. A site can reasonably use both, or either, without the two interfering.

Worth saying plainly for the same reason: Google is not part of any of this, and no arrangement involving Bing changes that. That question has a page of its own, because it is asked more than every other question about this protocol combined.

What makes a submission produce nothing

Four cases, and all four are on your side of the exchange rather than the engine's.

• An address that does not resolve or redirects elsewhere

  Announcing a change at an address that answers with something other than the page is a contradiction, and it resolves the way you would expect: the announcement produces nothing.

• A page excluded by your own configuration

  If robots.txt or a directive on the page itself tells crawlers not to fetch an address, the announcement does not override that. The two instructions are read as what they are, and the exclusion is the one you wrote most recently.

• A page that has not actually changed

  Repeated submission of unchanged addresses is outside what the scope above describes and does nothing useful in any case.

• A key file that stopped being served

  Verification is checked at the time of submission rather than once at setup, so a hostname change or a rule that starts intercepting the path removes verification quietly, while everything else about your site keeps working normally.

What to expect

A narrow, real improvement, and no figure attached to it.

For a site publishing frequently, changes can be learned about sooner than ordinary revisiting would manage. For a site changing twice a year, this is close to irrelevant, and that is worth knowing before configuring anything. For every site, it leaves ranking untouched, because nothing in an announcement addresses it.

No number belongs here. How quickly any engine acts on an announcement is its own scheduling decision, made across everything else it is doing, and a provider quoting you a figure for it is describing a schedule it does not control. The honest shape of the promise is timing, not volume and not placement.

FAQ