IndexNow: What It Does, Who Supports It, and How to Set It Up

IndexNow tells Bing and other participating engines when a URL changes. Google does not use it. Here is how the protocol works and how to wire it up with PageIndexer.

You publish a page on Tuesday. Google might not fetch it until the following week. Bing can be quicker, but there is still a gap between "live on my site" and "showing up when someone searches for it."

That gap matters if you run a store with seasonal stock, a news site, or anything where timing is part of the product. Waiting for a crawler to wander back is not a strategy. It is just what happened by default for years.

IndexNow was built to shrink that gap. It is an open protocol: your site sends a small notification when a URL is added, updated, or removed. Participating engines can use that signal to crawl sooner instead of rediscovering the change on their own schedule.

Which search engines actually use IndexNow

This is the part most summaries get wrong. IndexNow is not a Google feature. Google has its own systems, including the Indexing API for certain site types. If your goal is specifically Google coverage, IndexNow alone will not move that needle.

Engines that have adopted or announced support for IndexNow include Microsoft Bing, Yandex, Seznam, and Naver. DuckDuckGo and others have tied into the ecosystem in various ways. The list changes; indexnow.org is the canonical reference.

For a typical marketing site, the practical split looks like this: IndexNow helps on Bing and the smaller engines in that camp. Google needs a different pipe. PageIndexer handles both. IndexNow submissions go out for supported engines, and Google-bound URLs go through the Indexing API where your site qualifies.

What happens under the hood

Before IndexNow, the usual flow was passive. You update a page, refresh your sitemap, maybe ping a search engine, and wait. The engine decides when to recrawl based on its own crawl budget and priorities.

With IndexNow, you push a URL (or a batch of URLs) to an endpoint after the change is live. The engine still decides whether to crawl and whether to index. You are not forcing inclusion. You are skipping the "maybe we will notice eventually" stage.

The protocol also supports delete notifications. If you remove a product or kill an old landing page, you can tell participating engines the URL is gone instead of leaving a stale result in search for weeks.

One honest limitation: a ping is not a guarantee. Thin pages, duplicates, and noindex tags still behave the same way. IndexNow fixes discovery latency, not content quality.

Verification: the key file

Every IndexNow setup starts with a key. You generate a random string, host it as a plain text file on your domain, and include that key when you submit URLs. The engine fetches the file to confirm you control the site.

The file must live at your root domain or a path you declare. A working example looks like https://yourdomain.com/abc123def456.txt with nothing in the file except the key itself.

Platforms that do not give you real root access make this annoying. On Squarespace, people often upload the file through a Link page and redirect a short path to it so the public URL still resolves at the domain root. It is a workaround, not elegant, but it works.

If verification fails, nine times out of ten the file is returning HTML instead of plain text, or it is behind a login, or the URL redirects three times before the engine gives up.

Setting it up with PageIndexer

You can wire IndexNow yourself with a script that POSTs to the API whenever your CMS publishes. PageIndexer exists because most teams do not want to maintain that plumbing.

After you add a site in PageIndexer, the app generates your key file and shows you exactly what to upload. Use the download link in the IndexNow panel, put the file where your host allows, then hit verify inside PageIndexer. Once the check passes, submissions run automatically when your monitored pages change.

If you already use PageIndexer for Google indexing through Search Console, the IndexNow layer sits on top of the same page list. You are not maintaining two separate inventories.

New pages picked up from your sitemap get submitted on the schedule you have configured. You do not need to open Bing Webmaster Tools for every post.

When it is worth the effort

IndexNow pays off on sites that change often: blogs, ecommerce catalogs, local businesses with rotating offers, affiliate pages that get refreshed. If you publish twice a year, the setup cost probably exceeds the benefit.

It also makes sense if Bing traffic matters in your niche. In some verticals Bing still sends a meaningful slice of visits, and faster indexing there is easy upside.

It is less compelling as a standalone "SEO hack." Pair it with solid internal linking, accurate sitemaps, and content worth indexing. The protocol does not rescue a page Google already crawled and skipped.

Common mistakes

Submitting URLs before they return 200. Pinging staging environments. Forgetting to resubmit after a migration changes your domain structure. Claiming IndexNow will "boost Google rankings" in pitch decks. It will not.

Another one: letting the key file expire when you redesign the site and wipe static uploads. Verification silently breaks until you re-upload.

Where to go from here

If you are on PageIndexer already, open your site dashboard, finish the IndexNow verification step, and watch the submission log on your next publish. If you are evaluating the tool, the WordPress use case walks through the full indexing workflow including Search Console.

IndexNow is a small piece of infrastructure. Used correctly, it removes a real delay on engines that listen. Used as a substitute for good pages and honest positioning about what Google does and does not accept, it will disappoint.