IndexNow

The usual discovery model works by polling. The crawler comes back to a URL when its own scheduling decides, and until then the change you published does not exist for the search engine. A large share of those visits ends on a page identical to the previous one, and that fruitless check consumes your bandwidth and the search engine's capacity. On a small site the lag barely shows; in a shop with tens of thousands of product pages it can mean the index runs several days behind the catalogue.

IndexNow reverses the direction of the notice. It is the site that informs the search engine at the moment something changes, with a minimal HTTP request. Microsoft Bing and Yandex introduced it jointly on 18 October 2021 with two arguments: cutting crawls that bring nothing, and opening the mechanism to any search engine that wants to join. Notifying one participant amounts to notifying all of them, because each entry point distributes the notice among the rest.

As checked on 19 August 2026, the participating search engines are Microsoft Bing, Naver, Seznam.cz, Yandex and Yep. Google is not among them.

Setup starts with a key. You generate a string of between 8 and 128 characters using letters, digits and hyphens, and publish it in a UTF-8 text file reachable over HTTP whose name is the key itself followed by the .txt extension. The usual place is the root of the domain. If you put it in a subdirectory, you have to state its location in every submission and may only notify URLs that sit below that path.

For a single address a GET request with the URL and the key as parameters is enough. For batches you send a POST with a JSON object declaring the host, the key, the location of the file when it is not in the root, and the list of addresses, with a maximum of 10,000 per request. Every URL in the batch must belong to the declared host.

The response tells you whether the notice got through. A 200 confirms receipt and a 202 indicates the key is still pending validation. A 400 signals an incorrect format, a 403 a key that cannot be verified, a 422 addresses that do not match the host or the key's path, and a 429 a submission rate treated as abusive. The official recommendation is not to repeat the same URL without a meaningful content change, and to leave at least five minutes between resubmissions.

This deserves saying first: anyone selling IndexNow as a general acceleration of rankings is describing something that does not happen. Google announced in November 2021 that it would evaluate the protocol for efficiency reasons and has not adopted it since, so the main organic traffic channel of most European sites stays outside. For Google you keep working with the sitemap, with URL inspection and with an architecture that makes crawling easy.

That said, the notice pays off where there are participants. Before building it, look in your analytics at what share of search visits arrives from Bing, Yandex, Naver or Seznam; that percentage is the honest measure of the benefit. The clearest case is e-commerce with a living catalogue, where price and availability change daily and reaching the index late means serving a wrong product page. On sites with thousands of URLs, the crawl saving also frees capacity for the pages that did change.

There is a limit no documentation hides: notifying is not indexing. The protocol communicates that something has changed and brings the crawler's visit forward. The decision on whether that page enters the index, and with what relevance, still belongs to the search engine.

• Send the notice only when the content genuinely changes, not on every save in the content management system.
• Check that the key file answers with status 200 and contains exactly the string, with no HTML around it and no redirects along the way.
• Log the response code of every submission and review the 403s and the 422s, which betray a key that cannot be verified or addresses outside the declared host.
• Notify removals too, because a URL that turns into a 404 or a 410 is useful information for the crawler.
• Keep the sitemap up to date, since it is the channel that still works for the search engine that does not participate.
• If a plugin or your CDN handles it, check in the server logs that the submissions go out and are not repeated thousands of times a day.

• Promising the client faster indexing in Google, which does not accept the protocol.
• Moving or renaming the key file after configuring it, which makes every submission return a 403 from then on.
• Resubmitting the whole catalogue every night although nothing has changed, which ends up triggering 429 responses.
• Placing the key in a subdirectory and carrying on submitting URLs from across the site, which are rejected with a 422.
• Treating a URL as indexed because the submission returned 200, when that code only confirms the notice was received.