If every URL in your sitemap carries the same lastmod timestamp, your sitemap is telling Google that everything changed at once, every time you deploy. Google uses lastmod only when it's consistently and verifiably accurate, so a flat timestamp throws away a useful hint about which pages to recrawl. The fix is to give each URL the date its content last changed.
The bug that doesn't show up in Lighthouse
A site can score 100 on Lighthouse, load in under a second and still tell Google the wrong thing about itself. I found this on my own sitemap while auditing this site. The titles were clean and the builds were fast, and the sitemap.ts file stamped every page with the same date.
The sign is easy to spot. Open the sitemap and check the lastmod value on a handful of URLs. If the homepage, a two-month-old article and the privacy policy all share one timestamp, down to the second, they were all generated by a single new Date() call applied to every entry on every build.
What lastmod is for
The lastmod field tells search engines when a page last changed in a meaningful way, which helps them decide what to recrawl. Google's sitemap documentation is specific. It "uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate", and the value should reflect "the last significant update to the page". The same page says Google ignores the priority and changefreq fields altogether.
When every URL shares one timestamp, Google can compare it with the pages, see that most of them didn't change, and find little reason to keep relying on your dates.
Work With John
If your site isn't bringing in enquiries, that's fixable.
I work with US service businesses and B2B brands on SEO, websites and lead follow-up. On a free strategy call, I'll tell you what's holding your site back, without a sales pitch.
Book a free strategy callWhat it costs you
The main cost is a lost hint. When you publish a new article or rewrite an old one, an accurate lastmod helps Google notice the change sooner. With flat dates that hint is gone, and Google falls back on its own crawling schedule.
On a large site that changes often, that can waste crawling on pages that haven't changed. Google's crawl budget guidance is aimed at sites with roughly a million pages, or 10,000 that change daily, so on a small site the effect is slower pickup of updates rather than pages left uncrawled.
Freshness matters for some searches too. Google's guide to its ranking systems describes "query deserves freshness" systems that show newer content where searchers expect it. Accurate dates won't make a page rank, but they help Google see when a page has been updated.
Why this is so common right now
AI coding tools write working code quickly, without the context behind it. A common Next.js sitemap pattern computes one timestamp at build time and applies it to every entry, because it's the simplest thing that works. The build succeeds, the sitemap validates and the site looks finished.
Nothing in that process tells you the dates are wrong. The gap lies in knowing to ask the question, and a Lighthouse score won't raise it for you.
How to check if your site has this
Open your live sitemap.xml and read the lastmod values. If more than a couple of URLs share an identical timestamp, and the pages behind them changed at different times, you have the problem.
On Next.js, find whatever generates the sitemap, whether that's the App Router's sitemap.ts, next-sitemap or a custom script, and look for a single date variable reused across every entry.
If new or updated pages take longer than you'd expect to show in Google, this is one possible cause worth ruling out. The technical SEO overview covers how it fits with crawling and indexing more broadly.
The fix
Stop generating one timestamp per build, and pull a real date for each page from wherever its content lives: a CMS field, a data file or a database column.
Articles should use their published date, or their updated date after a substantial edit. Pages built from structured data should use the "last changed" field that data already has. Pages that rarely change, such as a privacy policy, can carry a fixed date, as long as it reflects a real edit and isn't regenerated on every build.
The aim is accuracy. Bumping dates without real changes is the same problem in reverse, and Google's helpful content guidance warns against changing dates to make pages seem fresh when the content hasn't substantially changed.
Dates are part of a maintained site
Accurate dates are one small part of a site being honest about itself, along with visible updated dates on articles and structured data that matches what the page says. Fixing the sitemap won't move rankings by itself, and it's one of the details that separate a maintained site from one nobody has touched since launch. The 45-point website optimization checklist covers the rest of those details.
A stale sitemap is rarely the only thing nobody has kept up with. If your last real technical review was more than a year ago, my website maintenance plans cover this kind of issue on an ongoing basis.
