Sitemap lastmod for Real Export Product Changes: What Timestamp to Emit

An automated sitemap generator that stamps every URL with the build time tells Google the same thing about product pages that genuinely changed and pages that did not. This article separates three clocks — XML generation time, page content modification time, and the moment a search engine next fetches the page — and uses Google’s documented definition of a significant update to decide which value an export catalog should emit. It then wires the generator to the page’s own modification record, keeps the emitted value stable across rebuilds, and closes with a verification loop that does not convert a correct timestamp into a crawl or ranking expectation.

The timestamp your generator writes is not the page’s modification time

A nightly sitemap build and a real product-page edit are two different events, and a generator that writes the build time into every <lastmod> element collapses them into one. The reader’s question — "our sitemap is rebuilt every night and every URL gets today’s date, is that what <lastmod> is for?" — has a documented answer, and it is not the build clock.

Three clocks are in play, and only one of them belongs in the sitemap. The XML generation time is when your build process wrote the file. The page content modification time is when the product page’s own content last changed in a way that matters. The third is when a search engine next fetches the URL — an event you do not control and cannot schedule by editing a timestamp.

Google’s documentation ties the value to the second clock, not the first: the <lastmod> value "should reflect the date and time of the last significant update to the page," with main content, structured data, and links on the page given as generally significant examples and a copyright date update given as not significant.

There is also an accuracy condition attached to whether the value is used at all. Google states it uses the <lastmod> value "if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate."

A build timestamp fails that condition by construction, not by imprecision. If the generator writes today’s date for every URL on every run, then a product page whose specification table was edited this morning and a product page untouched for a year carry the same value. The sitemap no longer distinguishes them, and the comparison Google describes — the emitted value against the page’s actual last modification — cannot come out accurate for both.

The syntax itself is not the problem. A basic XML sitemap entry is a <loc> element plus a <lastmod> element, shown in Google’s own example as <lastmod>2022-06-04</lastmod>. The element is doing exactly what it was designed to do; the value being fed into it is the wrong clock.

For an export catalog this matters more than for a small brochure site, because the catalog is where the real changes happen: a variant goes out of stock, a specification row is corrected, a datasheet link is replaced, a related-product link is added. Those are the events a buyer and a search engine both have a reason to care about, and a nightly build timestamp erases all of them.

Source reference

What counts as a real change on an export product page

Once the build clock is out of the picture, the remaining question is per-page: which edits to this product page justify a new <lastmod> value? Google’s documentation gives the classification directly rather than leaving it to taste. An update to the main content, the structured data, or links on the page is generally considered significant; an update to the copyright date is not.

Translated to an export product page, the significant side of that line includes the specification table when a value, unit, tolerance, or material actually changes; the structured data describing the product when a field such as availability, price range, or identifier changes; and the links on the page when a datasheet, manual, or related-item link is added, replaced, or removed. These are the edits a buyer would notice and act on.

The not-significant side is where most false freshness comes from. A shared footer whose copyright year rolls over, a template component that re-renders identically on every page, a CSS or layout deploy that leaves the product’s own content untouched — none of these is a significant update to the page under the documented definition, and none of them should move the timestamp.

It is worth being explicit about the workaround people reach for next, because it does not exist. Google ignores <priority> and <changefreq> values in XML sitemaps, so neither element can be used to express "this page changes often" or "this page matters more" in place of an honest <lastmod>.

The practical consequence is that the classification has to be made in the content system, not in the sitemap. If your CMS cannot tell a specification-table edit apart from a footer re-render, no amount of sitemap configuration will recover the distinction, because the sitemap only emits what the page record already knows.

Wiring the generator to the page’s own modification record

The mechanism that satisfies the accuracy condition is not a smarter sitemap file; it is a different data source for the value. Google recommends automatic generation for sitemaps with more than a few dozen URLs, suggesting that you extract your site’s URLs from your website’s database and export them to the screen or a file on your web server.

The same database record that holds the product’s content revision is the natural source for <lastmod>. If the product row carries a modification timestamp that is updated when the specification table, structured data, or page links change — and not when a template or footer re-renders — then the sitemap generator can read that field instead of the build clock. The generator’s job becomes formatting and emitting a value it did not invent.

Two properties of the emitted value matter as much as its source. First, it should be stable across rebuilds: an unchanged product page should keep the same date on every run, so that a rebuild does not look like a change. Second, it should be the page’s own date, not a rounded or normalized one, because the comparison Google describes is against the last modification of the page.

The URL set the generator emits is a separate decision from the timestamp, and it has its own documented rule. A sitemap should contain the canonical URLs the site wants shown in search results; where the same content is reachable under different URLs, the preferred URL should be included instead of all the variants that lead to the same content.

For a large export catalog there is also a hard ceiling to plan around: a single sitemap is limited to 50MB uncompressed or 50,000 URLs, and a larger set must be split into multiple sitemaps, optionally combined through a sitemap index file.

One thing the generator does not need to worry about is ordering. The order of URLs in a sitemap does not matter to Google, so a generator can emit records in whatever order the database returns them without affecting how the timestamps are read.

Verifying the emitted dates without assuming a recrawl

Verification here means checking the value against the page, not checking whether anything happened in search afterwards. Google’s accuracy condition is framed as comparison with the last modification of the page, so the check is internal: for a sample of product URLs, compare the emitted <lastmod> against the page’s own recorded modification time and confirm they agree.

The Search Console Sitemaps report is the documented place to see operational signals about the file itself: it shows when Googlebot accessed the sitemap and also potential processing errors. That is a check on whether the sitemap was fetched and parsed, not a statement about whether any individual product page was recrawled or reindexed.

It is worth stating the boundary plainly, because it is the most common place teams over-read the fix. Submitting a sitemap is merely a hint: it does not guarantee that Google will download the sitemap or use it for crawling URLs on the site. A correct <lastmod> is therefore not a recrawl request, and it should not be reported internally as one.

Do not promise a recrawl interval or use an indexing or ranking outcome as the success criterion for updating sitemap dates. The success criterion is narrower and fully checkable: the emitted value matches the page’s real last significant modification, and it stays stable when nothing changed.

If you are still working out whether a specific product URL is in the index at all, that is a different diagnostic with a different starting point; see Google Not Indexing Pages: Diagnose One Exact URL by Index-Status Stage. And if the product page’s visible title is being rewritten in search results while you are auditing the sitemap, that is a separate mechanism again, covered in Google Title Links for Export Product Pages with Long Model Codes.