Findings · 2026-10-14 · By VSNARY | Emmanuel Orta · 0 views

Sitemap lastmod: 103 pages, one date, and why engines skip it

Our sitemap told search engines that 103 pages last changed on 23 September. Most had been rebuilt since. Google and Bing both use lastmod only when it is accurate, and one date on every page is the commonest way to make it inaccurate. What we found, how we dated each page after the fact, and the rule that keeps it right.

A sitemap is a list of a site's pages, and the lastmod date beside each one tells a search engine or AI crawler which pages changed since it last looked. A crawler with limited time per site uses that date to decide what to fetch again. A correct date gets a changed page recrawled sooner. A wrong date either wastes the crawl on pages that did not change or hides the ones that did.

What our sitemap said #

On the morning of 14 October 2026, every standing page in our page sitemap (everything that is not a post) carried the same value: <lastmod>2026-09-23</lastmod>, 103 entries in all. That was the day a theme change touched every page. Since then the homepage, pricing, the API documentation and most of the site had been rebuilt, many of them on 7 October. The sitemap said none of them had changed.

The cause was simple. Posts carry their own publication and update dates, so the blog's entries were right. Every other page took its date from one site-wide value, set when the theme was rebuilt and never moved again. Nothing was broken in the usual sense: the file was valid, every URL answered 200, and the date was a real date. It was just the same answer to 103 different questions.

Why one date on every page is worse than no date #

Google's sitemap documentation says it uses lastmod only when the value is consistently and verifiably accurate, for example when checked against the page's own last modification, and that it should reflect the last significant update to the page. It also says Google ignores the priority and changefreq fields.

Bing measured the problem. In a February 2023 study of sitemaps it knew, 84% set lastmod; of those, 79% had correct values and 18% did not. The most common error was the same date on every URL, often the date the sitemap file was generated rather than the date the page changed, and Bing said dates that always match the current day may be disregarded. In July 2025 Bing called lastmod a key signal for deciding what to recrawl for AI-driven search, as Search Engine Journal reported.

The condition both engines state is consistency. A sitemap that is wrong in a pattern gives an engine a reason to stop trusting its dates, including the ones that are right. That is why fixing the date generator matters more than fixing any single row.

Four ways to date a page, and which one is right #

How we dated 103 pages after the fact #

We had no per-page record, so we built one from our release history. For each page we found the newest release that changed something inside that page's own content: its text, the parts that render it, its title or its description. If no release had touched a page since it was created, its creation date stands. Changes to the shared navigation, the footer or the stylesheet do not count. They change every page at once and say nothing about any one page, which is exactly the signal a lastmod date is meant to carry. A translated page carries the date of the English page it translates.

The same per-page date now feeds the page's own structured data (dateModified on the page's WebPage entry), so the sitemap and the page cannot disagree about when it changed.

Four pages still say 23 September, and that is now correct: nothing on them has changed since. A uniform date is not wrong in itself. It is wrong when it is uniform because nobody looked.

Why no check caught it #

Our own scanner flags a sitemap in which every URL carries the same lastmod, with the finding SITEMAP_NO_LASTMOD. Ours did not trip it: posts carried their own dates, so the file as a whole held many dates, and the uniform ones sat in one part of it. A block of identical dates inside a varied file can be honest (a site whose pages really did launch on the same day), and the file alone cannot tell the difference. Only the pages' own history can, which is why the fix had to come from our release record rather than from the sitemap. The live share of scans where the sitemap carries no usable lastmod at all:

The rule that keeps it right #

One map holds a date per page. A release that changes a page moves that page's entry in the same release; a release that only changes the navigation, footer or styling moves nothing. The sitemap and the page's structured data both read the map. If a page is ever missing from it, it falls back to the last site-wide date rather than to today, so a missing entry makes a page look older, never newer, and never invites a needless recrawl.

Check your own sitemap in two minutes #

1. Count the distinct dates. curl -s https://example.com/sitemap.xml | grep -o '<lastmod>[^<]*' | sort | uniq -c | sort -rn | head. If one value covers most URLs, find out why. If your sitemap is an index, run it on each child file.
2. Compare with today. If every date is today, the sitemap is stamping its own generation time.
3. Test six pages by hand. Pick three you know changed recently and three you know did not, and compare each date with what happened.
4. Check the page agrees. The dateModified in a page's structured data should match its sitemap date.
5. Run the full audit in the XML sitemap guide, or the free scan, which reads every declared sitemap.

Questions this post answers

What is lastmod in a sitemap?

An optional date beside each URL in an XML sitemap, in W3C Datetime format, saying when that page last changed. Search engines and AI crawlers use it to decide which pages to fetch again.

Does Google use the sitemap lastmod date?

Yes, when it is accurate. Google's documentation says it uses lastmod if the value is consistently and verifiably accurate, for example against the page's own last modification. Google ignores the priority and changefreq fields.

Why do search engines ignore some lastmod dates?

Because they are wrong in a pattern. Bing found the most common lastmod error is the same date on every URL, often the time the sitemap was generated, and said dates that always match the current day may be disregarded.

Should lastmod change when I edit the site's footer or navigation?

No. A change that appears on every page at once says nothing about any one page. Lastmod should move when that page's own content changes significantly.

How do I check whether my sitemap lastmod dates are accurate?

Count the distinct dates in the file, check that they are not all today, and compare a few pages you know changed and a few you know did not with their dates. The dateModified in each page's structured data should match its sitemap date.

Does lastmod matter for AI search?

Bing said in July 2025 that lastmod is a key signal for deciding which pages to recrawl for AI-driven search, and recommended accurate dates with a time component.

Related findings

Comments

Comments are read before they appear. Nothing is published automatically, and no account is needed.

Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.

All findings · The dataset · How the dataset works