Every sitemap lastmod had the same date: deriving modified dates from a content hash

Commit dates made every page look new

The old build set each URL's lastmod to the date of the last git commit that touched the file. That helper, git_date, arrived on October 5 in bdbbe97, a commit that carries an AI coding agent's co-author line. The agent's code measured when a file changed.

It broke on 12ed443, a site-wide pass. Fifty-two HTML files went into one commit, each gaining an RSS <link> in its head, and all 51 sitemap URLs ended up on that day. Re-running today's hash rule (the inside of <main>) over those 52 files, only 2 had real body changes: the SugarDoc app page in Korean and English. 42 had identical bodies. The other 8 differed by a single added line, a "last updated" date. (Counting structured data in the head as well, 11 pages changed their FAQ or feature list.)

Google's sitemap documentation says it uses lastmod only if the value is "consistently and verifiably" accurate, and gives a copyright date update as an example of a change that isn't significant.

The date moves only when the body hash changes

The October 18 restructure, b82faac, moved all page dates into one file, data/content-dates.json. The agent co-wrote that commit too. The new tools/dates.py opens by citing a written spec section for dates (IA spec 4.1). For a hand-written page it hashes the inside of <main> with breadcrumbs and build-generated blocks removed:

def hand_input(page_html):
    inner = main_html(page_html)       # inside <main> only
    inner = _CRUMBS_RE.sub("", inner)  # drop breadcrumbs
    inner = strip_build_blocks(inner)  # drop <!-- build:* --> blocks
    return _WS_RE.sub(" ", inner).strip()

# same hash: keep dates; new hash: modified = today
# new page: published = modified = today

The easy thing to miss is the date itself. In 12ed443 the "last updated" line sat inside <main> as plain HTML. Hash that line and every date change looks like a content change, so the next day's build moves the date again, forever. On hand-written pages the line now lives in a build:meta block. Those 8 app pages became generated pages built from data/apps.json, so their hash covers the input data, not the HTML. A unit test (test_every_marker_block_is_removed) asserts the phrase never reaches the hash input, and test_idempotent_next_day checks that a rerun the next day leaves the dates alone.

Never derive lastmod from commit dates or build dates. Don't let people edit it either: the repository's AGENTS.md says "never edit dates by hand" (how we write that file is in How to write AGENTS.md).

99 files touched, 6 dates moved

Commit b79f2d1 on October 19 touched 99 HTML files, mostly to bump a ?v= cache-busting value on the stylesheet links. Apart from 14 new pages, the modified date moved on 6 existing ones: the home page, the apps hub and the privacy policy list, in Korean and English, each of which now lists the new pages.

IndexNow pings follow the same dates. tools/indexnow.py picks only pages whose modified date is today, and it is a dry run unless you pass --send.

What we check next

The related-notes list (build:extra) is excluded from the hash. Google counts link changes as significant, yet when a new note joins that list, older notes keep their dates. We will decide after reading Search Console's crawl data in November 2026.

FAQ

More AX notes

• Structured data after FAQ rich results ended: what we kept for GEO
• A static site that several AI agent sessions edit: one --check gate before every commit
• Privacy policy AI processing location (cross-border transfer): a notice fixed twice in one day, then tied to code
• Pre-gzipping Android assets, measured: zero APK savings, and .pack.gz became .pack with a FileNotFoundException
• A market:// link opens a store chooser on SKT-sold Samsung phones: set the Play package first
• A splash that never moved on: addOnCompleteListener(this) and onStop

All notes on Website and search · All AX notes