Technical SEO

Your Sitemap Is Lying to Google

By John Akande · 7 min read · July 13, 2026

TL;DR

Every page in a sitemap sharing the exact same lastmod timestamp tells Google nothing about which content is actually fresh
This is the default behavior in most Next.js sitemap setups, and AI coding tools will not flag it because the site still looks and performs fine
The fix is a few lines: use real per-page update dates instead of a single build-time timestamp
It is a signal issue, not a ranking factor on its own, but it compounds with every other trust signal Google is already weighing

The bug that doesn't show up in Lighthouse

A site can score 100 on Lighthouse, load in under a second, and still be quietly telling Google the wrong thing about itself. I found this on my own sitemap while auditing this exact site: clean titles, fast builds, solid content, and a sitemap.ts file that undermined all of it.

The tell is always the same. Open the sitemap, check the lastmod field on a handful of URLs, and every single one carries the exact same timestamp, down to the millisecond. The homepage. A resource article from two months ago. The privacy policy. All identical, because all of them were generated by one new Date() call, applied once, to every entry, on every single build.

That's not cosmetic. It's a signal Google actually uses, and a flat signal is the same as no signal at all.

What lastmod is actually for

Work With John

Your site should be your best salesperson. If it is not, that is a fixable problem.

I work with US service businesses and B2B brands to build SEO systems that produce consistent, compounding leads. I will tell you exactly what is broken. No pitch.

Book a free strategy call

The lastmod field in a sitemap exists to tell Google how fresh a page is, so it can prioritise what to recrawl and when. It's one of the few direct hints you get to hand Google about your own content's timeline, and most sites hand over nothing useful.

When every URL shares one timestamp, Google can't tell your homepage from your terms-of-service page in terms of freshness. It just sees a sitemap that was regenerated at build time and never touched again, whether or not that's true.

What it actually costs you

Four things happen when this goes unfixed.

Google treats every page as equally stale. Without a freshness hierarchy, nothing signals "this is new, prioritise it."

Crawl budget gets spent in the wrong places. Google allocates a limited number of crawls to your site. When it can't tell what matters, it often doesn't crawl what matters.

You lose the freshness advantage entirely. Google's freshness signals favour recently updated content, especially for time-sensitive topics. A site with real per-page dates has an edge a flat-timestamp site simply doesn't.

It reads as a trust signal, not just a technical detail. Google evaluates infrastructure, not just content. A sitemap where nothing is ever "recently updated" quietly suggests nobody is maintaining the site.

Why this is so common right now

AI coding tools generate working code fast. They don't generate context. The default pattern in most Next.js sitemap setups is to compute one timestamp at build time and apply it to every entry, because that's the simplest thing that works and still passes every visible check: the build succeeds, the sitemap validates, the site looks done.

Nothing about that process tells you it's wrong. The gap isn't in the tool, it's in not knowing to ask the question. It's an infrastructure problem, not a coding problem, and infrastructure problems don't show up in a Lighthouse score.

How to check if your site has this

Open your live sitemap.xml directly and scan the lastmod tags. If more than a couple of URLs share an identical timestamp, that's the problem in front of you.

If you're on Next.js, check whatever generates your sitemap, whether that's the App Router's sitemap.ts, next-sitemap, or a custom script, and look for a single date variable being reused across every entry instead of a per-page value.

If pages are taking noticeably longer than expected to get indexed after you publish or update them, this is a plausible contributing factor worth ruling out. See the technical SEO overview for how this fits into crawlability and indexation more broadly.

The fix

The fix is structural, not complicated: stop generating one timestamp per build, and start pulling a real date per page from wherever that content actually lives, a CMS field, a data file, a database column, whatever your source of truth is.

Blog posts and articles should use their actual published or updated date. Pages driven by structured data should use whatever "last changed" field already exists for that content. Pages that genuinely don't change often, like a privacy policy, are the one legitimate case where a static date is honest, because it's actually true, as long as that date reflects a real edit and isn't silently regenerating on every build.

The point isn't to fake freshness. It's to stop erasing real freshness data you already have by flattening it into one number.

Why this matters beyond rankings

This is an E-E-A-T signal as much as a technical one. Google's framework for evaluating trustworthiness looks at the whole picture, including whether the infrastructure behind a site suggests ongoing attention or a one-time build nobody has touched since.

A sitemap with real, differentiated dates says someone is maintaining this. A sitemap where everything shares one timestamp says the opposite, whether or not it's true. Fixing it doesn't move rankings by itself, but it removes one more reason for Google to trust the site less than it should. If you want the fuller list of details like this that quietly separate maintained sites from abandoned ones, the 45-point website optimization checklist covers the rest.

Stay Sharp

Guides like this, twice a month.

No agency talking points. No keyword stuffing. Just the frameworks I use on paid engagements, free.

No spam. Unsubscribe any time.

Frequently asked questions

It tells Google when a specific page was last meaningfully updated, which the crawler uses to help decide what to recrawl and how often. It is a freshness hint, not a guarantee of any specific crawl behaviour, but it is one of the only direct signals a sitemap gives you.

Not on its own. It is a signal issue, not a ranking factor with a fixed weight. But it compounds with everything else Google evaluates about your site's trustworthiness and freshness, and it can slow down how quickly new or updated content gets recrawled.

Open your live /sitemap.xml and scan the lastmod values across a handful of different pages. If pages that clearly haven't been touched in months share the exact same timestamp as pages published yesterday, that's the problem.

Replace whatever single timestamp variable is being applied to every entry with a real per-page date pulled from your actual content source, an updatedAt field, a CMS timestamp, or a publish date, so each URL gets its own accurate value instead of one shared build-time date.

No, they're related but separate signals. The sitemap's lastmod is a hint you provide; the Last-Modified HTTP header is a server-level response header. Getting one right doesn't automatically fix the other, and ideally both should be accurate.

Yes, easily. Most default Next.js sitemap patterns compute one timestamp at build time unless someone specifically wires in per-page dates. An AI tool will generate that default pattern correctly and it will pass every visible check, because nothing about it looks broken until you know what to look for.

Less urgently, but the fix costs almost nothing regardless of site size, so there is no real reason to skip it even on a small site.

John Akande

SEO specialist and growth operator working with US service businesses and B2B brands. I build search infrastructure that produces compounding leads — not just rankings.

Book a free strategy call More guides →

← Back to all resources