Sitemap lastmod: the format and when Google uses or ignores it
Sitemap lastmod uses W3C Datetime, such as 2026-09-28T09:00:00+00:00. Google trusts it only when it is consistently accurate, so set it from real edits.
LLaunchScaler·Published ·8 min read
Sitemap <lastmod> uses W3C Datetime: either a date, 2026-09-28, or a full timestamp with a time zone, 2026-09-28T09:00:00+00:00. Google uses the value only when it is consistently and verifiably accurate, and it ignores <changefreq> and <priority> entirely, so the date has to move when the page really changes and stay put when it does not.
Getting the format right takes a minute. Getting the accuracy right is what decides whether Google reads the field at all.
What is the correct lastmod format?
W3C Datetime, a profile of ISO 8601. The sitemaps protocol says the value "should be in W3C Datetime format," and that "this format allows you to omit the time portion, if desired, and use YYYY-MM-DD." If you include a time, Search Console requires a time zone: "if you do specify a time, you must also specify a time zone."
Form
Example
Valid in a sitemap?
Date only
2026-09-28
Yes
Date, time and offset
2026-09-28T09:00:00+00:00
Yes
Questions, answered
What people ask about this
01
What is the lastmod date format in a sitemap?
W3C Datetime. Use a date alone, such as 2026-09-28, or a full timestamp with a time zone, such as 2026-09-28T09:00:00+00:00. If you include a time, you must include the time zone.
The W3C note defines the pieces: YYYY four-digit year, MM two-digit month, DD two-digit day, hh:mm:ss on a 24-hour clock ("am/pm NOT allowed"), and a time zone designator of Z or +hh:mm or -hh:mm. Search Console's example of valid values is 2005-02-21 and 2005-02-21T18:00:15+00:00.
Bing recommends including the time: its guidance is to use "standard ISO 8601 date formatting for lastmod values, including both the date and time," because a timestamp "provides a more precise signal of when content was updated."
Is lastmod required?
No. The sitemaps protocol marks <lastmod> as optional, and only <loc> is required for each URL. Google says "you can use a lastmod element for all the pages in your sitemap, or just the ones you're confident about," and that for pages whose change date your software cannot tell, such as a homepage or category page that aggregates other pages, "it's fine to leave out lastmod for those pages."
Leaving it out costs you the recrawl signal for that URL. Filling it with dates that are not true costs more, because it can make Google stop trusting the field across your whole sitemap.
When does Google use lastmod, and when does it ignore it?
Google uses it when it is accurate and ignores it when it is not. Its sitemap documentation says Google "uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate." Google checks your dates against what it sees on the page when it crawls, and adjusts how much weight it gives them.
Google's 2023 announcement spelled out the consequence: lastmod "needs to consistently match reality: if your page changed 7 years ago, but you're telling us in the lastmod element that it changed yesterday, eventually we're not going to believe you anymore when it comes to the last modified date of your pages." When it is trusted, Google uses it "as a signal for scheduling crawls to URLs that we previously discovered."
The other two optional tags do nothing for Google. Its documentation: "Google ignores <priority> and <changefreq> values." Its 2023 post adds that changefreq "is also conceptually overlapping with lastmod," and that priority "generally doesn't accurately reflect the actual priority of a page." Bing says the same: changefreq and priority "are ignored by Bing and do not influence how your content is crawled or ranked."
What counts as a change worth a new lastmod?
A change to what the page says or links to. Google defines it as "last significant modification": an update to "the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not." A new footer, a tweak to the sidebar or a rebuilt bundle with identical content is not.
Change
Update lastmod?
Rewrote or added a section of the main text
Yes
Corrected a price, spec or date shown on the page
Yes
Added or changed structured data
Yes
Added or changed links in the content
Yes
Changed the footer, sidebar or copyright year
No
Redeployed the site with no content change
No
Fixed a typo
Your call; Google's bar is "significant"
Two rules follow. Do not set lastmod to the time the sitemap was generated: the sitemaps protocol says "the date must be set to the date the linked page was last modified, not when the sitemap is generated," and Bing's tip is identical. And do not bump every URL on every deploy, which is an easy way for a sitemap to end up with dates Google stops trusting.
Why do AI crawlers care about lastmod?
Because lastmod is the cheapest way for any crawler to find what changed without refetching everything. Bing says so directly for its AI search: "freshness signals directly influence how quickly updates are reflected in search results and AI generated answers," and lastmod "remains a key signal, helping Bing prioritize URLs for recrawling and reindexing, or skip them entirely if the content hasn't changed since the last crawl."
That matters for AI answers, which quote whatever version of your page the crawler last stored. A price you changed last week, or a feature you shipped, reaches those answers only after a recrawl. An accurate lastmod gives crawlers a reason to come back to exactly that page. A missing or frozen lastmod gives them none, so they recrawl on their own schedule. The content freshness and AI citations guide covers the on-page side of freshness.
Should lastmod match the date shown on the page?
Yes. Keep one "last updated" date per page and use it everywhere: the sitemap's <lastmod>, the dateModified in your Article or BlogPosting structured data, and the visible "Last updated" line. Google looks "at several factors to determine our best estimate of when a page was published or significantly updated," so dates that disagree weaken each other.
Google's byline date guidance asks you to "ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values," to label dates clearly with text like "Last updated," and not to "specify future dates." It also recommends giving "a time and timezone in markup for added precision," the same advice Bing gives for lastmod. When all three dates come from the same field in your data, they cannot drift apart.
How do you generate lastmod from the real modified date?
Take it from the same field that records when the content last changed, never from the clock at build or request time. In a CMS that is the post's modified timestamp; in a Next.js sitemap.ts it is whatever updatedAt your data source stores. Build the date once per URL and let it change only when that record changes.
The Next.js docs show lastModified: new Date() in their example, which stamps every URL with the moment the sitemap was generated. Next.js also caches sitemap.js by default, so in practice that date is your last build time, and it changes on every deploy for every page. Replace it with the content's own date:
// app/sitemap.ts
import type { MetadataRoute } from "next";
import { getAllPosts } from "@/lib/posts";
export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
const posts = await getAllPosts();
return posts.map((post) => ({
url: `https://example.com/blog/${post.slug}`,
lastModified: post.updatedAt, // the content's own edit date
}));
}
For pages without a meaningful edit date, such as the homepage or a listing page, leave lastModified out rather than inventing one. Keep updatedAt honest at the source too: if your CMS updates it on every save, including saves that change nothing visible, it will drift from reality the same way.
For a CMS or a plugin that writes the sitemap, check one post: edit only its text, save, and confirm its <lastmod> changed while the other entries stayed the same. Then redeploy without edits and confirm nothing changed.
How do you check your sitemap's lastmod values?
Fetch the sitemap and read the dates. Three things to look for: every value parses as W3C Datetime, the dates differ from page to page, and they match when you actually edited those pages. A sitemap where every entry shows the same timestamp is the clearest sign of a build-time date.
That counts how many URLs share each date. One date shared by every URL means the value is generated, not real. Then open the Sitemaps report in Search Console: an "Invalid date" error lists entries that break the format. Google's troubleshooting guide says to use "the <lastmod> tag in sitemaps to indicate when an indexed URL has been updated" and to avoid resubmitting "the same, unchanged sitemap multiple times per day." The sitemap could not be read guide covers the other errors that report can show.
After a significant update to one important page, you can also ask Google to recrawl it directly; the request indexing guide covers the quota and when that is worth doing. For submitting the file itself, see how to submit a sitemap to Google.
Check your lastmod dates in one pass
To check how your sitemap reads to crawlers, run the free scan on LaunchScaler. Give it the URL, no account needed, and it runs 156 checks across 6 of its 7 categories at no cost. One of its AI visibility checks looks for exactly this: it warns when no sitemap can be found or when the sitemap's lastmod values are missing or static, because crawlers then cannot tell which pages changed. Its search checks also flag a sitemap missing from robots.txt and entries that redirect, return 404 or are noindexed. Fix what it reports, then let Google and Bing pick up the dates on their next sitemap read.
No. It is optional in the sitemaps protocol, and Google says you can use it for all pages or only the ones you are confident about. Leaving it out is better than filling it with dates that are not true.
03
Does Google use sitemap lastmod?
Yes, when it is consistently and verifiably accurate. Google uses it as a signal for scheduling recrawls of URLs it already knows, and says it stops believing a site whose lastmod dates do not match reality.
04
Does Google use changefreq and priority?
No. Google says it ignores the priority and changefreq values, and Bing says the same about both tags. Only loc and lastmod matter to them.
05
When should I update lastmod?
When the page changes in a meaningful way: the main text, the structured data or the links. Google says a copyright date or a sidebar change is not significant, so a deploy that changes nothing on the page should not change its lastmod.
