Sitemap Lastmod: Google Says Drop Inaccurate Dates

Sitemap lastmod hygiene got its bluntest public guidance yet on July 16, 2026, when Google’s Gary Illyes told an SEO whose client site was emitting unintentionally wrong dates that the site is “probably better off without the lastmods. at least you save a few bytes.” The subtext is sharper than the joke: Google either trusts your lastmod values or it ignores them wholesale — and inaccurate dates are how you land on the wrong side of that line.

The stakes are quiet but real. For large archives, an accurate lastmod is one of the few levers that tells crawlers which of your thousands of URLs actually changed — and a corrupted one can mean refreshed content waits longer to be recrawled while the crawler re-verifies everything on its own schedule. The failure is silent: no Search Console error, no warning, just a signal that stops being believed.

This playbook covers what Illyes actually said and why it is a restatement rather than a reversal, what the lastmod tag formally promises per the sitemaps.org protocol and Google’s documentation, the three most common ways CMS and build pipelines corrupt the signal, a keep / fix / omit decision matrix you can run against your own sitemap this week, and how we implement modifiedTime-driven lastmod on Digital Applied’s own production sitemap — including where our implementation honestly falls short.

The exchange started with a practitioner’s genuinely hard question. SEO Jason Kilgore had found a bug on a client site producing wrong modification dates at scale, and asked Google directly: “Would a site be better off with no lastmod date at all on any pages? Or one where the lastmod date isn’t reliable/trusted (given the binary nature of Google’s trust on this)? We found a bug manifesting a set of unintentionally incorrect dates.”

Illyes’ answer, posted at 07:59 UTC on July 16, took a position most SEOs hedge on: if the dates are wrong, remove the tag. Search Engine Roundtable’s Barry Schwartz covered the exchange the same morning and compressed it to a single editorial line: “In short, use the lastmod date correctly and don’t try to trick Google.”

Note what the question presupposed — Kilgore already described Google’s trust as binary in his own framing, and Illyes did not correct him. That matters because it is the practical rule the rest of this playbook is built on: there is no partially trusted lastmod. Either your dates hold up when Google checks them against the pages, or the entire column of dates in your sitemap becomes decoration.

The July 2026 reply reads as news, but it is better understood as the latest data point on a line Google has been drawing for roughly a decade. Search Engine Roundtable’s own coverage links the new statement back through years of consistent Illyes and John Mueller commentary on the same tag.

The 2024 thread also pointed at a plausible mechanism. Commentary around the Google Search API leak that year suggested Google appears to store a last-significant-update timestamp per URL internally — the reference point a sitemap’s claimed date would be compared against. We have not independently verified that finding, but it is consistent with what the documentation says out loud: Google verifies lastmod against its own observation of the page, and your tag either keeps agreeing with reality or stops being used.

Read as a trend, the direction is one-way. Each public statement since 2017 has narrowed the tag’s job description — from “we may use it” to “we use it if verifiably accurate” to “if yours is wrong, delete it.” Our projection: expect zero future tolerance for approximately-right dates, and expect the same verification logic to matter more as AI crawlers and answer engines lean on freshness metadata when choosing what to re-fetch and cite. Clean lastmod is cheap insurance for both audiences.

Most lastmod bugs are really contract misunderstandings. The tag makes a narrow, formal promise defined by two documents — the sitemaps.org protocol (the shared open standard that Google, Bing, and other engines consume) and Google’s Search Central documentation layered on top. Four clauses do most of the work:

• It is optional. Google’s docs are explicit that the tag is not required and its inclusion is not mandated. Omitting it is a fully supported, spec-compliant state — which is exactly why “drop it” is viable advice rather than damage.
• It dates the page, not the sitemap. Per sitemaps.org, the value “must be set to the date the linked page was last modified, not when the sitemap is generated” — in W3C Datetime format, with YYYY-MM-DD as the minimum precision. Build-time stamping violates the spec’s core sentence.
• Only significant updates count. Google defines the legitimate trigger as the last significant update — changes to main content, structured data, or links. Routine touches like a copyright-year bump are explicitly excluded.
• It is separate from HTTP freshness. The protocol notes lastmod is distinct from the If-Modified-Since / 304 mechanism, and engines may use the two sources differently. A correct 304 setup does not excuse a wrong lastmod, or vice versa.

