IndexNow is routinely described as "instant indexing." It isn't. It's a change-notification protocol: a POST that tells participating search engines a URL on your host changed. What the engine does next — fetch it, queue it, ignore it, index it, drop it — is entirely its own decision, governed by the same scheduling and quality systems that would have handled the URL anyway.
That distinction matters because it determines what you can reasonably expect, and what you should measure. The honest claim for IndexNow is narrow: it can shorten the discovery gap between a change happening and a crawler knowing about it. Everything downstream of discovery is unchanged.
What the protocol actually transmits
The payload is deliberately thin. A batch submission is a JSON POST to any participating endpoint:
POST /indexnow HTTP/1.1
Host: api.indexnow.org
Content-Type: application/json; charset=utf-8
{
"host": "example.com",
"key": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
"keyLocation": "https://example.com/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6.txt",
"urlList": [
"https://example.com/products/widget-9",
"https://example.com/blog/how-widgets-work"
]
}There is no field for what changed, no timestamp, no priority, no content hash, no indication of whether this is a new URL or an edit to an old one. The specification allows up to 10,000 URLs per request. A single URL can also be submitted with a GET to api.indexnow.org/indexnow?url=...&key=....
So the entire information content of an IndexNow ping is: this URL, on this host, is worth looking at now. Compare that to a sitemap with lastmod, which carries the same signal plus a timestamp, but is pull-based — the engine learns about it only when it next fetches the sitemap.
How key verification works, and why a 202 is normal
Ownership is proven with a key file. You generate a key of 8–128 characters (hex characters, letters, digits, dashes), write it as the sole contents of a UTF-8 text file, and host that file so the submitted URLs are under the same path scope. Root is the simple choice: https://example.com/<key>.txt.
The endpoint responds immediately, before verification completes in many cases:
| Status | Meaning | What to do |
|---|---|---|
| 200 | Accepted, key already validated | Nothing |
| 202 | Accepted, key validation pending | Nothing — this is not an error |
| 400 | Malformed request | Fix JSON or key format |
| 403 | Key not valid for the host | Check the key file is reachable and byte-identical |
| 422 | URLs don't belong to the host, or key mismatch | Check for protocol/subdomain mismatch |
| 429 | Too many requests | Back off; you are likely spamming |
Most monitoring failures I see come from treating 202 as a failure and retrying in a loop, which pushes you toward 429. Log the status, don't retry on 202.
One genuine gotcha: the key file must be served as plain text and must not redirect across hosts. A site that force-redirects example.com to www.example.com will fail verification if you submit host: example.com and the key file 301s. Submit the canonical host.
Who actually consumes the ping
IndexNow is a shared endpoint. Submitting to one participating engine's endpoint propagates the notification to the others — that's the explicit design, and it's why api.indexnow.org exists as a neutral address.
The participants that matter in practice are Microsoft Bing, Yandex, Seznam, and Naver. Because Bing's index feeds a long list of downstream consumers, including DuckDuckGo and several AI answer products, the reach is wider than Bing's own search share suggests. Cloudflare offers a one-click integration (originally shipped as "Crawler Hints") that submits on your behalf when it observes cache invalidations.
Google is not a participant. Google said in 2021 that it would evaluate IndexNow, and it has not adopted it since. Google's own push mechanism, the Indexing API, is documented as supported only for JobPosting and BroadcastEvent (livestream) pages. Using it for general content is outside the documented scope, and Google has repeatedly said submissions outside that scope are not honored. If someone sells you "instant Google indexing" via IndexNow, they are selling you a Bing ping.
What IndexNow cannot fix
The reasonable inference from the protocol's design — and from what Bing has said publicly about submission quality — is that IndexNow sits before crawl scheduling, not around it.
- It doesn't raise crawl budget. If a crawler is throttling you because your server is slow or your index-to-crawl ratio is poor, a notification doesn't change that calculus. It changes what's at the front of the queue, not how long the queue is.
- It doesn't affect indexing decisions. A thin page that would be crawled and dropped still gets crawled and dropped, just sooner.
- It doesn't survive abuse. Submitting your entire URL set nightly, regardless of change, destroys the signal's value. Engines have said they weight submission reliability; a host that cries wolf gets discounted.
- It doesn't replace sitemaps. Sitemaps are the recovery mechanism for anything your ping pipeline missed — failed deploys, queue drops, URLs created outside your CMS.
How to measure whether it changed anything
The metric is not "indexed pages." It's time from content change to next crawler fetch, and you can only measure it from your own logs.
- Instrument the change event. Your CMS or build pipeline already knows when a URL's content hash changed. Write that timestamp somewhere queryable.
- Assign a holdout deterministically. Hash the URL path, send even buckets through IndexNow, hold odd buckets back. Don't split by section or template — crawl frequency correlates strongly with both.
- Join to bingbot log hits. For each changed URL, find the first verified bingbot fetch after the change timestamp. Verify by reverse DNS, not user-agent string.
- Compare distributions, not means. Time-to-crawl is heavily right-skewed. Report medians and the 75th/90th percentiles for treated versus holdout.
- Run it long enough to cover a weekly cycle. Crawl rates have day-of-week structure; two weeks minimum.
If the treated group's median time-to-crawl isn't visibly lower, the honest conclusion is that discovery was never your bottleneck on that site. That's a useful finding — it redirects attention to server response time, internal linking, or quality filtering.
What to do
Wire IndexNow into the publish and update hooks of your CMS, not into a nightly cron that dumps your sitemap. Fire only on genuine content-hash changes, deduplicate within a short window so an editor saving six times in a minute produces one ping, and batch rather than firing per URL. Store the response status with the URL and the timestamp so you have a submission log to join against.
Then run the holdout once, measure the distribution shift in your bingbot logs, and write down the number. If it's meaningful, you've bought a free reduction in discovery latency across Bing and everything downstream of it. If it isn't, you've spent an afternoon on a webhook and learned where your actual constraint lives.