Nearly all sitemap URLs share the same modification date

The check counts how many sitemap URLs give the same calendar day in <lastmod>. A finding is raised when at least 95% of URLs with a valid date share it (min_same_day_share: 0.95 in config/seo.json) and there are at least 20 such URLs (min_urls_with_lastmod). The report gives that day, the number of URLs and how many sitemap files we read.

The day is taken as written, without converting the time zone. Different times on the same day (a build that took a few minutes) count as one day.

The threshold comes from measurement, not from a desk. On 26 real sites (15 Sep 2026), sites with dates from git or from a content management system had their most common day on 0.4–60% of URLs. The highest legitimate-looking value was 89%, a Shopify store where a product's date moves with every stock sync. A sitemap filling in today's date came out at 100%. The 95% threshold sits above the highest legitimate value.

When /sitemap.xml is an index (WordPress, Shopify, large sites), we read at most five nested files; when there is no sitemap there at all, we take the files from the Sitemap: lines in robots.txt. .xml.gz files are unpacked.

What the check does not do:

• It does not tell whether the content really changed. It is a heuristic: a new site where all pages were created on the same day looks exactly like a sitemap carrying the build date. The finding text says so.
• It does not count a Google News sitemap (<news:news>): by definition it only holds articles from the last two days, so a shared date is normal there.
• It does not read the whole sitemap of a large site: only the first five files. The report says how many of how many.
• It ignores <priority> and <changefreq>. Google says it ignores them, so a finding would say nothing.
• It never runs below 20 dated URLs: a small site with three pages changed on the same day may legitimately look like this.

The finding is site-level and informational: it costs no score at all, just like a missing <lastmod> in SEO-07. The only documented consequence of an inaccurate date is that Google may stop taking it into account, which is the same state as having no <lastmod>.

For visibility in AI answers we have no documented effect, same as SEO-07 and ACC-06. No operator of a language model declares reading <lastmod>.

For classic search Google describes it in its own words: “Google uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate.” The date should reflect the last significant update of the main content, structured data or links, not, say, the year in the footer.

The sitemaps.org protocol puts it even more bluntly: the date must be set to the date the linked page was last modified, “not when the sitemap is generated”.

That also sets the limit of what we may claim: Google may ignore an inaccurate <lastmod>. That it will, or how quickly, the documentation does not say, and we do not know.

Find where the sitemap generator takes the date from. Typical causes: new Date() in the generator (a Next.js sitemap.ts, a custom script), the build time of a static site, the last deployment date, or a “modified” field that every bulk save moves.

• <lastmod> = the date of the page's last significant update, ideally from the same source as the content (the CMS, git history).
• When you do not know the real date, leave <lastmod> out. A missing value is more honest than an invented one and costs the same.
• A new site where everything really was created on the same day can ignore the finding; the dates will diverge with further edits.
• Do not touch <priority> and <changefreq> because of this, Google does not use them.