Should you really include the lastmod attribute in your XML sitemaps?

Why does Google care about the lastmod attribute?

The crawl budget — that limited amount of pages that Googlebot is willing to crawl on your site within a given timeframe — is a valuable resource. Google is constantly seeking reliable signals to direct its bots to the pages that have genuinely changed, rather than blindly crawling the entire site.

The lastmod attribute in XML sitemaps is one of those signals. When you indicate that a page was modified on a specific date, you are essentially telling Googlebot: "Come check this one out, there's something new." However, if all your pages show today's date, the signal becomes noisy and potentially unusable.

What happens when I set today's date everywhere?

Google loses the ability to prioritize crawling. Imagine a site with 50,000 pages: if your sitemap indicates that all 50,000 pages have been updated today, Googlebot won't know where to start — and it ultimately ignores this attribute altogether.

The result: you miss out on the main advantage of the sitemap, which is to effectively guide the crawl towards your fresh content. Pages that have been genuinely modified may not be recrawled quickly, while unchanged pages waste crawl budget unnecessarily.

When should the lastmod attribute be updated?

The nuance is important. Google talks about significant changes. A footer change or a CSS adjustment doesn’t warrant affecting lastmod. However, a paragraph overhaul, the addition of a chapter, or an update of numeric data — that’s legitimate.

Many CMS and plugins update lastmod as soon as any field on the page is modified, including invisible metadata. This is precisely the automatic behavior that Mueller points out: you need to control what triggers the update of this attribute.

• Only fill lastmod for pages where the visible content has changed significantly
• Avoid sitemap generators that default to today’s date for all URLs
• Keep lastmod empty or omit it if you lack a reliable system to track real changes
• Prioritize the quality of the signal over the systematic presence of the attribute: an incorrect lastmod is worse than an absent lastmod

Is this statement consistent with what we observe on the ground?

Yes, and it’s even a welcome confirmation. For years, SEOs who closely monitor server logs have observed that Googlebot prioritizes certain pages over others — and that the lastmod attribute plays a role in this prioritization, provided it is credible.

Sites that systematically lie about lastmod (whether intentionally or via a poorly configured CMS) see their sitemap gradually devalued by Google. This is visible in Search Console reports: the percentage of pages crawled after sitemap submission drops, and Google resorts to its own signals (internal links, perceived freshness via SERPs, etc.).

What nuances should be added to this recommendation?

The idea of “significant change” remains vague. Google does not provide a quantified threshold — is it 10% of text changed? 20%? A new section? It likely depends on context, page type, and your site’s usual update frequency. [To be verified] based on your own log analyses and the evolution of your crawl budget.

Moreover, this recommendation mainly applies to large sites. If you have 50 pages, it doesn’t matter if lastmod is accurate or fanciful — Google will crawl everything regularly. But as soon as you exceed a few thousand pages, fine management of this signal becomes strategic.

Are there cases where this rule does not apply?

Yes. News sites, classifieds platforms, or any site with a mass influx of new URLs often need to make compromises. Some prefer to omit lastmod completely and rely on other levers (sitemap frequency, priority, site structure).

Similarly, if your CMS does not easily distinguish between a cosmetic change and a real editorial change, it’s better not to fill lastmod than to do so incorrectly. An inaccurate attribute sends a misleading signal that will eventually be ignored — and you lose all the value of this lever.

What should you concretely do to correctly leverage lastmod?

First step: audit your current sitemap. Download it, extract the lastmod values, and check if they truly correspond to actual content modification dates. If 90% of your pages show the same recent date, it’s a sign of a problem.

Second step: identify what in your CMS or sitemap generator triggers the update of this attribute. Is it a WordPress hook that triggers on every save_post, even if you only changed an invisible metadata? Is it a cron job that regenerates the sitemap and puts today’s date everywhere? You need to reclaim control over this logic.

What technical errors should be avoided at all costs?

The most common error: setting lastmod = today’s date by default in the sitemap generation template. Some developers do this for convenience, thinking “newer = better.” It’s the opposite: you sabotage the signal.

Another pitfall: confusing changes in the database with changes in visible content. If your system updates lastmod whenever an internal data point changes (publication status, tag added, etc.), you will over-report. Filtering these events requires some specific development work, but it’s essential.

How can I verify that my implementation is clean?

Monitor the server logs to see if Googlebot is actually crawling the pages whose lastmod you changed — and if it's ignoring those you didn’t touch. If the bot’s behavior doesn’t change after you correct your sitemap, it means Google has already classified your signal as unreliable.

You can also compare the lastmod dates of your sitemap with the “last crawled” dates in Search Console. A significant and systematic discrepancy between the two indicates that Google is not (or no longer) using your lastmod to prioritize crawling.

• Ensure lastmod is updated only during actual editorial changes in the content
• Disable or correct any plugin/module that sets today’s date by default on all URLs
• Omit the lastmod attribute rather than incorrectly filling it if you lack a reliable system
• Analyze your server logs to confirm that Googlebot properly reacts to lastmod changes
• Document precisely what triggers the update of this attribute in your technical stack
• Test on a sample of pages before deploying a new sitemap logic across the entire site