IndexNow: How to Notify Search Engines Instantly (and Why Google Isn't Part of It)

You publish a page and Bing never shows it. IndexNow exists for exactly that: telling search engines the moment something changes instead of waiting for the next crawl. Here is how to implement it properly in 2026, limits included.

Content is discovered by periodic crawling, and that system is slow: between publishing and the crawler returning, days or weeks can pass. IndexNow changes part of that job, because your site reports which URL changed. The interesting part is who receives that notification.

What IndexNow is and isn't

IndexNow is an open protocol created by Microsoft Bing and Yandex in October 2021 to notify search engines when a URL is created, updated or deleted. Your site sends an HTTP request to a protocol endpoint (an address the notification goes to), and participating engines reflect the change before they would have discovered it on their own.

The goal Bing stated is twofold: reduce exploratory crawling and, over time, limit crawling of the sites that adopt the protocol. Notify, and you get crawled less.

What IndexNow doesn't do

• It guarantees nothing. Bing's official FAQ says it plainly: using IndexNow does not guarantee that web pages will be crawled or indexed. It is a priority signal, not an instruction.
• It does not replace your sitemap or content quality. Useful content, internal linking and crawler-accessible pages remain the foundation.
• Submissions consume crawl quota. Every notification counts; what you gain is priority over other known URLs.
• It is not a channel for Google, and there is plenty of confusion about that.

Who actually uses IndexNow in 2026

The participating engines and services

The protocol's official registry (searchengines.json) lists seven entries: Bing, Yandex, Seznam, Naver, Yep, Internet Archive and Amazonbot. Worth saying it that way, registry in hand, instead of repeating the "all search engines" line, which is false.

Any public endpoint works, because all of them forward the notification to the rest: api.indexnow.org (global), bing.com/indexnow, yandex.com/indexnow, search.seznam.cz/indexnow, searchadvisor.naver.com/indexnow, indexnow.yep.com/indexnow and indexnow.amazonbot.amazon/indexnow. The engine documentation also requires whoever verifies a submission to notify all other participants within 10 seconds: notify one and they all know.

Adoption: why it matters more than in 2021

Bing's official numbers show how much has changed. In December 2024 it reported more than 3.5 billion URLs submitted per day and 18% of new URLs getting clicks in search results, alongside adoptions by GoDaddy, Internet Archive and Condé Nast. In May 2025 came Shopify and Milestone, and Amazon confirmed adoption for mid-June 2025.

The practical consequence: many CMS platforms already submit without their owners knowing (WordPress with the usual SEO plugins, Shopify, Wix, Drupal). Before implementing anything, check whether the site is already doing it.

Google isn't part of it: the three misconceptions

Google does not appear in the participants registry. Its channels for requesting a crawl remain the XML sitemap declared in robots.txt and URL Inspection, with a daily quota and an official warning: repeating the request does not speed crawling up.

• The "sitemap ping". Google's sitemap ping endpoint was deprecated in June 2023 and those requests return 404 today. Any plugin still "pinging" Google is doing nothing useful.
• The Indexing API as a shortcut. It only accepts pages with JobPosting or BroadcastEvent inside a VideoObject, as covered in the video SEO guide. It is not a general way to request indexing.
• "If I notify Bing, Google already knows." It doesn't: these are separate indexes. What is true is that keeping Bing's index fresh has value of its own, because it feeds search surfaces and third-party assistants.

In short: IndexNow buys freshness on the participating engines, while the sitemap and Search Console are Google's channel.

How to implement IndexNow in four steps

Step 1: generate the key

The IndexNow key (its API key) is generated with the official tool and must be between 8 and 128 hexadecimal characters: letters a to z, digits and hyphens. Technically any string meeting those rules works, but the generator avoids copy errors.

Step 2: host the key file

The recommended option is uploading a UTF-8 text file to the site root, named {key}.txt with the key as its only content. It must be publicly reachable and must not be blocked by a misconfigured robots.txt.

The alternative is hosting it elsewhere and pointing to it with keyLocation in every submission. Watch the restriction: the location limits the URLs you can submit with that key. A file at example.com/catalog/key123.txt lets you notify URLs under /catalog/, but not those under /help/.

Step 3: submit one URL or a batch

For a single URL, one GET request with the address escaped per RFC 3986 is enough:

https://api.indexnow.org/indexnow?url=https%3A%2F%2Fexample.com%2Fpage&key=YOUR_KEY

For a batch, a JSON POST with up to 10,000 URLs per request and the Content-Type: application/json; charset=utf-8 header:

curl -X POST https://api.indexnow.org/indexnow \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{"host":"example.com","key":"YOUR_KEY",
       "urlList":["https://example.com/a","https://example.com/b"]}'

The keyLocation field is optional and only used if you picked the second option in step 2. You can mix http and https URLs, and the recommended usage is submitting the moment content changes: the CMS hook on save or publish.

Step 4: verify

Bing Webmaster Tools is where you check that URLs were received, and where you discover whether the site was already submitting. And one clarification that prevents frustration: received is not indexed; the final decision belongs to each engine.

Response codes, quotas and limits

• 200: URL received correctly.
• 202: received, with key validation still pending. Usual on the first submission.
• 400: invalid format.
• 403: invalid key, because the file does not exist or does not contain the key.
• 422: the URLs do not belong to the host, or the key does not match the scheme.
• 429: too many requests, with suspected spam. Pause and retry according to the Retry-After header.

Daily limits are set by each engine per site and are not published, which is why the rule is simple: submit only real changes, at most 10,000 URLs per POST, never resubmit without changes (the FAQ recommends waiting at least 5 minutes between updates of the same page) and log your response codes. Every notification is one more request counting against your crawl budget.

Best practices: when to notify and when not to

• Notify only URLs created, updated or deleted since you started using the protocol; do not try to pay off last year's backlog.
• Do not notify for cosmetic changes. A line in the footer changes nothing; a change to main content, price or availability does.
• Automate with CMS or backend hooks instead of doing it by hand, so nobody has to remember.
• Use deletion notifications: if you remove a URL, that submission helps engines drop it sooner, just like a well-handled 404.
• Pair the protocol with solid basics: useful content, internal linking and a correct sitemap.

How IndexNow fits with what you already have

• Sitemap and lastmod. Google does use the modification date to schedule crawls, but it has to match reality. Google still ignores changefreq and priority.
• CDN. Some CDNs integrate IndexNow out of the box. The documented case is Cloudflare Crawler Hints: it uses the cache MISS signal to send notifications, ships with the free plan and can be turned off per page with the meta robots noindex tag.
• Logs and Search Console. After a submission, server logs show which bots arrived and when; on Google's side, coverage reports tell you how indexing is going.

IndexNow is a discovery accelerator, not a complete strategy: it keeps a recent change from waiting weeks, and that is all it does.

IndexNow implementation checklist

1. Is the site already submitting? Check Bing Webmaster Tools before touching any code.
2. Is the key 8 to 128 hexadecimal characters long, produced by the official generator?
3. Is the {key}.txt file at the root, in UTF-8, reachable and outside your blocked robots.txt rules?
4. Is submission automated when content is created, updated or deleted?
5. Are you sending batches by POST with a maximum of 10,000 URLs and the right Content-Type?
6. Are you sending only real changes, with at least 5 minutes between notifications for the same URL?
7. Are you logging response codes so you can diagnose 403, 422 or 429?
8. Does the sitemap lastmod match reality?
9. Is it clear that Google is handled separately, with sitemap and Search Console?

Notifying fast helps, especially on sites that publish daily. But what decides whether a page enters the index is still the usual: that it deserves to be there and that it can be crawled.