IndexNow: What a 202 Actually Means, and Whether Google Cares

I wired IndexNow into this site this week and learned something in the first ten minutes that is not in most write-ups: the success response you almost certainly got back means nothing.

If you submitted URLs and saw HTTP 202, you have not confirmed anything. I proved that to myself with a deliberately invalid key, and it returned the same 202 as my real one.

Here is what the status codes mean, what Google does with IndexNow, and whether the whole thing is worth half an hour of your time.

The 202 problem

IndexNow's bulk endpoint takes a JSON body with your host, your key and a list of URLs. I submitted 175 URLs pulled from this site's sitemap and got back:

HTTP 202

Which looks like success. It is not. Per the protocol's own specification:

• 200 OK - URL submitted successfully. The key was validated.
• 202 Accepted - URL received. IndexNow key validation pending.
• 400 Bad Request - the request itself was malformed.
• 403 Forbidden - the key is not valid.
• 422 Unprocessable Entity - the URLs do not belong to the host, or the key does not match the schema.
• 429 Too Many Requests - you are submitting too often.

A 202 is a receipt, not a verdict. The engine has taken your payload and will go and check your key later. If that check fails, nothing happens, nobody tells you, and your URLs are silently dropped.

The control experiment

To be sure I was reading that correctly rather than guessing, I sent two single-URL submissions through the GET endpoint - one with my real key, one with thirty-two zeros:

real key    -> HTTP 200
all zeros   -> HTTP 202

That is the whole lesson in two lines. The invalid key produced the more reassuring-looking response of the two, because 202 simply defers the question. The 200 is the only one that tells you the engine went and fetched your key file and was satisfied.

So: verify with a single GET, not with your bulk POST. Submit one URL on its own and look for a 200. Bulk submissions legitimately return 202 and you cannot conclude anything from that either way.

Does Google use IndexNow?

No. This is the most-searched question about the protocol and it has a short answer that a lot of posts talk around.

IndexNow is a Microsoft-led protocol. Bing, Yandex, Seznam and Naver participate. Google announced back in 2021 that it would evaluate it and has never adopted it for indexing. Your IndexNow submission does not reach Google, and Google still has to be told about new pages the old way - a sitemap it crawls on its own schedule, or a manual Request indexing in Search Console.

That makes IndexNow a worthwhile addition to your setup rather than a replacement for any of it. If someone sells it to you as a way to "get indexed by Google instantly", they are either confused or hoping you are.

Setting it up: the part that silently fails

The mechanics are genuinely simple. You need three things:

1. A key - any hex string between 8 and 128 characters. Generate it, do not invent it by hand.
2. That key, as plain text, in a file at the root of your site: https://example.com/<key>.txt, containing nothing but the key.
3. A POST to https://api.indexnow.org/indexnow with your host, key, key location and URL list.

The failure mode that catches people is ordering. The key file has to be live before you submit anything. IndexNow fetches it to validate the request. If you deploy your application code first and the key file second - which is the natural order if the submission lives in your backend and the key file lives in your frontend - then every submission in between is rejected, and the 202 you got back will have told you nothing was wrong.

On this site the key file is a static file in the frontend's public/ directory and the submission happens in the backend API, which are two separate deployments. I deployed the frontend first on purpose, then checked the file was actually reachable before letting the API send anything:

curl -s -o /dev/null -w "%{http_code}" https://example.com/<key>.txt
200

Thirty seconds of checking that saves you from a silent failure you would not otherwise notice for weeks.

What the request actually looks like

There is no SDK and you do not need one. The entire protocol is one POST with a JSON body:

POST https://api.indexnow.org/indexnow
Content-Type: application/json

{
  "host": "example.com",
  "key": "a1b2c3d4e5f60718293a4b5c6d7e8f90",
  "keyLocation": "https://example.com/a1b2c3d4e5f60718293a4b5c6d7e8f90.txt",
  "urlList": [
    "https://example.com/blog/my-new-post",
    "https://example.com/blog"
  ]
}

Four fields. keyLocation is technically optional when the file sits at the root under its own name, but send it anyway - it removes any ambiguity about where the engine should look, and costs you nothing.

Two constraints worth knowing before you write the loop: every URL in a single request must belong to the same host, and you can send up to 10,000 of them at a time. If you are backfilling an existing site, read the URLs straight out of your own sitemap rather than querying your database - the sitemap already encodes which pages you consider public, so you inherit that filtering for free.

On a Next.js front end the key file is simply a static file in public/, which means it ships with your normal build and needs no route handler. If your URLs and your publishing logic live in different applications, as they do here, the only thing to remember is that the key file belongs to whichever host serves the pages - not to whichever service makes the call.

Where to call it from

Submit when content actually changes, not on a schedule. On this site the ping is attached to the three admin actions that can make a post publicly visible - create, update and publish - so nothing has to be remembered by hand.

Three conditions are worth enforcing before you send anything, because pointing a crawler at a page it will then be told to ignore wastes the submission and teaches the engine to trust your feed less:

• The post is published, not a draft.
• It is not scheduled for a future date.
• It is not marked noindex.

And make the call best-effort. A search engine being slow or down must never fail an editor's save. Catch everything, log a warning, move on - the sitemap is still there as the slow fallback, which is the entire reason this is an optimisation rather than a dependency.

Don't trust the dashboard either

After my 175 URLs came back 202, I opened Bing Webmaster Tools to watch them arrive. The IndexNow page said:

URLs submitted in last 4 hours: 0

and listed nothing but submissions from April 2025. Hours later it still did.

That is reporting lag, not failure - the protocol-level acceptance and the key validation had both already been confirmed by then. But if the dashboard is the only thing you look at, you will conclude your integration is broken when it is fine, or convince yourself to "fix" something that was never wrong.

Check in this order: the key file returns 200, a single-URL GET returns 200, and only then the dashboard, days later, as a lagging confirmation.

So is it worth it?

Honest answer, and it depends entirely on which problem you have.

Worth it if your content changes and your site has little authority. A site nobody links to gets crawled rarely. Mine had been publishing into a void: the previous version of this site pinged IndexNow through a WordPress plugin until April 2025, then moved to a Next.js stack and nothing replaced it. Eighteen months of posts were never announced to anyone - they just sat in a sitemap waiting for a crawler that had no particular reason to hurry.

Not worth much if you are big. If Bingbot already crawls you hourly, you are telling it something it was about to find out anyway.

Never worth it as a Google strategy, for the reason above.

The real argument for it is the cost side rather than the benefit side. It is one static file, one HTTP call, and perhaps thirty lines of code. There is no ongoing cost, no quota to manage and no account to maintain. Against that, even a modest improvement in how quickly Bing and Yandex notice your work is worth having - particularly now that Bing's index feeds Copilot, which means "how fast does Bing see this page" has quietly become "how fast can an AI assistant cite it". On this site AI assistants already send about as much traffic as Google organic does, so that is not a hypothetical.

What to actually check

If you have IndexNow set up already and have never verified it beyond seeing a 2xx, this takes two minutes:

1. Fetch your key file. It must return 200 and contain exactly the key, nothing else.
2. Submit one URL through the GET endpoint and confirm you get 200, not 202.
3. Confirm your submissions are triggered by content changes, not by a cron job that fires whether anything changed or not.
4. Confirm drafts and noindexed pages are excluded.

If step two gives you a 202 every time, your key is not validating and nothing you have submitted has counted. That is a quiet, invisible failure that can run for months - which is exactly the kind of bug worth spending two minutes to rule out.