Google: skip lastmod if dates are wrong
Incorrect values in an XML sitemap can dilute crawl budget and indexing signals. Google’s Gary Illyes stated clearly on Bluesky that website owners are better off omitting lastmod dates when those values are wrong. His comment was brief but practical: without inaccurate lastmod entries you at least save a few bytes — and, more importantly, you avoid misleading freshness signals.
Why lastmod in the XML sitemap matters
The lastmod element in an XML sitemap is meant to tell search engines when a URL was last meaningfully changed. In theory, that helps crawlers prioritize fresh or revised pages for recrawling. In practice, many CMS platforms, plugins, and export scripts generate timestamps that do not match real content changes. Then lastmod becomes noise instead of a reliable signal.
That is exactly what Illyes was pointing to. When Google repeatedly sees lastmod dates that do not reflect actual change activity, the value of the field drops. In case of doubt, a sitemap without lastmod is cleaner than a sitemap with systematically wrong dates. This is not advice against sitemaps overall, but a clear quality rule for maintaining individual sitemap elements.
Common sources of lastmod errors
Many teams set lastmod to the time of the latest deployment, cache refresh, or sitemap export. The timestamp changes even though the page title, text, internal linking, or structured data did not. Other systems write new dates on every crawl or rendering run while the editorial content stays the same.
- Automatic timestamps without a real content diff
- The same lastmod value for large URL groups after batch jobs
- Timezone and format errors in W3C datetime values
- lastmod on soft-404, redirect, or parameter URLs
- Mismatch between lastmod and the visible change date on the page
Patterns like these can signal to Google that lastmod is not trustworthy. The field then becomes ineffective or ignored. Worse, teams rely internally on seemingly fresh sitemap data and mis-prioritize crawl and content reviews.
A pragmatic choice: omit it or maintain it correctly
Illyes’ statement can be read as a decision rule. Either lastmod is set only when a change is verifiable and traceable, or the element is left out. For many small and mid-sized sites, omitting it is the more robust option until a reliable change logic exists. For large publishers and shops with real change pipelines, lastmod remains a useful control instrument — but only with high data quality.
Technically, that means lastmod must be tied to an editorial or product-related change event. A new paragraph, an updated price, a revised specification, or a new FAQ answer are valid triggers. A nightly sitemap rebuild without content change is not. Soft redirects, canonically consolidated URLs, and purely technical meta tweaks should also not be marked wholesale as content updates.
Checklist for SEO and development teams
- Identify which systems currently write lastmod
- Sample-check lastmod against real content history
- If uncertain, remove lastmod from the sitemap
- If kept, allow only real changes and consistent date formats
- Audit sitemap indexes, URL sets, and change frequency regularly
How this relates to crawl budget and indexing
Sitemaps remain a core discovery and prioritization tool, especially for large sites, new domains, and deeply nested structures. lastmod is only an optional helper signal within that system. More important are correct canonical URLs, reachable status codes, sensible prioritization through internal linking, and stable coverage of key landing pages in the sitemap. Incorrect lastmod values improve neither crawl efficiency nor rankings — they only create inconsistent metadata.
That is why Illyes’ guidance fits technical SEO practice: fewer signals, but trustworthy ones. A lean sitemap without lastmod is often clearer than a complete sitemap with systematically inaccurate change dates. Teams should also watch Search Console: sitemap errors, indexed versus submitted URLs, and crawl stats reveal faster than assumptions whether the sitemap strategy is working.
What editorial teams and agencies should do now
Start with a short audit of sitemap generation. Which CMS plugins, shop modules, or custom exports set lastmod? Are there documented rules for content updates? Do the dates match for news, product pages, and evergreen guides? If the answers are unclear, removing lastmod is the fastest path to better signal quality. After that, a durable change process can be built before lastmod is re-enabled.
For reporting, keep a clean separation: sitemap coverage and indexing status remain KPIs. lastmod is not a standalone ranking factor and should not be treated as a success metric. What matters is whether Google finds, crawls, and keeps important URLs in the index. Illyes’ Bluesky comment is a reminder that technical fields only help when they match reality — and that saving a few bytes is a welcome side effect of sound data hygiene.
Teams that keep lastmod should treat data quality as a monitoring topic. Sampling after releases, checking against CMS revision history, and alerts on mass sitemap changes help detect drift early. That keeps the field a controlled signal instead of an automatic side effect of the deployment pipeline.
Bottom line, the recommendation is simple and operationally actionable. Use lastmod only when the change dates are correct. Otherwise omit it. That stance reduces false alarms in crawl strategies, improves the reliability of sitemap signals, and keeps technical SEO setups closer to how Google actually uses such metadata. For teams with limited resources, it is one of the most efficient optimizations in sitemap management.
