XML sitemaps: one identical lastmod on every URL makes your sitemap useless

An XML sitemap tells search engines which URLs exist, and which ones have changed. Almost every CMS handles the first job. A good share of them fail the second, and fail it invisibly: the file is valid, Search Console reads it without error, and yet it no longer carries any information about what moved. The cause sits in a single field, lastmod, and in how it gets filled.

What Google actually does with lastmod

Google's position is written plainly in its documentation on building a sitemap: the lastmod value is used "if it is consistently and verifiably accurate", for instance by comparing it against the page's real last modification. Google adds that the priority and changefreq fields are ignored. Of the format's three optional fields, one counts, and only when it tells the truth.

From the engine's side, the arithmetic runs like this. A robot has a crawl budget capped per site. When it rereads a sitemap, it compares the announced dates against the ones it has stored. A URL whose date has moved forward deserves another visit; a URL whose date has not can wait. If every date moves forward together at each reading, the engine can no longer tell a genuinely updated page from an untouched one. It ends up distrusting the field and falls back on its own heuristics, which are generally slower.

The typical defect: the build date

Many static site generators, and a fair number of CMSs, write the date the site was regenerated into lastmod. On a site published daily, every URL then carries today's date, including three-year-old articles nobody has touched. The sitemap permanently announces that everything has changed.

We checked this defect on several production sites over the summer of 2026, across more than three hundred URLs in total: in each case, a single lastmod value for the whole sitemap, equal to the time of the last build. None of these sites sent a Last-Modified HTTP header or an ETag on its pages, and none answered robots' conditional requests. The engine therefore had no way of knowing what to reload.

Diagnosis in three checks

The check takes a few minutes, with nothing more than a terminal.

1. Count the distinct lastmod values. Fetch the sitemap, extract the lastmod tags and count the unique values. A healthy sitemap on a site of several hundred pages has dozens. A single value, or a handful all dated the same day, is the defect.
2. Compare lastmod against the page. Take an old URL from the sitemap, open the page, and compare the modification date shown in the article, or in its structured data, against the lastmod value. A gap of several months confirms that lastmod does not describe the page.
3. Test the HTTP headers. Request a page with a HEAD request and see whether the server returns Last-Modified or ETag. Then send the same request with If-Modified-Since set to the date you received. A server that answers 304 Not Modified knows how to say a page has not changed; a server that returns 200 every time forces the robot to download everything again.

These three tests need no paid tool. They are among the checks we recommend before any discussion about indexing a media property.

Why it hurts a media property more than a brochure site

A twenty-page brochure site gets fully recrawled whatever happens. A media property that publishes several articles a week and corrects others lives on a reliable freshness signal: it is what lifts an updated article, and what spares the robot from spending its budget on frozen pages. When the signal breaks, two symptoms show up within a few weeks:

• New articles take longer to get indexed, because they are drowned in a sitemap where everything looks new.
• Corrections to older articles are not picked up, because nothing tells a corrected page apart from one a build simply regenerated.

On a media property that also targets generative engines, the problem is paid for twice: the robots of AI search tools, which lean on the same sitemaps, inherit it. Content revised to correct a figure keeps being served in its old version for weeks.

The correction criterion

Fixing the defect means making lastmod carry the date of each page's last editorial change, and nothing else. In practice:

The acceptance criterion is the same as the diagnosis: after the fix, the number of distinct lastmod values has to reflect the media property's real history, and two successive builds with no editorial change have to produce two identical sitemaps. If the sitemap changes while nothing was written, the fix is not done.

The special case of a media property in a subdirectory

When a media property is hosted under a path of the main site, a blog served under /blog/ from another platform for instance, a second difficulty comes in: the robots.txt file that declares the sitemap is only read at the host root. A robots.txt placed in the subdirectory is never consulted, and the Sitemap lines it holds do not exist as far as search engines are concerned, as Google's robots.txt documentation points out. You then have to declare the media property's sitemap in the main site's robots.txt, or submit it directly in Search Console. Google withdrew the option of pinging a sitemap through a plain HTTP request in 2023: with no explicit declaration, a media property on a subpath has no discovery channel at all.

Both defects, uniform lastmod and undiscovered sitemap, get fixed once and for all at the publishing tool level. It is the kind of detail a CMS built for a media property has to settle by construction, because no editorial team will check it by hand at every publication. On the other freshness signals, the revision date on display and structured data, see our article "Freshness: date your content, revise it, and prove it to the engines".