Should you really update the lastmod date of the sitemap for every minor change?

What does Google consider a 'significant' change?

John Mueller draws a clear line: a significant change impacts the main content of the page — rewriting a paragraph, adding a section, updating factual data. Conversely, modifying a view counter, adjusting a pixel in CSS, or changing a dynamic display date does not warrant a refresh of the lastmod.

The issue? Avoid saturating the signal. If all your URLs report an updated lastmod every day without a valid reason, Google eventually ignores the attribute or, worse, slows down the crawl of your actually modified pages. The sitemap becomes a noise tool rather than an indexing accelerator.

Why does Google ignore priority and changefreq?

These two attributes date back to a time when search engines naively relied on webmasters' statements. Google has long had its own signals — internal links, traffic, actual content freshness — to decide what to crawl first. Declaring a page as 'high priority' or 'daily' has never forced Googlebot's hand.

In practice, these tags clutter the XML file and burden the parsing without providing value. Better to remove them to lighten your sitemaps, especially on sites with thousands of URLs.

How does this directive influence the crawl budget?

The crawl budget relies on two pillars: the crawl capacity that Google allocates to your site and the crawl demand that it deems relevant. A poorly used lastmod skews the demand — Googlebot thinks a page has changed, spends time recrawling it, finds nothing new, and lowers its priorities.

On a media site that publishes 50 articles a day, updating the lastmod for the entire archive because a widget has moved forces Google to unnecessarily recrawl thousands of pages. The result: new publications are detected later, indexing slows down.

• Only declare a lastmod if the main content has changed — title, body text, key structured data.
• Remove priority and changefreq from your sitemaps; they add no value.
• Monitor your crawl logs to detect excessive recrawling related to fanciful lastmods.
• Automate the lastmod update only when the CMS detects a change in the main content field, not the template.
• Test the impact: disable lastmod for a month on a section of the site and compare the indexing speed in Search Console.

Does this recommendation align with real-world observations?

In technical audits, we regularly see sites that update the lastmod every hour because a script regenerates pages on the fly. Google ends up crawling these URLs less often precisely because it has learned that the signal is false. [To verify] — no public study quantifies precisely Google's tolerance for lastmod noise, but logs show a correlation between stable lastmod and predictable crawl frequency.

Conversely, on e-commerce sites where the price changes in real-time, never touching the lastmod can also pose problems: Google does not know that a product listing has gone out of stock or that the price has dropped by 30%. Mueller's recommendation assumes you can define 'significant' — and that is far from trivial.

What nuances should be considered based on the type of site?

On a blog, the rule is simple: modifying the body of the article = new lastmod, adding a comment or an ad banner = nothing. On a continuously updated news site, the line blurs — does a live blog that enriches every 10 minutes justify a real-time lastmod? Technically yes, but be careful not to send 500 modified URLs every hour in the sitemap.

For UGC platforms (forums, marketplaces), the classic trap: every new comment triggers a lastmod. Result, Google spends its time recrawling threads with no added value. Better to filter: only raise the lastmod if the initial post changes, not the responses.

What to do if Google still ignores your legitimate lastmods?

It happens. You update a strategic page, the lastmod is correct, and Google doesn’t revisit for 3 weeks. Several explanations could be at play — the page is poorly linked internally, it has a history of low traffic, or the site suffers from a tight crawl budget. The lastmod is just one indicator among others, never an order.

In this case, forcing reindexing via the URL inspection tool remains an option but should be used sparingly. If the problem is recurrent, it's probably a signal that the page lacks internal weight — strengthen the linking, create links from the homepage or a hot section.

How to audit the current use of lastmod on your site?

Start by retrieving your XML sitemaps and analyzing the distribution of lastmod dates. If 80% of your URLs have a lastmod identical to today, it's probably a bug. Cross-reference with crawl logs — is Google really recrawling these pages, or is it ignoring the signal?

Use tools like Screaming Frog or OnCrawl to extract lastmod and compare it with the actual modification dates in your CMS. A massive discrepancy indicates a failing script or a default configuration of the sitemap generator.

What business rules should be defined to automate lastmod correctly?

The key: define what counts as 'main content' in your database. For an article, it's the body or title field. For a product listing, it's description, price, stock_status — but not internal metadata like last_viewed_at or admin_notes.

Implement conditional logic: only trigger the lastmod update if a critical field changes. Document this rule and test it in staging before deploying. On WordPress, some plugins allow you to filter the monitored fields — take advantage of this granularity.

Should you completely remove lastmod if you're unsure about managing it properly?

Yes, it's a defendable option. An incorrect lastmod is worse than an absent lastmod. If your CMS does not allow fine control over what triggers the update, or if you lack the resources to audit the logic, it’s better to remove the attribute from the sitemap.

Google will continue to crawl according to its own heuristics — links, popularity, traffic. You lose an acceleration signal, certainly, but you avoid polluting your crawl budget with false positives. This is a reasonable compromise for medium-sized sites without a dedicated technical team.

• Extract all sitemaps and analyze the coherence of lastmod dates.
• Cross-reference declared lastmod with crawl logs to detect any disinterest from Google.
• Identify fields in your database that trigger a lastmod update and filter out non-critical ones.
• Remove priority and changefreq from all sitemaps — they have no utility.
• Test in staging: modify a minor field and check that the lastmod does not change.
• Monitor the impact on indexing speed via Search Console after adjustments.