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.