One more clause trips up even careful implementations: in a sitemap index file, lastmod means something different. There it marks when the referenced sitemap file itself last changed — not when any of the pages inside it did. Pipelines that copy page-level logic into index files end up lying at a second level without anyone noticing.

Almost nobody sets out to fake lastmod. The dates go wrong as a side effect of how content systems store timestamps — which is precisely the kind of bug Kilgore described finding, and the kind Google’s significant-update definition is written to police. Three patterns account for most of the damage we see in technical SEO audits:

The common thread: each failure mode produces dates that are locally defensible — some system really did write to that record at that time — and globally false as a description of when content meaningfully changed. That gap is exactly what Google’s verification closes. When the crawler fetches a page whose sitemap claims yesterday and finds content it has seen unchanged for months, the sitemap loses the argument. Do that consistently and, per the binary model, the whole file’s dates stop being consulted.

Related warning from the other direction: Mueller has separately cautioned that manually bumping lastmod is not an SEO hack. Touching the date without a real content change does not earn a recrawl boost — it just spends trust you will want later.

Trade coverage of the Illyes reply mostly stops at the quote. The useful next step is an audit: identify which pattern actually generates your lastmod values, then apply keep / fix / omit. The matrix below maps the common patterns against the two trust killers — trivial-edit re-stamping and timezone or format risk — with a recommended action for each. Fold it into a full 50-point crawl audit if you are reviewing the whole crawl surface at once.

Two audit checks make the matrix actionable in under an hour. First, diff a sample: pull twenty URLs from your sitemap, open each page’s actual revision history, and see whether the claimed lastmod matches a significant content change. Second, look for the uniform-date tell — if hundreds of URLs share one recent timestamp, a build stamp or bulk operation wrote it, not your editors. Teams that want the exhaustive version can work through a deeper 200-item technical checklist where sitemap hygiene sits alongside the rest of the crawl-layer items.

Rather than describe a hypothetical implementation, here is the one this page is served by. Digital Applied’s production sitemap generator (app/sitemap.ts in our Next.js codebase) drives blog-post lastmod from editorial metadata, not from file or build timestamps. Each post’s entry resolves its date as new Date(post.modifiedTime || post.publishedTime) — the code comment above it reads “Blog pages — modifiedTime first so content refreshes reach crawlers.” A post’s date moves only when we deliberately update its modifiedTime after a significant revision, which is the exact trigger Google’s documentation defines.

The same file derives each category hub’s lastmod from the newest post in that category — computed from every post’s modifiedTime or publishedTime — so hub pages advertise freshness only when a post inside them actually changed, rather than carrying a static build timestamp.

And the honest caveat: our static marketing pages (home, about, services) currently share a single build-time date rather than per-page edit tracking. That is the build-stamping pattern from the matrix above. It is low-stakes for a few dozen slow-changing pages that do not depend on lastmod-driven recrawl priority — but it would be exactly the wrong pattern for the 1,700-plus-post blog archive, which is why the blog side is wired differently. Knowing which of your page classes can tolerate the lazy pattern, and which cannot, is most of the judgment in this topic.

Illyes’ one-liner compresses into a rule you can actually run: omission is the correct state whenever your pipeline cannot tell the truth yet. Because the tag is optional, removing it costs nothing but the bytes — Google falls back to its own crawl scheduling, the same thing it does when it distrusts your dates anyway, minus the credibility damage. Here is the full decision tree:

One caution before you expect miracles from the fix: lastmod influences crawl scheduling, not indexing judgment. If refreshed pages are being crawled but still left out of the index, the bottleneck is content quality signals rather than sitemap plumbing — why Google leaves pages crawled but not indexed is its own diagnosis. Clean lastmod gets Google to the door faster; it does not argue the page’s case once inside. If you want a second set of eyes on the whole crawl-and-index layer, this is core territory for our agentic SEO services, where sitemap hygiene is one item in a continuously monitored technical baseline rather than a one-off cleanup.