I turned on IndexNow to fix a Google problem. Google is not in the protocol

The problem I was actually trying to solve

Eighteen days of access log said something uncomfortable. Googlebot fetched my sitemaps thirty-three times, and in the same window my origin recorded it entering exactly one of my eleven posts. Reading the sitemap repeatedly and then not visiting what it lists is not a failure — it is a scheduling decision, and it is Google’s to make — but it did mean nobody was going to find those posts through search any time soon.

That number has a flaw, and I found it four days before this note was due to publish. An origin access log cannot see a request the CDN answered. I tested that rather than assumed it: three requests for the same post gave me a MISS that appeared in my log, then two HITs that never reached my server at all.

Then I made the same mistake twice in one afternoon. My first correction said the comparison was biased because sitemaps are served no-store and therefore always reach the origin. I checked that too, and it is false. Four consecutive requests for my sitemap were all HIT, age 1548 seconds, while the origin was still sending no-cache, no-store, must-revalidate, max-age=0 on every one of them. RFC 9111 section 5.2.2.5 says a cache MUST NOT store any part of such a response. My CDN stores it anyway, because something in my own configuration tells it to override the header — and I had been reading the traffic it hides as if it were the whole picture.

So the honest version is narrower than either sentence I wrote first. My origin recorded Googlebot entering one post. The origin undercounts every resource the edge caches, which here is both the posts and the sitemaps, and from the origin side I cannot tell you by how much for either — which means I cannot tell you which of the two is undercounted more. The real figures are in Search Console under Crawl stats, which counts “the total number of crawl requests issued for URLs on your site, whether successful or not” from Google’s side of the connection, not mine. They are not in your access log, and no amount of care with the log will put them there.

IndexNow is the obvious lever. You publish a key file, you POST a list of URLs, and participating search engines are told your content changed instead of waiting to notice. It took about ten minutes to enable, because the SEO plugin already ships the module switched off.

What I did not do, before turning it on, was read the list of participants.

What the protocol actually promises

IndexNow publishes its own participant list at a well-known address, searchengines.json, and it is short: Bing, Yandex, Seznam, Naver and the rest of the adopters. Google is not in it. Not deprecated, not pending — absent.

That single fact reframes everything that follows. Every good thing I am about to describe happened on the Bing side of the web, and my measured problem was on the Google side. The tool did its job perfectly and missed the target completely.

One endpoint reaches all of them

The official FAQ is explicit that you do not submit engine by engine: “You may submit your request to only one of the following participating endpoints. Each endpoint sends your submission directly to its respective search engine, and your submission will be shared across all other participating search engines.” One POST is the whole job.

Receiving is not crawling, and crawling is not indexing

This is the sentence worth memorising, from the protocol documentation: a success code “only indicates that the search engine has received your URL”. The FAQ goes further and describes what happens next: the engine “evaluates whether it should crawl the URL based on its crawl quota, scheduling logic, and quality signals”, and “each engine makes its own decision about whether to index it”.

So the honest description of a successful submission is: a message was delivered. Nothing about that message obliges anyone to act on it.

The handshake, second by second

Here is what my server recorded. The times are UTC and they come from the access log, not from a dashboard.

One detail before the sequence: I requested all twenty URLs myself, one at a time, before submitting any of them. All twenty returned 200. Submitting a list you have not checked is how you teach an engine that your feed is not worth acting on, and the cost of checking was about forty seconds.

The key fetch is the part of the protocol most people never see, and it is the reason the first response was a 202 rather than a 200. To submit URLs you must “prove” ownership of the host for which URLs are being submitted by hosting at least one text file within the host. The engine has to come and read that file before it will trust anything you sent.

There is a temptation here that I want to name rather than indulge. Bingbot’s previous real visit to this site was seventeen days earlier. Thirteen seconds after my submission it was back. That sequence is suggestive and it is not proof: no engine publishes anything that links a submission to a subsequent crawl, and I cannot see inside Bing’s scheduler. What I can say is what the log says, in the order the log says it.

The 202 that looks like a problem and is not

My first submission returned 202, which reads like a half-success. It is the documented answer. The protocol’s response table is unambiguous: 200 is “URL submitted successfully”, and 202 is “URL received. IndexNow key validation pending.”

The FAQ says when to expect it: “Note: For your first request, you may receive an HTTP 202 response.” The key had not been validated yet, because the key fetch had not happened yet. Thirteen seconds later it did.

