One site in five cannot tell you its IndexNow key is missing
We asked 1,418 websites for an IndexNow key file that does not exist. 19.1% answered 200 OK.
The finding in one sentence: on roughly one site in five, an IndexNow key
file that is missing or misnamed returns 200 OK instead of
a 404, which means every check based on status codes reports success while search engines compare the file
contents, find no key, and discard the submission without telling anyone.
Why this is worth measuring
IndexNow validates by fetching a key file from your domain. You publish
https://example.com/{key}.txt containing the key, and the engine fetches it to confirm you control
the host before accepting anything you submit.
The awkward part is when that check happens. The shared endpoint, Bing and Yandex all answer
202 Accepted to any well-formed request, then validate the key afterwards and discard the
submission silently if it fails. Naver, Seznam, Yep and Amazon fetch the key during the request and answer
403 instead. So the same broken key looks like success on three engines and failure on four, and
the natural thing to do is check the key file yourself.
Which raises the question this study answers: if you fetch your own key file to check it, does the answer mean anything? On a host that returns 404 for missing files, yes. On a host that returns 200 for everything, no. We did not know how common the second case was, and neither, as far as we can find, did anyone else.
Method
A deterministic random sample of 2,500 domains was drawn from the Tranco top one million, restricted to ranks 1,000 to 100,000 and seeded so the sample can be redrawn exactly. Ranks below 1,000 are dominated by infrastructure rather than websites; beyond 100,000 the list thins into domains that are rarely maintained at all.
Each domain got two requests, both read-only:
- A homepage fetch, to establish that the domain serves a website. Tranco ranks by DNS traffic, so the list contains CDN hosts, ad exchanges and DNS endpoints that answer nothing on the apex. Counting those as broken websites would have inflated every other figure.
- A request for a key-shaped file that does not exist:
https://host/{32 hex characters}.txt. This is the exact request an engine makes during validation.
Responses were classified by status: 404 or 410 as correct, 200 as a soft 404, 401/403/406/451 as blocked. No IndexNow submission was sent to any search engine at any point, and no domain received more than two requests.
Results
Of 2,500 sampled domains, 1,082 were excluded as not serving a website, leaving 1,418 qualifying sites.
| Response to a nonexistent key file | Sites | Share |
|---|---|---|
| 404 or 410: verification works correctly | 1,076 | 75.9% |
| 200: soft 404, verification is unreliable | 271 | 19.1% |
| 401 or 403: blocked, engine never reads the file | 28 | 2.0% |
| 5xx, timeout or other | 43 | 3.0% |
95% confidence interval on the 19.1% figure (Wilson score): 17.1% to 21.2%.
Among the 271 soft-404 sites, 97.4% returned an HTML page and 51.3% redirected somewhere else entirely before answering 200. Neither is a key file, and neither is distinguishable from one by status code.
Three things that make it worse than the headline
1. Content-type checking does not save you
An obvious defence is to check that the response is text/plain as well as 200. Four sites in the
sample defeat that directly by serving a soft 404 that claims to be plain text.
Taylor & Francis
(tandf.co.uk, Tranco 46,666) is the cleanest example. Ask it for any nonexistent
.txt and it answers 200, with content-type text/plain, and a body reading
"Site is under construction, please visit later". Correct status for a key file, correct content type for a
key file, wrong contents. Only comparing the body catches it.
bonfire.com (Tranco 31,440) inverts it: content-type text/plain, body is a full HTML
document. The header is simply wrong.
2. Ten sites would validate any key at all
Ten of the 271 soft-404 sites return 200 and echo the requested filename in the response body. The IndexNow specification asks that the file contain the key, so a validator implementing a "does the body contain the key" check would accept any key whatsoever on those hosts.
Whether that is exploitable depends on each engine's implementation, which is not publicly documented, so this is a caveat rather than a vulnerability report. Our own verifier compares the trimmed body for exact equality and rejects all ten, which is the behaviour we would expect of any careful implementation.
3. It is not the badly-run sites
The instinct is to assume this correlates with neglected corners of the web. It does not, or at least not mainly. Verified again on 23 August 2026, all of these answer 200 to a nonexistent key file:
| Site | Tranco rank | Response |
|---|---|---|
| Geox | 44,109 | 200, redirected, HTML |
| Disney Careers | 43,127 | 200, redirected, HTML |
| Mandiant | 40,201 | 200, redirected, HTML |
| Indiana University | 3,530 | 200, redirected, HTML |
| Telecom Italia | 5,148 | 200, redirected, HTML |
| Taylor & Francis | 46,666 | 200, text/plain |
Verified by hand with a browser user agent, independently of the measurement script.
These are well-resourced organisations. A catch-all route that serves the application shell for any unmatched path is a completely ordinary framework default, and nothing about it is a bug in normal operation. It only becomes a problem the moment a protocol depends on 404 meaning "not found".
Does it vary?
Mildly by popularity, and the direction is what you would guess:
| Tranco rank band | Sites | Soft 404 |
|---|---|---|
| 1,000 to 10,000 | 130 | 16.2% |
| 10,000 to 30,000 | 293 | 16.7% |
| 30,000 to 60,000 | 393 | 18.1% |
| 60,000 to 100,000 | 602 | 21.6% |
By server header, where the sample supports it:
| Server | Sites | Soft 404 |
|---|---|---|
| Cloudflare | 488 | 19.5% |
| nginx | 295 | 18.0% |
| not disclosed | 247 | 21.5% |
| Apache | 110 | 13.6% |
| Vercel | 27 | 14.8% |
| Amazon S3 | 26 | 42.3% |
The Amazon S3 figure is the highest in the table and rests on 26 sites, so treat it as a hint rather than a result. Static hosting commonly serves an index document for unmatched paths, which would explain it.
Limitations
This does not measure sites using IndexNow. It measures sites that could adopt it. IndexNow keys are random filenames with no public registry, so adoption is not externally observable and the stronger claim, "X% of IndexNow users are silently failing", cannot be made honestly by anyone, including us.
A soft 404 does not mean a correctly published key fails. If your key file is genuinely there, it is served and verification succeeds. What the soft 404 removes is your ability to detect the case where it is not there.
The blocked figure understates and overstates at once. 313 further domains were excluded because their homepage refused our crawler entirely. A verified Bingbot would very likely not be refused, so counting those as blocked would overstate the problem; excluding them means the 2.0% covers only sites that serve humans and then refuse the key file specifically.
One measurement, one moment. Taken on 23 August 2026 from a single network location. Sites change, and geographically routed infrastructure may answer differently elsewhere.
What to do about it
- Find out which case you are. Request any random
.txtfile at your domain root. A 404 means your key file can be verified by status. A 200 means it cannot. - Verify by contents, never by status. Fetch the key URL and compare the body to your key. This is correct on every host in this study, including all 271.
- Stop treating 202 as confirmation. It means the request was well formed. It says nothing about whether your key was accepted.
- If you can, make unmatched paths return 404. Worth doing regardless of IndexNow: soft 404s cause Google to report Soft 404 in Search Console and waste crawl budget on pages that do not exist.
Our key checker does the second one: it fetches the file the way an engine does and compares the body, so it reports a mismatch on a soft 404 rather than a false pass. It is free and needs no account.
Data and reproduction
The complete result set for all 1,418 qualifying domains is published, one row per site, with rank, verdict, status, content type and server header.
Download the dataset (CSV, 93 KB)Sample: Tranco top 1M, ranks 1,000 to 100,000, seed 42, drawn with a Fisher-Yates shuffle over a mulberry32 PRNG. Two GET requests per domain, 12 second timeout, user agent identifying the study. Re-running with the same seed draws the same domains.
If you repeat it and get a materially different number, we would genuinely like to know: contact@instantindexnow.com. Corrections will be noted on this page.
Measured 23 August 2026. We build an IndexNow submission tool that verifies key files by contents, so we are not a neutral party. The method, the raw data and the sampling seed are published above so the result can be checked rather than believed.