Skip to main content
AutoIndexNow

Blog · November 3, 2026 · 4 min read

Sitemap lastmod and IndexNow: why you need both

A sitemap lists every page and when it changed; IndexNow announces a change as it happens. How the two signals fit, and how to keep lastmod honest.

"Do I still need a sitemap if I use IndexNow?" comes up a lot, usually followed by its mirror image: "Why use IndexNow if my sitemap already has lastmod?" The short answer is that they do different jobs, and the engines that publish guidance on this ask for both.

Bing says it plainly: "combining sitemaps for comprehensive site coverage with IndexNow for fast, URL-level submission" gives content the strongest foundation for discovery. Here is what each signal does, where each one falls short, and how to keep them consistent.

What a sitemap is for

A sitemap is an inventory: every URL you want discovered, with the date each one last changed. It is pulled, not pushed. Engines fetch it on their own schedule; for Bing, after the first submission, "typically at least once per day."

That makes the sitemap good at completeness and bad at speed. It is the only place an engine can see your whole site at once, including pages that have not changed in years. And it is how the IndexNow FAQ tells you to handle older content: IndexNow "is not intended for retroactive submission of older changes", and the FAQ points to sitemaps with accurate lastmod values instead.

What IndexNow is for

IndexNow is a notification: this URL was just added, updated or deleted. It is pushed the moment you send it, and participating engines share it with each other. It says nothing about the rest of your site.

That makes IndexNow good at speed and useless for completeness. A page you never notified about is invisible to IndexNow, and the FAQ is clear that it "is not designed for submitting every URL on your site at once."

Why lastmod is not a substitute for IndexNow

lastmod carries the same information as an update notification, a URL and when it changed, so it is tempting to see it as a slow IndexNow. The difference is timing and attention. An engine reads lastmod when it next fetches the sitemap, and it still has to choose which of thousands of URLs to recrawl first. IndexNow puts the specific URL in front of the engine when it changes.

Why IndexNow is not a substitute for lastmod

The reverse also fails. Notifications get lost: your job crashed during a deploy, an endpoint answered 429, the site was added to monitoring after the change. A sitemap with accurate dates is the record engines can reconcile against later. It is also the only signal that covers pages you never notified about.

Keep lastmod honest

Both signals are only worth something if they are true, and lastmod is where most sites quietly lie.

The sitemaps protocol is explicit: the date "must be set to the date the linked page was last modified, not when the sitemap is generated." Bing repeats it: use "the true last modification time of the page content, not the sitemap file itself", and "avoid setting lastmod to the time your sitemap was generated unless the content on that URL was actually updated."

The common ways it goes wrong:

  • Build time as lastmod. Static site generators often stamp every URL with the build time. Every deploy then claims every page changed.
  • Database updated_at as lastmod. A view counter or a cache column bumps the row, the sitemap says the page changed, and the content is identical.
  • Template changes. A new footer changes every page's HTML. Whether that is a content change is a judgement call, but announcing it as one, on every page, at once, is not useful.

If engines learn that your lastmod moves without the content moving, it stops being a reason to recrawl. Bing also asks for ISO 8601 with date and time, for example 2026-10-19T14:05:00+00:00, and ignores changefreq and priority, so do not spend effort on those two.

Make the two agree

The cleanest setup derives both signals from the same decision: did this page's content meaningfully change?

  1. When the answer is yes, set the page's lastmod to that moment and send the IndexNow notification.
  2. When the answer is no (a redeploy, a counter, a timestamp in the footer), change neither.
  3. When a page is removed, take it out of the sitemap and notify the removal, which IndexNow covers too.

AutoIndexNow reads your sitemap to know what exists and uses lastmod only to decide which pages to check first. Whether a page "meaningfully changed" is decided by rendering it and comparing a fingerprint of its normalized content. So a sitemap that stamps everything with the build time does not turn into a flood of submissions. See how change detection works.

A quick audit

Pick five URLs from your sitemap that you know have not changed in months, and look at their lastmod. If any shows today's or yesterday's date, your lastmod comes from the build or the database, not from the content, and is worth fixing before anything else.

Then check the opposite: edit one page, publish, and confirm its lastmod moved and nothing else did.

Sources

A 200 or 202 from an IndexNow endpoint means the request was accepted, not that the URL is indexed. Google does not participate in IndexNow.

All posts