dateModified is a claim, not a lever. Google reads it, checks it against what actually changed on the page and in your sitemap, and quietly stops trusting sites whose dates move while content doesn't. There is no ranking boost for a fresh timestamp on a stale page. There is a real one for genuinely updated content on queries that want freshness — and the honest pipeline that captures it is about 30 lines of build script.

Where freshness actually matters

Freshness is query-dependent, not a site-wide multiplier. Queries with an implicit "right now" — "best self-hosted photo software", anything with a year in it, version-anchored questions — reward recently updated pages. Timeless queries ("what is a reverse proxy") barely register it. For a directory, that split is convenient: best-of and comparison pages want a real update cadence; definitional content can sit untouched for two years without cost. Spend your freshness budget where the queries spend theirs.

Three dates, one truth

A page's modification date lives in three places: the visible byline, the dateModified field in Article or product schema, and lastmod in the sitemap. Google reads all three, and disagreement is resolved by trusting you less — the SERP date may be dropped entirely, or derived from crawl history instead of anything you declared. The rule is mechanical: all three dates come from one source of truth in the build, or don't show a date at all. And show "Updated" only when something updated; a visible 2026 date on prose that last changed in 2024 is the kind of claim that gets your dates ignored wholesale.

How the lie gets caught

The detection mechanism is unglamorous: crawl diffing. Regenerate 50,000 pages nightly with a fresh lastmod and Googlebot fetches pages whose declared date says "changed yesterday" but whose content diffs identical to last month's fetch. Google's sitemap documentation states it uses lastmod when it is "consistently and verifiably accurate" — the operational reading is that a pattern of false positives gets the field ignored site-wide, at which point your genuinely updated pages lose their recrawl priority along with the fakes. That failure mode and its cousins are covered from the sitemap side in sitemaps past 50,000 URLs.

The hash-and-bump build step

The honest implementation derives dates from content, not from build time. Hash the fields that matter; bump the date only when the hash changes:

import { createHash } from "node:crypto";

// fields that constitute a real change, per record type
const SIGNIFICANT = ["name", "description", "requirements", "specs", "verdict"];

function contentHash(record) {
  const src = JSON.stringify(SIGNIFICANT.map((k) => record[k]));
  return createHash("sha256").update(src).digest("hex").slice(0, 16);
}

// at build time, against the previous build's manifest
const prev = manifest[record.slug];
if (!prev || contentHash(record) !== prev.hash) {
  record.dateModified = buildDate;         // real change: bump
} else {
  record.dateModified = prev.dateModified; // no change: keep the old date
}

The design decision that makes or breaks this: which fields count. Volatile metrics — GitHub stars, download counts, view counters — must be excluded, or every page bumps every build and you've automated the exact lie you were avoiding. On this site, star counts are excluded from the hash; release versions and requirement changes are included, because a new release genuinely changes what the page tells a reader. The manifest of hashes and dates persists between builds as a small JSON artifact, and the same dates flow to the schema described in JSON-LD that moves the needle and to sitemap lastmod — one source of truth, three outputs.

What counts as a substantive update

The test I use: would a reader who saw the old version learn something new? Changed data value, changed verdict, new section — yes, bump. Typo, CSS, rebuilt footer, reworded sentence with identical meaning — no. The grey zone is rewriting for clarity; my rule is bump only if the meaning moved. If you want the update to count with readers as well as crawlers, say what changed — a one-line changelog under the byline ("Updated June 2026: RAM figures re-measured for v1.13") turns a date into evidence.

Verify the loop is working

The feedback instrument is the URL Inspection tool's last-crawl date. Pick ten pages whose data changed in the latest build and check how long the bump-to-recrawl gap runs; on a site whose dates have stayed honest, changed pages here get re-fetched within about a week, while unchanged pages drift out to multi-week ambient recrawl. If your genuinely updated pages are not being picked up faster than your static ones, that gap is the tell that the lastmod trust is gone — and the only repair is months of boringly accurate dates.

The visible date earns clicks, honestly or not at all

SERP dates influence CTR strongly on technical queries — a 2023 date on a "best X" result reads as expired and gets skipped. The tempting response is cosmetic re-dating; the durable one is making the update real. Pages refreshed on a genuine quarterly data cycle carry current dates because they are current, which is the only version of this that survives crawl diffing. Freshness theatre also draws the wrong crowd: date-bumping at scale is a pattern-level signal, exactly the kind that gets templated sites classified as thin.

Bottom line

Wire all three date signals to one content hash and let updates bump dates only when meaning changes. Spend real update effort on the pages whose queries reward it — best-ofs, comparisons, anything versioned — and let evergreen pages wear their honest old dates without embarrassment. dateModified moves rankings exactly as far as the underlying update deserves; the field itself is just the receipt.