IndexNow vs sitemap: inventory against timing
Both are worth having, and the rest of this page is about why that is the normal answer rather than a hedge.
Side by side
XML sitemap | HTTPS submission | |
|---|---|---|
| Answers | What exists on this site | This address changed just now |
| Scope | Everything you list | One address at a time |
| Read when | On the engine's schedule | Sent at the moment of change |
| Covers pages that did not change | Yes | No |
| Covers pages nothing links to | Yes | Only if something noticed a change |
| Useful for a brand new site | Yes | Not on its own |
| Carries timing | No | Yes, and that is all it carries |
| Fails by | Going stale without saying so | Simply not being sent |
The last three rows are the argument. One mechanism is complete and slow, the other is immediate and narrow, and a site publishing anything regularly needs both properties rather than a preference between them. Read the table as a description of coverage rather than as a scorecard: there is no column that wins.
What only a sitemap covers
Three cases, and a submission cannot reach any of them, however it is configured. These are the cases that settle the argument, because they are not preferences but gaps.
Pages that exist and have not changed
Nothing produces an event for them, so nothing announces them, and they remain perfectly worth knowing about. They are exactly what a list is for, and on most sites they are the overwhelming majority of pages.
Pages nothing links to
An address with no inbound link may never be discovered by crawling at all, and if it also never changes, no submission is ever generated for it. An
XMLlist is then the only mechanism that mentions the address anywhere.A brand new site
Before anything is known about a site, there is no history against which a change can be detected, and few links pointing at it from anywhere. A list published at a known location is the way in, and it is the only one of the three mechanisms that works from a standing start.
Those three are why the sitemap does not become optional when submission is switched on. Each of them is a page an engine would otherwise have no reason to know about, and none of them will ever produce a notice.
What only submission covers
There is exactly one case here, and it is the one people install submission for in the first place.
A change that matters now. A price, a correction, an availability status, a published article: something that was one way and is now another, where the value of an engine knowing is highest immediately and decays from there. The HTTPS request carrying that notice is small, and its whole worth is in when it arrives rather than in what it says. A sitemap can carry the address, but it is read when the engine chooses to read it, which may be after the moment has passed.
That is the entire contribution, and it is worth being precise about how narrow that is, because the narrowness is what makes the claim believable. Submission does not make a page more likely to be kept, does not affect how it is treated once found, and does not reach engines that do not participate at all, as set out under engines.
Why they do not conflict
An engine receiving both is not receiving two versions of the same claim, which is the worry that makes people ask whether to pick one.
The list says what your site contains. The notice says that one item changed. Those are complementary rather than contradictory, and an engine has no reason to prefer one over the other, because they are answers to different questions rather than competing answers to one. Nothing about publishing a sitemap weakens a submission, and nothing about submitting weakens a sitemap.
The one genuine interaction between them is that both depend on the same underlying truth: the address has to be reachable and worth serving in the first place. A submission for an address your site does not serve properly is a notice about a problem rather than about a page, and a sitemap listing addresses that fail is a list of problems presented as an inventory. Fixing what is served is upstream of both, and neither mechanism will tell you that this is what went wrong. Neither mechanism improves what it points at, and neither compensates for a page that is not worth keeping, which is covered under how it works.
The practical arrangement
Both, with each doing its own job and neither one maintained by hand. The maintenance question decides more here than the comparison does: a mechanism that depends on somebody remembering is a mechanism that stops working the week it matters most.
A sitemap generated from your site stays accurate without anybody remembering to update it, and submission attached to whatever already knows about changes happens without anybody remembering that either. Both fail the same way when they depend on a person: quietly, during the busy week when the pages being published matter most. Where that second one is attached matters more than it sounds, because it decides which changes ever become events at all, and it is covered under setup.
What is worth checking occasionally is that the sitemap still reflects the site. A stale list actively misleads about what exists, while a missed submission only means a change is discovered the ordinary way, a little later. The failure modes are not symmetrical, and the list is the one that goes wrong quietly enough to stay wrong for months.
FAQ
Does IndexNow replace a sitemap?
No, and the two are not interchangeable in either direction. A sitemap includes pages that have not changed, pages nothing links to, and a site nothing knows about yet, none of which ever generate a submission. Submission covers the one case a sitemap handles poorly, which is timing.
Do I need a sitemap if I use IndexNow?
Yes, for the three cases above. Submission only exists where a change was detected, so anything static, unlinked, or newly published on a site nothing knows about has nothing to announce, and would be invisible to an engine if the list were removed.
Which one gets my page indexed faster?
Submission notifies participating engines sooner, and that is exactly where its advantage ends. Whether a page is then crawled, kept, or shown is decided separately in both cases, on criteria that neither mechanism influences at all and that neither receives an answer about.
Should the same addresses be in both?
Yes, and that is not duplication in any sense that matters. The list states that an address exists; the submission states that its content has changed. An engine reading both receives inventory and timing rather than the same claim made twice, and has no reason to weigh one against the other.
Submission handled at the edge
IndexNow submission is part of Bridge CDN: the platform detects a change and announces the URL to the engines that take part. Automatic submission covers discovered and changed URLs only, enabling it imports no history, and full-site submission is manual.