Why does a Next.js sitemap show new dates on every build?
Using new Date() during sitemap generation records deployment time, not meaningful page modification. Source lastModified from content data or omit it.
Written for next.js developers generating XML sitemaps for articles, tools, datasets, and mostly static marketing pages.
Key facts
- Next.js sitemap entries can include lastModified values.
- Google says lastmod should reflect the last significant page modification and be consistently accurate.
- A deployment timestamp applied to every URL makes the signal noisy and hard to trust.
A useful rule: make each important claim understandable and verifiable without requiring the reader to reconstruct your meaning from the rest of the page.
Where does the false freshness come from?
A common sitemap function creates every entry with `lastModified: new Date()`. During a build, that expression gives all URLs the current timestamp even when their content did not change. Some teams also use a single application build date or file-generation time. The XML remains valid, but the field no longer describes the page. Search engines can compare claimed dates with observed changes and may ignore an unreliable signal. Inspect generated sitemap diffs across two identical builds to expose the problem.
- Run two unchanged builds and compare lastmod output.
- Trace each date to its source field.
- Remove global current-time defaults.
What should lastModified represent?
Use the most recent significant change to the indexed page's primary content. For an article, that can be a maintained editorial update timestamp. For a tool, it can be a release that materially changes function or documentation. Navigation, analytics, cookie banners, and routine infrastructure deployments usually should not refresh every page's sitemap date. If the system cannot determine a trustworthy page-level value, omit `lastModified`; Google describes it as optional. A missing field is cleaner than confident but false recency.
- Define significant change by content type.
- Keep editorial and deployment timestamps separate.
- Omit values that cannot be maintained honestly.
Where should dates be stored?
Store publication and modification dates with the canonical content record, not inferred from file-system metadata or Git checkout time. CMS entries can expose reviewed timestamps; repository articles can declare dates in typed front matter. Tools may use an explicit release ledger. Validate ISO values and ensure modification is not earlier than publication. The sitemap, visible page label, metadata, and Article JSON-LD should consume the same reader-facing date where their semantics match. Do not overwrite historical publication dates during migrations.
- Make dates explicit in content records.
- Validate chronological relationships.
- Reuse one source across visible and machine-readable surfaces.
How should generated sitemap code be structured?
Return stable static routes with maintained dates, then map dynamic records to canonical absolute URLs and their own modification values. Filter drafts, missing routes, redirects, and noindexed pages. Normalize origin and paths through the same URL helper used for metadata. Sort output deterministically so diffs reveal real additions and changes. Large sites can split sitemaps according to framework support, but every child sitemap needs the same truthfulness. Avoid asynchronous data that differs between sitemap generation and page rendering.
- Generate entries from the public route inventory.
- Filter noncanonical and nonindexable URLs.
- Keep output deterministic for review.
What tests catch date regressions?
Generate the sitemap twice from unchanged fixtures and require byte-stable dates. Change one article's content timestamp and assert that only its entry changes. Parse every URL and compare it with the production host, route response, canonical, and indexability. Reject future dates and implausibly old defaults. Keep an integration test for one static page and one dynamic article. These tests make the semantic contract visible and prevent a convenience call to current time from silently refreshing the whole site. Review the diff before every release, and retain one known stable fixture for reliable future regression comparison.
- Require deterministic output for unchanged content.
- Assert one record change affects one entry.
- Cross-check every sitemap URL with its live route.
Put it to work
Find the highest-impact fix on your site.
Compare sitemap lastmod values with visible dates, content records, canonical pages, and unchanged builds.
Audit sitemap timestampsSources
- 1.Next.js documentation: sitemap.xmlChecked 2026-07-26
- 2.Google Search Central: Build and submit a sitemapChecked 2026-07-26