Sitemap lastmod reflects real content dates

Both major index operators document sitemap lastmod as a live signal for AI answers, and both condition it on honesty. Bing's guidance for AI-powered search says "the lastmod field in your sitemap remains a key signal" and that fresh discovery "helps ensure that AI systems reference the most current version of a page" — while explicitly ignoring changefreq and priority. Google states it "uses the lastmod value if it's consistently and verifiably … accurate." A sitemap that stamps every URL with the build timestamp claims everything changed on every deploy; that is exactly the inconsistency Google says disqualifies the signal, and it deprives AI systems of the per-page freshness data they use to avoid citing stale content. Vibe-coded sitemaps overwhelmingly default to new Date() for every entry.

Feed lastmod from per-record dates — post frontmatter, CMS/database updated-at fields, or file modification times — instead of a build-time constant, at least for content collections.

// app/sitemap.ts
export default function sitemap() {
  return posts.map((post) => ({
    url: `https://example.com/blog/${post.slug}`,
    lastModified: new Date(post.updatedAt), // per-record, not new Date()
  }))
}

Bing also supports IndexNow for pushing URL changes immediately — optional, but it serves the same freshness goal. Routes that genuinely change every deploy (a homepage with live data) may legitimately use the deploy date.

• ID: sitemap-lastmod-accurate

• Severity: low

• What to look for: This is a code-level check. Locate the sitemap source — app/sitemap.ts / sitemap.xml route, a static public/sitemap.xml, or a generator script. Before evaluating, quote how lastModified/lastmod is populated for each URL family the sitemap emits. Classify each URL family as: (a) per-record dates (frontmatter dates, database updated_at, file mtimes), (b) a module-scope build-time constant (new Date() at module level, a BUILD_DATE const) applied to the family, or (c) no lastmod at all. Identify which families are content collections — blog posts, articles, docs pages, changelogged entries: things with an obvious per-record date available. Count the URL families and report the classification.

• Pass criteria: A sitemap exists, emits lastmod, and every content-collection family derives it from per-record dates. Build-constant lastmod is acceptable on routes that genuinely change with most deploys (homepage, live dashboards, index pages) — the inaccuracy Google disqualifies is claiming change where none happened, and those routes do change. Report even on pass: "Sitemap emits lastmod for X URL families; Y content collections use per-record dates; build-date constant on [families] (routes that change per deploy — acceptable)."

• Fail criteria: A sitemap exists but (a) emits no lastmod at all, or (b) stamps content collections (blog/articles/docs) with a build-time constant even though per-record dates exist in the source data. Report: "lastmod for [family] is a build-time constant (new Date() at module scope) — per-record dates exist in [source] but are unused".

• Do NOT fail for: identical lastmod values in the rendered XML alone — a site whose every page genuinely changed in one deploy produces identical dates legitimately. The failure requires evidence in the code that the date is a constant applied regardless of content changes. Also do NOT fail for changefreq/priority choices: both Google and Bing document ignoring them.

• Skip (N/A) when: No sitemap exists — sitemap presence is covered by the SEO Fundamentals audit. Note in detail: "No sitemap found — cannot assess lastmod accuracy. See SEO Fundamentals audit."

• Detail on fail: "app/sitemap.ts stamps all 4 URL families with a module-scope BUILD_DATE — blog posts have frontmatter dates that go unused. Google: lastmod is used only 'if it's consistently and verifiably accurate'; Bing calls lastmod 'a key signal' for AI answers."

• Remediation: Use per-record dates for content collections:

  // app/sitemap.ts — per-record lastmod for content, deploy date only where honest
  const posts = getPosts()
  return [
    { url: base, lastModified: new Date() }, // homepage changes every deploy: fine
    ...posts.map((p) => ({
      url: `${base}/blog/${p.slug}`,
      lastModified: new Date(p.date), // from frontmatter/CMS, not the build
    })),
  ]