Why does Google ignore the lastmod dates in your XML sitemap?

What happens when all dates are the same?

When Google Search Console detects that an XML sitemap shows the same modification date for 100% of the URLs, the algorithm neutralizes this information. Technically, the sitemap remains valid and parsable, but the temporal signals disappear. Googlebot continues to read the file to identify any new URLs to index, but it gives no priority to contents marked as recently modified.

The problem often stems from poorly configured automated scripts: some CMS or plugins generate sitemaps on-the-fly and systematically apply today's date to all entries. This practice starts from a good intention — signaling freshness — but it sabotages the signal by drowning it in noise. Google cannot distinguish a genuinely revamped article from a static page that hasn’t changed in three years.

Are priority and changefreq tags truly useless?

Yes, and this has been documented for a while. The <priority> tag was intended to indicate the relative importance of a page within a site — from 0.0 to 1.0. The <changefreq> tag suggested a frequency of updates (daily, weekly, monthly). However, Google has publicly confirmed that it ignores both attributes in nearly all cases.

Why? Because every webmaster mechanically assigns priority="1.0" to all their important pages, which effectively means everything is a priority — hence nothing is. The same logic applies to changefreq: sites indicate “daily” by default without the content moving substantially. The engine has stopped trusting these self-declared signals and prefers to analyze the frequency of modifications itself through its own successive crawls.

What constitutes a “major” content change in Google's eyes?

Google does not publicly define a precise quantitative threshold — there’s no “30% modified text” or minimum word count. However, Mueller and other spokespersons have clarified that it involves a substantial modification of the editorial body: rewriting an entire paragraph, adding new sections, updating numerical data, restructuring the argumentative framework.

Conversely, the following do not count as major changes: simply incrementing a view counter, adding a user comment, modifying a footer or a common sidebar across the site, or changing a CTA button without altering content. These micro-variations often trigger a regeneration of the sitemap with a new date, even though the indexable content remains unchanged.

• identical lastmod everywhere → Google disables the temporal signal and limits itself to discovering URLs
• priority and changefreq → ignored in most configurations, signal has become unreliable
• Major change → substantial modification of indexable editorial content, not just a technical or cosmetic detail
• Automated scripts → often responsible for systematically overriding dates with today's value
• CMS audit → check that the sitemap generator correctly retrieves the actual publication or last editorial modification dates from the database

Is this guideline consistent with real-world observations?

Absolutely. We have observed for years that sites that play the transparency card — providing only the actual dates of editorial modifications — experience a higher crawl rate for recently updated pages. Conversely, sites that reset all dates to today’s date daily see Googlebot spacing out its visits on stable content, as it can no longer trust the sitemap to detect what has truly changed.

A classic test involves a server log audit after correcting a sitemap polluted by uniform dates: in the days following, you see the bot focusing its resources on URLs whose lastmod tags have indeed changed since the previous crawl. This is an indirect but measurable signal that Google reactivates the consideration of this metadata once it becomes reliable again.

What nuances should be applied to this rule?

The first nuance: Google refers to a sitemap where all URLs carry the same date. If 95% of your pages show variable and consistent dates, but 5% accidentally bears today's date (e.g., automatically regenerated category pages), the engine does not necessarily cut the signal for the entire file. It simply downgrades the trust placed in the sitemap as a whole. [To be verified]: Google has never published a numerical threshold (“if more than X% of URLs have the same date, lastmod is ignored”), so caution is warranted on mixed configurations.

The second nuance: some sites with very high publication frequency — news aggregators, user-generated content platforms — can legitimately see a significant portion of their URLs changed daily. In this case, having many entries dated today is not suspicious. Yet even there, it is rare for 100% of the pages to change simultaneously: a good sitemap should reflect the actual distribution of updates.

Should XML sitemaps be abandoned?

No. The sitemap remains a valuable discovery tool, especially for deep or orphaned content that lacks strong internal links. Even if Google ignores lastmod/priority/changefreq, simply listing a URL speeds its initial indexing. This is particularly critical for large e-commerce sites or media outlets that publish hundreds of pages daily.

However, we must stop viewing the sitemap as a crawling prioritization lever if we do not inject reliable data into it. A minimalist sitemap — just <loc> and a real <lastmod> — is better than a file bloated with fanciful metadata that the engine will learn to ignore. And if your CMS does not allow the retrieval of the actual modification dates, it is better to completely disable the lastmod tag rather than pollute the signal.

What concrete steps should be taken to fix a misconfigured sitemap?

First step: audit the sitemap generator. Identify if it is a WordPress plugin (Yoast, RankMath, All in One SEO), a custom script, or a native CMS module. Check in the code or settings if the <lastmod> tag is wired to a database field corresponding to the real editorial modification date (post_modified, updated_at) or if it is systematically calling date(). Many plugins offer an option “use post modified date” that needs to be checked.

Second step: clean up aberrant historical dates. If your site has accumulated sitemaps with uniform lastmod for months, Google may have already disabled the signal. Regenerate the file with actual dates, then force a new submission via Search Console (or wait for the next automatic fetch). Monitor the logs to verify that Googlebot starts prioritizing crawling the URLs whose date has changed since its last visit.

What mistakes to avoid when redesigning a sitemap?

Do not confuse publication date and modification date. Some CMS offer two fields: created_at and updated_at. For the sitemap, updated_at is what counts — unless the page has never been modified, in which case both are the same. Also, avoid triggering an update of lastmod for trivial changes: fixing a typo, adding a missing alt tag, modifying a global menu. These micro-interventions do not justify a new freshness signal.

Another classic trap: index sitemaps pointing to on-the-fly generated sub-sitemaps. If each sub-sitemap is recreated daily with today’s date for all its entries, the problem cascades up to the parent level. Ensure that the generation logic correctly cascades the actual dates from the data source to the final XML file.

How can I check if my sitemap is now being utilized by Google?

First verification: Search Console, Sitemaps report. If Google detects an inconsistency issue (all dates identical), it will not explicitly notify you as an error — the file remains valid in terms of XML protocol — but you can cross-check with the Coverage report to see if recently modified pages are actually recrawled shortly thereafter.

Second verification: analyze server logs. Compare the crawl frequency before and after correcting the sitemap. If Googlebot focuses its resources on the URLs whose lastmod has changed, that's a good sign. If the crawl pattern remains unchanged, either the engine has not yet regained trust in the signal, or other factors (crawl budget saturated, low-quality content) limit the impact of the correction.

• Audit the sitemap generator to ensure <lastmod> accurately reflects post_modified or updated_at from the database
• Disable or correct scripts that systematically overwrite dates with date() or today’s date
• Exclude pages that never change from the sitemap, or inject their true initial publication date without artificially modifying it
• Submit the corrected sitemap via Search Console and monitor the crawl rate of recently updated URLs in the logs
• Do not trigger lastmod updates for cosmetic modifications (footer, sidebar, common meta tags)
• Segment sitemaps by content type or update frequency if the site mixes static pages with high-frequency news feeds