fix(sitemap): lastmod timestamps are always "now", misleading Google recrawl prioritization

[PedroAntunesCosta]

Problem

Both sitemaps set lastmod to the current timestamp instead of the actual last-modified date of each page:

• Static sitemap (next-sitemap.config.js): every page gets the build timestamp, even pages untouched for months.
• Server-side sitemap (src/pages/server-sitemap.xml/index.ts): every page gets the request timestamp, which changes on every crawl.

// next-sitemap.config.js
lastmod: config.autoLastmod ? new Date().toISOString() : undefined

// src/pages/server-sitemap.xml/index.ts
url.lastmod = new Date().toISOString()

Why it matters

Per Google's sitemap documentation:

Google ignores <lastmod> if it's consistently inaccurate. When every URL always shows today's date, crawlers learn the value is unreliable and stop using it to prioritize recrawling — defeating the entire purpose of the field.

In practice this means:

• Pages with genuinely fresh content don't get prioritized for recrawling
• Crawl budget is not allocated based on actual content freshness

Expected behavior

lastmod should reflect when the content was last modified, not when the sitemap was generated:

• Static sitemap: use the git commit date or the article's frontmatter updatedAt field (if available)
• Server-side sitemap: use the lastmod from the OpenAPI spec file or navigation data if available; otherwise omit the field rather than emit a misleading timestamp

Omitting lastmod entirely is valid and preferable to an inaccurate value.

References

• Audit that surfaced this issue: EDU-18465
• Upstream fix that prompted the audit: EDU-16758 / PR chore: reland PR #1226 + PR #1261 — Netlify deploy probe #1264
• Google guidance: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap#additional-notes-about-xml-sitemaps

Files to change

• next-sitemap.config.js — static sitemap lastmod logic
• src/pages/server-sitemap.xml/index.ts — server-side sitemap lastmod assignment