Practical Lens 35: Sitemap lastmod signals must be truthful

Why this happens

• CMS or deployment pipelines update every sitemap date even when content did not change.
• Important pages keep old lastmod dates after substantial editorial changes.
• Different sitemap sources report different dates for the same URL.
• Crawlers cannot reliably separate meaningful updates from automated timestamp noise.

What this usually indicates

• Noisy recency: many URLs show the same fresh lastmod date after every release.
• Stale evidence: important pages look old even after meaningful content updates.
• Sitemap drift: sitemap dates conflict with visible content, HTTP headers or actual publication history.
• Reduced crawl trust: freshness signals become less useful for prioritizing pages.

What to verify (evidence-only)

• Check whether lastmod changes only after meaningful content edits.
• Compare sitemap dates with visible page update dates where available.
• Confirm that all sitemap entries use the final canonical URLs.
• Look for mass-updated dates across unrelated pages after deployments.
• Check whether critical pages have stale lastmod values despite recent content changes.

Terminal check example

Replace example.com with the audited domain. The goal is to compare sitemap lastmod values with page and header signals.

curl -s https://example.com/sitemap.xml | grep -E '<loc>|<lastmod>'
curl -I https://example.com/important-page
curl -s https://example.com/important-page | grep -iE 'dateModified|datePublished|lastmod'

PowerShell check example

Use this on Windows to inspect sitemap lastmod values and compare them with page response metadata.

[xml]$sitemap = Invoke-WebRequest -Uri 'https://example.com/sitemap.xml' | Select-Object -ExpandProperty Content
$sitemap.urlset.url | Select-Object loc,lastmod
(Invoke-WebRequest -Uri 'https://example.com/important-page').Headers