IndexNow names five search engines, and a 200 only means received

What an IndexNow submission actually contains

The protocol has two request forms and they are both small. To announce one URL, you issue a GET to the search engine's IndexNow endpoint carrying two query parameters, the changed URL and your key. To announce many, you POST a JSON body naming the host, the key and a urlList array. The documentation states you can submit up to 10,000 URLs per post, mixing http and https URLs if needed, and it requires that submitted URLs are escaped and encoded to follow RFC 3986, the standard for URI syntax. There is no payload beyond the URLs. You do not send the content, a last-modified time, a change type, or any description of what changed. The engine learns that something about that address is different and nothing about what.

The key is the authentication, and it is worth reading the rule carefully because the documentation states it twice with different wording. The documentation page says the key should have a minimum of 8 and a maximum of 128 hexadecimal characters, then in the next sentence permits lowercase letters, uppercase letters, numbers and dashes, which is a considerably larger set than hexadecimal. The FAQ on the same site drops the word hexadecimal and simply says 8 to 128 characters with the same permitted set. Anyone generating a key from a UUID, which is what the FAQ suggests, is fine either way. It is a small inconsistency in a short specification, and it is the kind of thing worth noticing before you write a validator against the stricter sentence.

Ownership is proved by hosting the key as a UTF-8 text file whose filename is the key, containing the key. The recommended location is the root of the host, so a key of abcd1234 becomes a file at /abcd1234.txt. A second option allows the file elsewhere, declared per submission through a keyLocation parameter, and that option carries a scoping rule that is easy to miss: a key file at /catalog/ can cover URLs beginning /catalog/ and cannot cover URLs beginning /help/. The documentation adds that URLs falling outside that scope may not be considered for indexing, and recommends the root placement in preference.

The protocol dates from 18 October 2021, when Microsoft published the announcement introducing IndexNow and described it as created by Microsoft Bing and Yandex. That post sets out the case plainly: it can take days or even weeks for new URLs to be discovered and indexed, and telling an engine which URLs changed lets it prioritise those rather than crawl speculatively to find out. It also states an intention that has not obviously arrived, that in the future search engines intend to limit crawling of websites adopting IndexNow. Set against the other file that announces URLs, the difference is direction and nothing else. We have written before that a sitemap tells a crawler where pages are rather than that they changed, and IndexNow is the same assertion delivered by push instead of pull, with the same status: a claim from the site, believed or not by the recipient. For anyone doing generative engine optimisation, that framing matters more than the transport does.

Which search engines receive an IndexNow submission

The protocol site answers this in one sentence on its home page, and the sentence is worth quoting exactly because a great deal of secondhand advice paraphrases it loosely. Read on 12 August 2026, indexnow.org states that IndexNow is offered under the terms of the Attribution-ShareAlike Creative Commons License and has support from Microsoft Bing, Naver, Seznam.cz, Yandex, Yep. That is five named search engines. Google is not one of them, and nothing on the page suggests it is.

That absence is the single most consequential fact about IndexNow for anyone reasoning about AI answers, and it is worth stating without decoration. If your interest in faster discovery is driven by Google's generative surfaces, this protocol does not reach them, and Google's own advice for announcing URLs remains a sitemap. Whether the engines that do participate feed any particular AI assistant is a separate question, and one this post deliberately does not answer, because we have not verified any vendor's retrieval pipeline and a claim of that shape needs a primary source rather than an inference. What we have written about, from published measurement rather than assumption, is how rarely ChatGPT prompts carried citations and where those referrals landed, and the platform reference for that surface sits at getting cited in ChatGPT.

The sharing rule is the second thing the documentation settles, and it is a genuine design decision rather than a courtesy. Under a heading titled Requirement for search engines, the documentation states that search engines adopting the IndexNow protocol agree that submitted URLs will be automatically shared with all other participating search engines. The 2021 Bing announcement puts the same rule from the publisher's side: by notifying one search engine you will notify all search engines that have adopted IndexNow. So the endpoint you choose is not a routing decision. You submit once and the participants distribute among themselves, which is why Bing's four step integration guide can describe the whole thing as generate a key, host it, submit, verify.

There is also a stated bar for joining. The same section says that to participate, search engines must have a noticeable presence in at least one market or be closely linked to the search market and make a significant contribution to the number of url submissions. That is a membership rule written by the incumbents, and it explains why the list is short and stable rather than open. It is a reasonable rule and it is also worth naming for what it is, because a protocol whose participant list is gated by the participants is a consortium rather than a standard, whatever the licence on the document says. The same distinction turns up repeatedly in this space: llms.txt is a proposal one author maintains, robots.txt is an IETF standards-track document, and IndexNow is an agreement between named companies. All three are described as open, and they mean three different things by it.

What the response codes report, and what they do not

IndexNow publishes a six row response table, and it is unusually candid about the limits of its own success case. A 200 is documented as OK, URL submitted successfully. A 202 is Accepted, with the reason given as URL received and IndexNow key validation pending. A 400 is a bad request with an invalid format. A 403 is forbidden in case of a key not valid, which the table expands to cover a key file that is not found and a key file that is found without the key inside it. A 422 is unprocessable entity, for URLs which do not belong to the host or a key not matching the schema in the protocol. A 429 is too many requests, annotated as potential spam.

