IndexNow

How the protocol works

There are only two moving parts. The first is a key: you generate a random string, save it as a plain text file named after itself at your site root, and serve it. That file is public by design — serving it openly at a URL only the site owner could have created is the entire ownership proof, which is why an IndexNow key is not a secret and is safe to commit alongside your code. The second part is the submission: a POST carrying your host, the key, the location of the key file, and the list of URLs that changed.

The mechanics are deliberately small. IndexNow's documentation puts the ceiling at 10,000 URLs in a single POST, which is more than most sites will ever need at once. The first submission from a new key can come back as HTTP 202 rather than 200, because the engine is fetching your key file to check it before accepting anything; once that has happened, successful submissions answer 200. A rejection is almost always the key file — missing, renamed, or serving different contents than the key you sent — so that is the first thing to check when a submission that used to work starts failing.

Which engines are on the list

IndexNow publishes the endpoints that participate, and at the time of writing they are Bing, Naver, Seznam.cz, Yandex, and Yep. The design point worth understanding is that you only submit once: a submission sent to any one participating endpoint is shared across the others, so there is nothing to gain from sending the same batch five times. Several content platforms and CDNs also ship IndexNow support, which means some sites are submitting already without anyone having decided to.

• Google is not on that list. Submitting to IndexNow does nothing for Google Search, which still finds pages the older way — through links and through the sitemap you have already registered in Search Console. Anyone selling IndexNow as a way to get into Google faster is describing a different protocol.
• Bing is the reason most people bother. It is by a wide margin the largest of the participating engines in English-speaking markets, so for most sites it is the one that decides whether running the protocol is worth the afternoon.
• The regional engines are not filler. If Korea, Czechia, or Russia is a real market for you, Naver, Seznam.cz, and Yandex are the domestic search engines there, and their inclusion is a genuine reason to run the protocol rather than a rounding error.
• IndexNow's own framing leans on AI answers. Its documentation describes the protocol as helping keep your content current in AI-powered search results — which is the honest version of the claim, since freshness in an underlying index is upstream of any assistant that reads from it.

What a 200 actually tells you

It tells you the submission was accepted. That is all it tells you. IndexNow's own documentation is unusually direct on this point: submitting a URL does not guarantee that it gets indexed, because the engine still decides whether to crawl it against its own scheduling, its crawl quota, and its quality checks. The protocol moves a page to the front of the discovery queue; everything after discovery is unchanged.

We run IndexNow on agentceres.com as one step in a daily routine rather than on every build, because the protocol asks you not to resubmit unchanged URLs excessively. Today's run read the live sitemap and submitted 415 URLs in a single POST, and the endpoint answered HTTP 200. That number is the whole feedback we get. There is no callback, no per-URL status, and nothing that reports back when or whether a crawler actually arrived — so confirmation has to come from Bing Webmaster Tools, from Search Console for the engines it covers, or from your own server logs. Our submitter refuses to run at all if the hosted key file is missing or its contents disagree with the key in the script, because that mismatch returns a rejection that otherwise looks like a normal failed request and gets ignored.

• Worth setting up if you publish or change pages often enough that waiting on an organic recrawl is a real delay — a documentation site, a programmatic set of pages, an e-commerce catalogue with changing stock, or anything where a deleted page lingering in an index is embarrassing.
• Not worth much if you publish a handful of pages a month and they are well linked internally. A crawl budget that already covers your site comfortably does not need help being spent.
• Never a substitute for the reason to crawl. Announcing a thin page faster gets it looked at faster. It is the same lever as a clean canonical tag or an llms.txt file: plumbing that removes an obstacle, not a reason for anyone to care.