IndexNow

IndexNow is a push protocol for telling search engines that a page changed. Instead of publishing and waiting to be re-crawled, a site sends a small HTTP request naming the URL that was added, updated or deleted, and the receiving engines schedule their own visit.

It is deliberately minimal. The documentation describes one request shape for a single URL — a GET to https://<searchengine>/indexnow?url=url-changed&key=your-key — and one for a batch, a JSON POST carrying host, key and a urlList. There is nothing else to it: no page content, no metadata, no priority hints.

Verification by key file

Because anyone could otherwise submit anyone's URLs, IndexNow requires proof of control over the host. You generate a key of 8 to 128 characters, using only lowercase letters, uppercase letters, digits and hyphens; you save a UTF-8 text file whose name is that key with a .txt extension and whose contents are the key itself; and you publish it somewhere publicly reachable on the same host with no login required.

The root is the preferred location, so a key of I-love-IndexNow-3000 on yourdomain.com lives at https://yourdomain.com/I-love-IndexNow-3000.txt. A non-root location is allowed if you pass a keyLocation parameter with the submission. Search engines crawl the key file to verify ownership and keep using that key until you change it. Rotating is simply a matter of replacing the file and starting to submit with the new key; verification happens again on the next submission.

One endpoint, several engines

The design decision that makes IndexNow worth implementing once is sharing. The FAQ states that you may submit to only one of the participating endpoints, and that your submission will be shared across all IndexNow-enabled search engines. Endpoints listed there include a global one at api.indexnow.org plus engine-specific ones operated by Amazon, Bing, Naver, Seznam.cz, Yandex and Yep.

Note what is not on that list, and do not build a plan that assumes otherwise. IndexNow is a way of reaching the engines that participate in it, which is a different set from "search" in general.

What the response codes mean

This is where most implementations quietly go wrong. An HTTP 200 means the search engine received your URL. It is not a statement about indexing, ranking or even intent to crawl. A first request may come back as 202, meaning the URL was received and the key will be verified before the content is indexed; subsequent successful submissions typically return 200.

Anything else is a client-side problem to fix rather than retry blindly. The documentation's advice on a non-200 is to check that you are not submitting too often and that the key and URL are valid, then resubmit. URLs must be URL-escaped and encoded and follow RFC 3986.

When to send, and when not to

The protocol's value depends entirely on submissions being events rather than a habit. The FAQ's guidance is to notify whenever content is added, updated or removed — new product pages, blog posts, job postings or event announcements; updated descriptions or policy pages; price and availability changes; and deletions such as expired events or removed products.

User-generated content is the case where over-notification is easy, and the FAQ gives an explicit taper: submit each review from 1 to 20, then every 5 up to 100, then every 10 up to 1,000. A site that fires a submission on every trivial edit is spending its credibility on nothing.

Many people never need to write any of this. The FAQ lists content management systems with native integration or plugin support — WordPress, Shopify, Wix, Joomla, Drupal, PrestaShop, Typo3, Umbraco and others — and notes that Cloudflare offers native integration at the CDN layer. Checking your platform first is cheaper than an in-house implementation.

How it fits with the rest of discovery

IndexNow is a notification channel, not a substitute for the files that describe your site. XML sitemaps remain the enumeration of what exists; robots.txt remains the statement of what may be fetched; IndexNow adds only the timing signal that something changed. A URL that is disallowed will not become crawlable because you pushed it, and a page nobody wants will not be indexed faster because it was announced.

Its honest benefit is on the deletion side as much as the publication side, since telling an engine that a page is gone is otherwise slow, and a stale entry for a removed page is exactly the kind of thing that ends up quoted back at you.