IndexNow vs XML Sitemaps: What Each One Does for Search Discovery

IndexNow and XML sitemaps are often described as competing ways to “get indexed faster.” That framing is wrong. They solve different parts of the discovery problem and, for the search engines that support IndexNow, work best together.

The simple distinction. A sitemap is a structured inventory of the canonical URLs you want a search engine to know about, revisited over time. IndexNow is a notification: it tells participating search engines that a specific URL was just added, updated or deleted. Neither guarantees indexing.

What an XML sitemap does

An XML sitemap is a machine-readable list of the URLs you consider important and canonical. A single sitemap holds up to 50,000 URLs or 50 MB uncompressed; larger sites split into several files under a sitemap index.

The signal that matters is the quality of the inventory, not the number of files:

• Canonical URLs only. Google asks you to list the URLs you want to see in Search; Bing’s guidelines say sitemaps should “list only canonical URLs,” reflect current site structure and “remove deleted or redirected URLs promptly.”
• Truthful lastmod. Google uses lastmod “if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate,” and says it should reflect the last significant update — main content, structured data or links, not a copyright-year bump. Bing’s July 2025 guidance calls lastmod “a key signal” for deciding what to recrawl.
• No priority or changefreq theatre. Google says it ignores both; Bing’s July 2025 post says they “are ignored by Bing.”

One formatting nuance: Bing’s post recommends full ISO 8601 date-and-time values, while Google’s own sitemap example uses a plain date (2022-06-04). A date alone is valid. If your content is edited on a daily editorial cadence, a truthful date beats an invented time of day.

A good sitemap answers two questions: which public URLs should the engine know about, and which of them changed in a way that matters? It is not a publication feed for every CSS tweak.

What IndexNow does

IndexNow is a push protocol. When a page is added, substantially updated, redirected or deleted, a site submits the URL to an IndexNow endpoint. The FAQ says a submission to one participating engine is shared with all IndexNow-enabled engines.

The protocol is explicit about limits. Its documentation says a 200 response “only indicates that the search engine has received your URL” (a 202 means received, with key validation pending). The FAQ adds that “each engine makes its own decision about whether to index it,” and that submitting “does not guarantee immediate indexing.” Every submitted URL also counts toward your site’s crawl quota.

IndexNow does not replace the inventory. Its FAQ says it is “intended for notifying search engines about recently added, updated, or deleted URLs” and not for submitting every URL at once (a full resubmission is reasonable after a migration or redesign); “for ongoing discovery and long-term indexing, use an XML sitemap.”

Which search engines each applies to

As of 30 September 2026, IndexNow.org’s list of participating engines is Microsoft Bing, Yandex, Seznam.cz, Naver, Yep, the Internet Archive and Amazon’s Amazonbot. Google is not on it.

For Google, ordinary editorial discovery still comes from crawlable links — Google says it can generally only follow a link that is an <a> element with an href — from sitemaps, and from Google’s normal crawling. That is why a cross-engine site should never build an “IndexNow-only” workflow: a new page still needs an internal link and a sitemap entry for durable discovery.

Don’t confuse IndexNow with Google’s Indexing API

Google does have an Indexing API, and its name causes recurring confusion. Google’s documentation says it “can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” A normal article, product guide or SaaS page is not an eligible use case.

For an ordinary page, the Google workflow is conventional: publish a crawlable canonical URL, link to it internally, list it in the sitemap with an accurate lastmod, and use Search Console’s URL Inspection selectively when an important new page needs checking.

A side-by-side decision table

A workflow for publishing a new article

1. Publish the final canonical URL. Confirm it returns 200, is indexable and is not blocked in robots.txt for the crawlers you care about.
2. Link to it with a normal <a href> from a relevant indexed page, such as a hub or related article.
3. Add the canonical URL to the XML sitemap.
4. Set lastmod from the publication or last significant content update — never the deploy timestamp of an unrelated CSS or footer change.
5. Notify IndexNow participants, directly or through infrastructure that does it for you.
6. For Google, let normal crawling work. Use URL Inspection selectively for important launches rather than trying to push ordinary pages through the restricted Indexing API.
7. Monitor real indexing and visibility; a successful submission is not success.

When an existing page changes

Signal only meaningful change. If an article gains a new analysis section, its underlying facts change, or its structured data or links change substantially, refresh lastmod and notify IndexNow. A typo, colour or copyright-year change should not masquerade as a content update. IndexNow’s FAQ advises against resubmitting the same URL many times a day and says unnecessary submissions “may lead to wasted crawl quota without improving visibility.”

When a URL is removed or redirected

A deletion is a change too. Remove the old URL from the sitemap, return the right status (404 or 410) or a permanent redirect, update internal links, and notify IndexNow — its FAQ says redirected and deleted URLs should be submitted. Leaving redirected or deleted URLs in a sitemap creates conflicting instructions: the sitemap says “current canonical page,” the server says “moved” or “gone.”

Does every section need its own sitemap?

Usually not. Splitting is useful when URL volume demands it or when segmentation genuinely helps diagnosis. Dividing a small site into many files creates no ranking advantage. A new content section can live in the existing sitemap until it is large enough that separate reporting is actually useful — the trigger should be observability, not superstition.

Avoid duplicate submission systems

If a platform or CDN already sends IndexNow notifications for you, verify that coverage before adding a second publisher. Two systems submitting the same change add complexity without necessarily adding value, and duplicates spend crawl quota.

CrawlPact is served through Cloudflare with Cloudflare’s Crawler Hints enabled. Cloudflare documents that Crawler Hints uses a cache MISS as the sign that content has likely changed and reports it to IndexNow, and that it will not report a response with “an HTTP status code greater than 4xx.” Because CrawlPact’s public pages are edge-cached, a new URL’s first request is a MISS. CrawlPact therefore relies on that mechanism and has not built a second IndexNow client; submissions are checked in Bing Webmaster Tools rather than assumed. Crawler Hints is a signal heuristic, not a publishing hook — it is exactly the kind of coverage worth verifying rather than trusting.

Discovery is a system

Fast discovery comes from consistent signals, not a magic endpoint. A strong public page is linked from the site, listed accurately in the sitemap, canonical, crawlable, indexable — and worth indexing. IndexNow can make change discovery faster for participating engines, but it cannot repair contradictory robots.txt rules, thin content, duplicate URLs or a broken canonical architecture. CrawlPact’s own Bing Site Scan case study shows what one contradictory signal looks like in practice.

For Google and Bing alike, the durable strategy is the same: publish fewer, stronger canonical URLs and make every discovery signal agree about them.