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 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: no page content, no metadata, no priority hints.

How does IndexNow prove the request is yours?

Because anyone could otherwise submit anyone's URLs, IndexNow asks for 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 public on the same host with no login.

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 works if you pass a keyLocation parameter with the submission. Engines fetch the key file to verify ownership and keep using that key until you change it.

Which search engines receive an IndexNow ping?

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

Read what is not on that list before you plan around it. Google is not a listed endpoint, and neither is any answer engine's own crawler. IndexNow reaches the engines that take part in it, which is a different set from "search" in general and a much smaller set than "every system that might quote you".

What does a site without IndexNow look like to crawlers?

We can show this one on our own site. attensira.com does not send IndexNow pings today. Its edge middleware counts every request that names a crawler in its user agent, and the 30 days to 4 October 2026 make a clean baseline.

bingbot made 541 requests across 207 distinct pages, and Googlebot 189 requests across 80. The two busiest answer-engine crawlers, neither of which takes part in IndexNow, read more of the site: OpenAI's three agents fetched 428 distinct pages and PerplexityBot 331. The chart at the top of this page lines them up; the request volume per operator, a different measure, is on the pay per crawl page.

Bing found 207 of our pages without being told about any of them, through the sitemap and links. That is the honest baseline for a small site: discovery happens anyway, and IndexNow shortens the wait for the engines that take part. The same data shows its limit. The crawlers that read the most of our site are not IndexNow participants, so a ping would have told them nothing. These counts are user-agent claims, not verified identities; how to verify a crawler explains why that matters.

What do the response codes mean?

This is where most implementations go quietly wrong. An HTTP 200 means the engine received your URL. It is not a statement about indexing, ranking or even an 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; later successful submissions usually return 200.

Anything else is a client-side problem to fix, not to 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 escaped and encoded and follow RFC 3986.

When should you send a ping, and when not?

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

User-generated content is where over-notification is easy, and the FAQ gives a taper: submit each review from 1 to 20, then every 5 up to 100, then every 10 up to 1,000. Many sites never need to write any of this, because the FAQ lists native or plugin support in WordPress, Shopify, Wix, Joomla, Drupal and others, and Cloudflare offers it at the CDN layer.

How does IndexNow fit with sitemaps and robots.txt?

It is a notification channel, not a description of your site. XML sitemaps remain the list 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 does not become crawlable because you pushed it, and a page nobody wants is not indexed faster because it was announced.

Its most underrated use is deletion. Telling an engine a page is gone is otherwise slow, and a stale entry for a removed product or price is exactly what ends up repeated back to a buyer.

What goes wrong with IndexNow?

• Reading 200 as indexed. It means received. Check indexing in the engine's own tools.
• Pinging on every save. Trivial edits spend the signal on nothing; send on real changes.
• Expecting Google or answer engines to hear it. Neither is a listed participant.
• Forgetting deletions. Removed pages are where a notice saves the most stale answers.
• Losing the key file. A redesign that drops the file from the root silently breaks every later submission.

Does Attensira use or send IndexNow?

No, and we would rather say so. Attensira does not send IndexNow pings for you. It answers the question a ping cannot: after you change a page, did the crawlers that matter come back for it? With crawler logs installed in your edge middleware, every fetch is recorded against its path and agent, so a page you shipped on Monday either shows a bingbot or OAI-SearchBot request by Friday or it does not. A 200 from the IndexNow endpoint only says the notification was accepted; the log says whether anyone read the page. For the engines that do not take part in IndexNow, which on our site were the busiest readers, that log is the only signal there is.