How to verify an IndexNow submission was actually sent

Why checking that a submission was sent comes first

A rejection, a refusal for volume and a page missing from results all look alike from the outside: nothing visible happened. They have different causes and different remedies, and the first step that separates them is the same in every case: establish whether a submission was sent, and what the endpoint answered. Diagnosing anything else before that is diagnosing a guess.

Where IndexNow submissions are recorded

Every submission is written down in the submission log: the address, the engine it went to, the mode that decided that, the time, and whether the endpoint accepted it. A refusal is recorded the same way as an acceptance, so the log shows failures rather than hiding them.

Where the Fallback mode retries a refused address on the next engine, both lines stay, so the record shows the retry as well as the first answer. In the Balance mode a second engine is not tried at all, because the address was allocated to one. How the three modes spread a list of addresses is set out on the main page.

Reading the endpoint's answer

Each line carries the answer the endpoint gave. A 200 or a 202 means the submission was received; a 403 points at the key or its file; a 422 points at an address that does not belong to the host, or at a key outside the protocol's format; a 429 points at volume. What each code means and what to do about it is set out under response codes.

A line that says received is the end of what the record can show. Whether the engine then crawls, indexes or ranks the page is its own decision, and no record on your side reports it.

When no submission was sent

An empty record for an address is sometimes exactly correct. Automatic submission follows change detection, so an edit that produced no detectable change produces no announcement, and a site whose addresses have not changed has nothing to send. Saving a page without changing it, or changing something that does not alter what the address serves, is not a change to announce. An absence of submissions in that case is the mechanism working as intended, and sending one by hand would only repeat a claim that is not true.

Automatic submission also covers discovered and changed URLs only; enabling it imports no history, and full-site submission is manual. A page that existed before submission was switched on and has not changed since will not appear in the record until it changes.

Checking a submission from the engine's side

Where an engine offers its own console for site owners, that console is the place to ask about a specific address from its side. For Bing that console is Bing Webmaster Tools, which belongs to Bing and is documented by it; the protocol does not replace it. Bing’s own guide to the protocol ends on the same step: use Bing Webmaster Tools to check whether submitted addresses were received. Google does not participate in IndexNow, so no submission ever reaches it and there is nothing on its side to confirm.

The engine's view and your record answer the same first question from two ends. When they agree that a submission arrived, the submission chain is working, and anything left is a question about the page and about the engine's own decision regarding it.

Checking the key file while you are there

A record full of refusals with a 403 usually points at the key file rather than at the submissions themselves. Fetching the file the way the engine does, from outside your network and without following redirects, settles whether it is served correctly; checking the key file sets out the request to make and the four answers it can return. On Bridge CDN the key file is served by the edge at /<key>.txt on your own hostname, so nothing needs to be placed by hand for it to answer.

What the submission log cannot tell you

The submission log is a record of what left your side and what the endpoint answered. It cannot report what an engine did afterwards: whether it fetched the address, whether it kept the page, or where the page appears for a query. Those decisions belong to the engine, are made on its own criteria, and are never reported back to the sender of an IndexNow submission.

That limit is the reason to read the record first and draw conclusions second. A record that shows a submission was received rules out the whole submission chain as the cause of a missing page, which narrows the question to the page itself and to the engine's own decision about it.

What to check after the submission log

If the record shows a refusal, the cause is on your side and it has a remedy: a key file the engine could not read is set out under key not found. If the record shows the submission was received and the page still does not appear, the next step is set out under submitted but not indexed.

FAQ