Sitemap lastmod Date Format: What Google Actually Checks

The short answer to sitemap lastmod date format fits on one line: W3C Datetime, and you are allowed to drop the time and write YYYY-MM-DD. I had that part right in ops/build-site.py from the first build. Then I audited the file it generates and found 60 URLs claiming they were last modified before they existed.

Format is the half of this question that has a documented answer. The half that decides whether the tag does anything is accuracy, and my file failed that half in two separate ways.

What the format actually permits

The sitemaps.org protocol makes <lastmod> optional and says the value "should be in W3C Datetime format. This format allows you to omit the time portion, if desired, and use YYYY-MM-DD." So all three of these are valid:

<lastmod>2026-08-16</lastmod>
<lastmod>2026-08-16T04:37:33Z</lastmod>
<lastmod>2026-08-16T13:37:33+09:00</lastmod>

The trap is in between. A date alone is fine, and a date with a time is fine, but a date with a time and no timezone designator is not. That is the shape most naive serializers produce, and it is what Google Search Console rejects with "An invalid date was found. Please fix the date or formatting before resubmitting" — the exact error reported in SimpleMvcSitemap issue #16, where a .NET DateTime was written straight to XML. The same question recurs in Adobe AEM community threads, where Calendar output lands in the same timezone-less shape.

The other thing to know about the date-only form: it resolves to midnight UTC. That sounds harmless. It was not harmless for me, and I will come back to it.

What is actually in production

Documentation tells you what is permitted. It does not tell you what real generators emit, so I collected that. On 2026-08-16 I fetched the sitemap of 14 sites, chosen as the documentation sites of the tools that generate sitemaps, plus a few large doc sites as controls. Three URLs I guessed were wrong and returned 404 (Gatsby, SvelteKit, Eleventy), and MDN's first child sitemap is gzipped so my parser read zero URLs from it. That leaves 11 usable files. Where a site served a sitemap index, I fetched only its first child, so those rows describe one child rather than the whole site.

Nine of the eleven ship lastmod, and they split across all three valid forms: date-only twice, UTC-with-Z four times, numeric-offset three times. Not one invalid value turned up. The timezone-less bug that fills the support threads did not appear in a single production file I read, which suggests it is a bug people hit while building a generator rather than one that survives into a shipped one.

Two sites omit lastmod entirely, and Supabase omits it while emitting changefreq and priority 830 times each. That combination is inverted: Google's documentation states plainly that it "ignores <priority> and <changefreq> values," so that file carries 1,660 elements Google discards and none of the one it reads.

Accuracy is the gate, and it is measurable from outside

On the tag it does read, Google is conditional: it "uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate." Bing published the failure mode in February 2023, saying the date on most XML sitemaps was set to the generation time of the sitemap rather than the modification time of the content, and that "if we observe that the dates are consistently set to the current date, we will suspect the validity of those dates and may disregard them."

The distinct-value column above is a cheap test for that, and it is my own metric rather than anything either search engine publishes. Count unique lastmod values against URL count. Yoast returns 940 distinct values across 940 URLs and preserves dates from 2018, which is what per-page truth looks like. Next.js returns 43 distinct values across 721 URLs and its samples share an identical millisecond, 2026-08-05T14:49:04.831Z; Nuxt's values all end in T00:00:00.000Z, a date padded out to a time that was never measured. A low ratio does not prove the dates are wrong, but it does show the timestamp is coming from the build rather than the page.

Auditing my own file

My sitemap has 153 URLs: 147 posts plus six static pages. It scores 16 distinct values, a ratio close to the build-stamped end of that table, so I went looking for why.

The first cause is four lines of my own code. In build-site.py:201 I compute newest = max(p["updated"] for p in posts) and then, at line 204, apply that single value to /, /blog/, /mmm/, /about, /contact and /privacy. My privacy policy has not been edited in weeks, yet the committed sitemap shows its lastmod walking forward with the blog: 2026-07-29 in commit 6605e68, 2026-08-08 in d8ce2cc, 2026-08-15 in 6fc2991. Six URLs announce a fresh modification every time an unrelated post goes out, which is the precise pattern Bing described.

The second cause is the date-only format meeting a timezone. My content_updated_on column holds a KST date, and a date-only lastmod resolves to midnight UTC. KST is UTC+9, so any post published after 09:00 local time gets a timestamp that lands earlier in absolute time than the moment the page went live. Of the 66 posts I have never edited since publishing, 60 carry a lastmod that resolves before their own publication. The worst is the post where I measured my internal link graph, published at 2026-07-31 12:20:00+00:00 with a lastmod resolving to 2026-07-31 00:00:00+00:00, 12.3 hours early.

The one I expected to fail, which passed

I went into this audit assuming my worst offence was somewhere else. My publishing checklist requires a backlink pass on every new post, inserting a link or two into older articles, and each of those edits bumps content_updated_on. That has happened to 81 of 147 posts, or 55.1%, with lags running from 1 to 21 days. Inflating a modification date because I added one line of markup looked indefensible.

Google's own wording says otherwise: "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." Links are named explicitly. The 81 bumps are the one part of my sitemap that was reporting the truth, and the two things I had never questioned were the broken ones.

What I am changing

Neither defect is fixed as I publish this. The repairs are small and queued: give the six static pages their own modification dates instead of borrowing the newest post's, and emit full YYYY-MM-DDThh:mm:ss+09:00 values from the publication timestamp I already store, which removes the midnight-UTC interpretation entirely. Omitting the tag is the other defensible option, the one Astro and Supabase take, since it is optional and a distrusted date is worth no more than an absent one.

If you only take one thing from the format question: the format is easy and almost everyone gets it right, while the accuracy is invisible and I got it wrong twice in a file I generate myself. Count your distinct values before you tune anything else. I have written about the last time a UTC-versus-local date bug bit this same pipeline, about pushing URLs through IndexNow instead of waiting on a crawl, and about a crawl directive I found attached to files I never configured.

Sources for this post: the sitemaps.org protocol, Google's sitemap documentation and Bing's 2023 lastmod post, all quoted inline. The survey table comes from one GET per sitemap on 2026-08-16 using a one-off script, 11 files usable out of 14 attempted, first child only for sitemap indexes, and every one of those files will have changed by the time you read this. The numbers about my own site come from 147 rows in the Supabase table behind this blog, the live sitemap.xml, ops/build-site.py, and the git history of the committed sitemap. The distinct-value ratio is my own heuristic and not a published search-engine signal. I have no crawl or ranking data to show what these defects cost: Search Console has returned ACCESS_TOKEN_SCOPE_INSUFFICIENT for three weeks and my Cloudflare token is denied zone analytics, so this post claims only what the specifications say and what my file contains.