Sitemap lastmod: How to Use It So Google Trusts It

Of the three optional sitemap tags, Google uses exactly one. Its documentation says it ignores <priority> and <changefreq>, and uses <lastmod> only if the value is consistently and verifiably accurate. So the job is simple to describe: emit a lastmod that reflects the last meaningful change to each page, in the correct format, or do not emit one at all.

What each tag is worth

Tag	Google	Bing	Recommendation
<loc>	Required	Required	Absolute canonical URL
<lastmod>	Used if consistently accurate	Used, and Bing has publicly encouraged sites to set it correctly	Include when you can make it truthful
<changefreq>	Ignored	Low value	Omit
<priority>	Ignored	Low value	Omit

Removing priority and changefreq also shrinks the file noticeably on large sites. There is no downside.

Why "consistently accurate" is the whole point

Google can check your lastmod. It crawls a page, stores what it found, and the next time it crawls it can compare. If your sitemap claimed the page changed on Tuesday and the content is byte for byte what it was last month, that is a false signal. Enough false signals and the field is disregarded for your site. Google's Gary Illyes has described the evaluation as roughly binary: either the site's lastmod values are trusted or they are not.

This is why the most common implementation is also the worst one: the sitemap is regenerated every night and every URL gets the generation time as its lastmod. To Google, a site where all 40,000 pages "changed" at 03:00 every day is a site whose lastmod means nothing.

When the values are trusted, they are useful in a specific way. Google has to decide how often to revisit each known URL. A reliable lastmod lets it skip pages that have not changed and get to the ones that have sooner. On a site with a few hundred pages the effect is modest. On a site with hundreds of thousands, it is one of the few direct inputs you have into recrawl scheduling, which is why Google lists an up to date sitemap with lastmod among its crawl budget recommendations.

The correct format

lastmod uses W3C Datetime, a profile of ISO 8601. Valid forms:

<lastmod>2026-08-27</lastmod>
<lastmod>2026-08-27T14:05+00:00</lastmod>
<lastmod>2026-08-27T14:05:09+02:00</lastmod>
<lastmod>2026-08-27T12:05:09Z</lastmod>

Invalid forms that show up in real sitemaps:

<lastmod>27/08/2026</lastmod>            <!-- wrong order and separators -->
<lastmod>2026-08-27 14:05:09</lastmod>   <!-- space, no T, no timezone -->
<lastmod>2026-08-27T14:05:09</lastmod>   <!-- time without timezone -->
<lastmod>1787839509</lastmod>            <!-- Unix timestamp -->
<lastmod>0000-00-00</lastmod>            <!-- null date from the database -->

If you include a time, you must include a timezone designator (Z or an offset). If you are not sure your application stores timezones correctly, use the date only form. A correct date beats a wrong timestamp.

Two more format checks: the date should not be in the future, and it should not be earlier than the page's publication. Both are signs of a bug, and both undermine trust in the field.

What counts as a modification

Google's guidance is that lastmod should reflect the last significant update to the page, and it gives examples: changes to the main content, the structured data or the links on the page count. Updating the copyright date in the footer does not.

A practical way to decide:

Change	Update lastmod?
Rewrote or extended the article body	Yes
Price, stock status or specs changed on a product page	Yes
New reviews or comments that are part of the indexable content	Yes, within reason
Structured data added or corrected	Yes
Title or meta description rewritten	Yes
Typo fixed	No
Sitewide header, footer or sidebar changed	No
Template redesign with identical content	No
Cache cleared, page re-rendered, deployment happened	No
Related products widget rotated	No

The template case deserves attention. After a redesign, many CMSs touch the updated_at field on every record, or the sitemap uses the deployment date. Every URL then claims a change on the same day. If you know a bulk operation is coming, make sure it does not write to the field your sitemap reads.

Where the date should come from

The reliable source is a dedicated "content last changed" timestamp that your application sets only when fields that affect the rendered main content are saved. Many systems do not have one, so here is how the usual sources compare.

Database updated_at. Good if it only changes on real edits. Bad if background jobs touch it: view counters, sync tasks, re-indexing scripts. Check by querying how many rows were updated in the last 24 hours and asking whether that number is plausible.

SELECT COUNT(*) FROM posts WHERE updated_at > NOW() - INTERVAL 1 DAY;

If the answer is "all of them", you have found the problem.

File modification time (static sites). Breaks on most build pipelines, because a fresh checkout or build gives every file the same mtime. Use the last Git commit date for the content file instead:

git log -1 --format=%cI -- content/blog/my-post.md

Hugo exposes this as .Lastmod when enableGitInfo is on. Other static generators have equivalent options or plugins. Make sure your CI does a full clone (not a shallow one), or every file will share the date of the latest commit.

WordPress. Core sitemaps and the major SEO plugins use post_modified_gmt, which changes whenever the post is saved. That is normally close enough. Watch for bulk edit plugins and import tools that re-save every post.

Pages assembled from many records. A category page changes when its product list changes. A sensible lastmod is the most recent of: the category's own edit date and the newest date a product was added to or removed from it. Do not use the newest updated_at of all products in it if prices tick every hour, or the page will claim to change constantly.

When you cannot get a truthful value. Omit the tag. This is a legitimate, documented choice. No lastmod is a neutral signal, and it is far better than a wrong one.

lastmod in sitemap index files

In a sitemap index, <lastmod> on a <sitemap> entry means the time that child file last changed. Set it to the newest lastmod among the URLs in that child, or the file's real generation time if its content changed. If child membership is stable (URLs do not shuffle between files), this tells crawlers which files are worth re-fetching. The details are in sitemap index files for large sites.

How to audit your current values

1. Fetch your sitemap and look at the distribution of dates. The XML Sitemap Validator reports lastmod presence and format problems, and the Sitemap URL Extractor exports URLs with their dates to CSV so you can sort and count.
2. Red flags: every URL has the same date, every date is today, dates in the future, dates of 1970-01-01, or a time without a timezone.
3. Pick five pages you know you have not touched in months and five you edited recently. Check that the sitemap agrees.
4. Fetch the sitemap on two consecutive days and compare. URLs whose lastmod changed should be URLs someone actually edited.

A quick command line version of step 2:

curl -s https://www.example.com/sitemap.xml \
  | grep -o '<lastmod>[^<]*' | cut -c10-19 | sort | uniq -c | sort -rn | head

This prints how many URLs share each date. A healthy site shows a long spread. A broken one shows a single line.

Related signals to keep consistent

lastmod is not the only date Google sees. Keep these in agreement:

• The visible "Updated on" date on the page.
• dateModified in Article structured data.
• The Last-Modified HTTP header, if you send one. Supporting If-Modified-Since and returning 304 Not Modified for unchanged pages also saves crawl resources, as described in the HTTP status codes guide.

Do not bump visible dates without changing content to appear fresh. It is the same false signal in a different place, and readers notice as well.

If you fix it, how long until it helps?

There is no documented timeline. Trust is rebuilt as Google recrawls pages and finds that your dates now match reality, so expect it to take weeks at the pace Google crawls your site, not days. The fix is still worth making, because lastmod is also what other systems rely on. IndexNow submissions, internal monitoring and tools such as TurboIndex use sitemap lastmod changes to decide which URLs are worth resubmitting, and a truthful value means only changed pages get sent.

The short version: delete priority and changefreq, make lastmod truthful or remove it, and check the date distribution after every major deployment.