# Sitemap lastmod: my site sets it for every page, and it matched the last significant edit on 1 of 92 updated articles > Google uses sitemap lastmod if it is consistently accurate. My site sets it per page, and it matched the last significant edit on 1 of 92 edited articles. Canonical: https://brandonlazovic.dev/articles/sitemap-lastmod-honest/ Author: Brandon Lazovic Published: 2026-10-28 ## The short version - Sitemap lastmod is the date that tells a search engine when a page last changed, and Google says it uses that date if it is consistently and verifiably accurate. - This site sets lastmod for every article, from an update field nobody filled in, so it fell back to the publish date. It matched the last significant edit on 1 of 92 articles edited after going live. - Most of the gap came from one site-wide heading pass, but with sweeps and small edits set aside, lastmod still lagged the last significant edit on 42 of 46 articles. - A per-page lastmod stays honest only when the same edit that changes the page also changes the date, and when the page's own updated date and the sitemap read the same field. Sitemap lastmod is the date in a sitemap that tells a search engine when a page last changed, and Google says it uses that date if it is "consistently and verifiably" accurate. [1] My site sets lastmod for every article, which sounds like enough. It isn't. The date comes from an update field I never filled in, so every article falls back to its publish date. Of the 92 articles I edited after they went live, lastmod matched the last significant edit on one. A sitemap that never moves its dates reports no change, on a site where nearly every page has changed. > On this site, sitemap lastmod matched the date of the last significant edit on 1 of the 92 articles edited after going live, and was earlier than it on the other 91. ## What is lastmod in a sitemap? Lastmod is the optional date attached to each address in an XML sitemap, the file a site publishes to list the pages it wants search engines to find. The sitemaps protocol defines it as "The date of last modification of the page," and adds that "the date must be set to the date the linked page was last modified, not when the sitemap is generated." [2] Lastmod is the only date in a sitemap entry. Google says it "ignores `` and `` values," the two other optional fields that sound as if they would matter. [1] ## How does Google use sitemap lastmod? Google uses sitemap lastmod when the date is accurate in a way Google can confirm. Its sitemap documentation says "Google uses the `` value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate." The example Google gives of verifying is comparing the date with the page's own last change. [1] Google also defines which changes should move the date. "The `` value should reflect the date and time of the last significant update to the page. For example, 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." [1] Think of the inspection card in an elevator. If the date on it never changed after installation, a rider would learn nothing from it about when the elevator was last looked at. ## How accurate is sitemap lastmod on this site? Sitemap lastmod on this site matched the last significant edit on 1 of 92 articles edited after going live, measured on October 26, 2026. The other 91 showed an earlier date than the last significant change. None showed a later one, because nothing on the site can push the date forward. The site had 101 live articles that day. [3] The gap is large. The median article's lastmod sat 53.5 days behind its last significant edit, across the 92 edited articles. [3] The table below gives the count twice, once under Google's definition of a significant change and once with small edits and site-wide passes set aside. | Rule for a significant edit | Live articles | Edited after going live | lastmod matches | lastmod earlier | lastmod later | |---|---|---|---|---|---| | Any change to the body, or to a field that shows on the page | 101 | 92 | 1 | 91 | 0 | | Body changes of 20 words or more, ignoring edits that touched 10 or more articles at once | 101 | 46 | 4 | 42 | 0 | Most of the gap is one day's work. On 82 of the 92 articles, the last significant edit was a single pass on October 13 that rewrote the headings across 88 live articles. [3] Headings are main content under Google's definition, so that pass counts. But a reader who would not count it can read the second row, where that pass and every other site-wide sweep are set aside and lastmod still trails on 42 of 46. ## Why does a lastmod set for every page still go wrong? A lastmod set for every page goes wrong when the date comes from a field that only changes if someone remembers to change it. This site's build sets each article's lastmod from an "updated" date if the article has one, and from its publish date otherwise. [3] On October 26, no article had the updated date filled in. So every lastmod was a publish date, however much the page had changed since. That same rule explains why the count found no overstated dates. A lastmod bumped for a typo would overstate change, but on this site nothing bumps it at all, so it can only understate. [3] A second date on the page made the gap visible on one article. The article on [ChatGPT clicks arriving as direct traffic](/articles/chatgpt-clicks-arrive-as-direct/) was rewritten the day after it went live, and its byline and structured data say "Updated" with the new date. The sitemap still gives its publish date, because the list of revisions that feeds the byline is a separate field the sitemap never reads. [3] The page and the sitemap disagree about when the page changed. ## How did I count the edits? I counted edits from the git history of each article file, the record of every saved change to the site's source, and compared them with the lastmod in the built sitemap on October 26, 2026. [3] An edit counted as after going live when it was made later than 05:00 UTC (Coordinated Universal Time) on the publish date, when articles go live, and the commit that first added the article never counted as an edit. A change counted as significant if it altered at least one line of the article body, or a field that shows on the page or in its structured data, such as the title, description or source list. Changes only to fields that never render, such as the search title or the publish date itself, did not count. I kept the latest significant change per article and compared its date with lastmod, by day. I wrote the rule for a failed claim before counting. If lastmod had matched the last significant edit on 90% or more of the edited articles, the claim that it understates would have failed, and fewer than ten edited articles would have been too few to say anything. I checked one article by hand against its raw history, and it matched. Git history stands in for when the page changed, since a change is saved first and the site deploys minutes later, so the comparison is by day and not by hour. And this is one site of about 100 articles built from one configuration, so it describes how this site sets lastmod, not sitemaps in general. ## How do you keep sitemap lastmod honest? To keep sitemap lastmod honest, make the date change in the same edit that changes the page, and have the sitemap read the same date the page shows as "Updated." A lastmod that depends on someone remembering a second field will fall behind, as this site's did on 91 of 92 edited articles. [3] Three habits cover most of it. Use Google's sentence as the rule for what moves the date, so a heading rewrite or a new link counts and a copyright year does not. [1] Drive the page's visible updated date, its structured data and the sitemap from one field, so they cannot disagree. And now and then compare the sitemap's dates with the real change history of a few pages, the comparison Google names as its example of verifying. [1] The same comparison is worth running on the address list itself. The rule that keeps this site's error page out of the sitemap matches any address containing "/404," so it also drops the live article on [404 versus 410 status codes](/articles/404-vs-410-google/). [3] To list the addresses and dates in your own sitemap, the [sitemap URL extractor](/tools/sitemap-url-extractor/) reads them out. When a sitemap fails to load in Search Console at all, that is a different problem, covered in [the article on "Couldn't fetch"](/articles/sitemap-couldnt-fetch-quality/). ## Sources 1. Google Search Central: Build and submit a sitemap (last updated 2026-07-08) — https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap 2. sitemaps.org: Sitemaps XML format — https://www.sitemaps.org/protocol.html 3. First-hand: brandonlazovic.dev built sitemap (dist/sitemap-articles-0.xml), astro.config.mjs and the git history of each article file, 101 live articles, measured 2026-10-26