The next day the site published a post on schedule and the plugin submitted it by itself. That submission returned 200, and the log entry recorded it as automatic rather than manual. Same site, same key, one day apart: 202 then 200. The difference is not quality of request. It is that ownership had been proven in between.

Three things I could not find out, and neither can you

Working through the documentation, three gaps turned out to be real rather than my failure to look.

There is no way to query the status of a submission

I read the specification and the FAQ end to end looking for a status endpoint, a submission ID, a callback. There is nothing. The only defined indicator is the HTTP code of the response you already got. Bing’s own getting-started page makes the follow-up step a dashboard visit: “Use Bing Webmaster Tools to verify if your URLs are received by search engines.” A panel, not an API.

Nobody publishes the rate limits

The FAQ states that exact limits are not disclosed and that each participating engine sets its own. So any specific number you read about IndexNow quotas came from somewhere other than the protocol. I am not going to add one.

What Google did with my submission is unknowable

It is tempting to write that Google ignored it. I have no evidence of that, and neither does anyone else. What is verifiable is narrower: Google is not on the participant list, so there is no documented path from my POST to Google at all. Whether anything reached them, and what they did with it, is not a question my log can answer.

What to do about Google instead

Since the measured problem was Google-shaped, the honest follow-up is to say what does apply there.

Google’s own documentation on asking for a recrawl is direct about the ceiling: “Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all.” The URL Inspection tool in Search Console will accept a request per URL, and Google notes that indexing “can take up to a week or two”. It also says plainly that submitting the same URL repeatedly changes nothing, which makes the repeat-submission habit a pure waste of a quota nobody publishes the size of.

There is also an Indexing API, and it does not apply to a site like mine. Google’s quickstart scopes it precisely: it “allows site owners to directly notify Google when their job posting or livestreaming video pages are added or removed”. Technical write-ups are neither.

So for Google the toolkit is: a correct sitemap, internal links that actually reach the pages, and patience. Two of those three are work you do on your own site, which is the recurring lesson of every note I have written here.

Which lever reaches which engine

Laid out side by side, the split is stark, and it is the table I should have drawn before enabling anything.

There is a second reason the bottom two rows matter more than they look. Deciding which requests in your log are really from the crawler they claim to be is its own problem, and four in ten of mine were not — which means any conclusion drawn from raw bot counts, including conclusions about whether a submission worked, starts out unreliable.

IndexNow, in practice: frequently asked questions

Does IndexNow work with Google?

No. The protocol publishes its participants at indexnow.org/searchengines.json and Google is not among them. Enabling IndexNow is worth doing for the engines that do participate, but it is not a Google tactic and should not be counted as one in any report.

What does an HTTP 202 from IndexNow mean?

That your submission was received but your key has not been validated yet. The documentation lists it as the expected response to a first request. Once the engine fetches your key file, subsequent submissions return 200.

Do I need to submit to Bing, Yandex and Naver separately?

No. The FAQ states that a submission to one participating endpoint is shared across all the others. One POST covers the group.

Does a 200 mean my page was indexed?

No, and the specification is unusually blunt about it: the code only indicates that the search engine received your URL. The engine then decides whether to crawl it based on its own quota and quality signals, and separately whether to index it.

How do I check what happened after I submitted?

Through Bing Webmaster Tools, which reports submitted, crawled and indexed counts for URLs sent via IndexNow. There is no status endpoint in the protocol itself, so if you are not verified in that dashboard you have no visibility at all.

Is it safe to submit a URL that returns 404?

Yes — that is one of its documented uses, telling engines a page is gone. It still consumes crawl budget, so it is not free, and it will show up in the dashboard as a dead link. Submitting URLs you have not checked is a bad habit for a different reason: it tells the engine your feed is unreliable.

The general shape of this

I enabled a tool in response to a measurement, and the tool addressed a different search engine than the one the measurement was about. Nothing failed. The handshake completed in thirteen seconds, the second submission returned 200, and the automation has worked unattended since. All of that is real and none of it is the thing I needed.

The failure mode is worth naming because it is not laziness: it is that a working system produces satisfying feedback. A 202 turning into a 200, a bot arriving thirteen seconds after a POST — that is the texture of something functioning, and functioning feels like progress whether or not it is pointed at your problem.

The check that would have caught it took two minutes and I did it afterwards instead of before: open the participant list and look for the name you care about. If it is not there, whatever happens next is happening somewhere else.