The sentence that matters is not in the table. Twice on the documentation page, once for the single URL form and once for the batch form, the specification states that the HTTP 200 response code only indicates that the search engine has received your URL. That is the protocol drawing its own boundary, and it is more honest than most of the writing about it. Receipt is not validation, since validation of the key can still be pending under a 202. Validation is not fetching, because the engine still has to come and request the page. Fetching is not indexing. And indexing is not being cited in an answer. IndexNow reports the first of those five states and is silent on the other four.

Anyone who has spent time with crawler behaviour will recognise the shape of that gap, because a status code repeatedly turns out to describe the transaction rather than the outcome. We covered a study in which sites that banned GPTBot in robots.txt served it a 200 anyway, where the code said success and the stated policy said the request should never have been answered. Here the direction is reversed but the lesson is the same: a 200 is a fact about one HTTP exchange and carries no information about the system behind it.

The 429 deserves a note of its own, because it is the row a publish pipeline will meet first. The FAQ gives a concrete throttling pattern for user generated content, suggesting a site submit each new review from 1 to 20, then every 5 up to 100, then every 10 up to 1000, which is an explicit acknowledgement that a naive one-submission-per-change loop on a busy site is exactly what the spam response exists to catch. That is a rate limiting concern rather than a correctness one, and it is worth designing for before the first deploy rather than after. On the wider question of what a crawler is entitled to assume from any of this, RFC 9309 remains the document that governs whether the crawler may fetch the page at all, and our robots.txt tester resolves that per named token. Nothing in IndexNow overrides it. A submitted URL that robots.txt disallows is a URL the engine has been told about and is not permitted to fetch, and the protocol has no opinion on that conflict.

Discovery is one layer, readability is another

Here is the part only a scanner has much to add to, and it is a distinction rather than a criticism. IndexNow operates entirely on the discovery layer. It compresses the interval between you publishing and an engine knowing the address exists. Every question about whether that engine can then use the page lives on a different layer, downstream, and is decided by bytes your server sends in response to a request the ping merely hastened.

This site exists because two separate layers decide whether AI can read your site and they fail independently. Access is the first: robots.txt, per crawler, plus whatever your CDN or bot rules do to a request that does not look like a browser. Content is the second: whether the text a human sees in a browser is present in the raw HTML response, which is what prose parity scores, or whether it only appears after JavaScript executes. A client-rendered page has a parity problem before any crawler is told it exists, and telling that crawler sooner produces a faster arrival at the same empty document.

That is not a hypothetical failure mode. It is the ordinary case for a large class of modern sites, and it is why crawlers that do not execute JavaScript keep showing up in our writing, including an archive of 2.14 billion pages collected without running JavaScript at all. For a page built that way, a discovery signal is the least of its problems. The sequence is worth holding in order: the ping causes a fetch, the fetch is subject to robots.txt, the response is subject to your access rules, and only the bytes that survive all three are available to be read. IndexNow acts on the first arrow in that chain and on none of the others.

The practical consequence is a diagnostic one. If you wire up submission and nothing changes, the protocol has given you no way to tell why, because the only signal it returns is receipt. Working out where the chain actually broke means looking at the response a crawler receives rather than at the submission you sent, which is what what GPTBot sees is for on a single URL, and what our scoring method sets out for a whole page. That ordering is the useful takeaway from all of this. Fix the layer that decides whether the text is there before spending effort on the layer that decides how quickly somebody is told to come and look at it.

What to check before you wire IndexNow into your publish step

Four checks follow from the documentation rather than from opinion, and each one has a failure mode that returns no useful error.

The key file has to be fetchable by a search engine, not by you. It is a plain text file at a public URL with no login, and the engine fetches it to verify ownership before accepting submissions. That means it passes through exactly the same edge rules as any other non-browser request to your origin, and if those rules are aggressive the verification fails for the same reason a crawler fetch fails. Refusing automated clients is common enough to have been measured: researchers recorded headless Chromium soft blocked on 15.2 percent of the top 10,000 sites, and a request for a key file is a less browser-shaped thing than that. Open the key file URL from outside your network before assuming it works.

The scoping rule bites if you take the second key placement option. A key hosted below the root covers only URLs under its path, and the documentation warns that URLs outside that scope may not be considered for indexing. Nothing rejects the submission loudly; the URLs simply may not count. The documentation's own recommendation, to place the key at the root, exists precisely to remove this class of silent partial failure, and there is rarely a good reason to take the other option.

If a CDN is submitting on your behalf, find out what it treats as a change. Cloudflare's Crawler Hints documentation, last updated 5 May 2026 and available on the free plan upward, states that the feature supports IndexNow and that it uses cache-status MISS to determine when content has likely been updated before sending it to IndexNow's crawler. It adds that if an asset's response has an HTTP status code greater than 4xx, the hint will not be reported. A cache miss is a proxy for a change rather than a change, so an automated integration is asserting something slightly different from what you would assert by hand. That is a reasonable engineering trade and you should know which of the two your site is making.

Finally, keep the expectation calibrated. Google's own instruction for announcing URLs remains building and submitting a sitemap, and a sitemap is still the mechanism with the widest reach even though it is slower. IndexNow is worth doing for a site that publishes or changes pages frequently and cares about the engines on the supporter list. It is cheap, the protocol's FAQ names sixteen content management systems offering native integration or plugin support and names Cloudflare as a CDN with native integration, and the downside is a rate limit rather than a risk. Just do not expect it to answer a question it never claimed to answer. Crawlers also do not re-read your instructions instantly, which is a related patience problem we covered in how long a robots.txt edit takes to reach a crawler, and none of these timing mechanisms decides what a crawler finds when it finally comes. That part is your HTML.