Updating your page does nothing until the freshness signals move with it.

You can rewrite half an article, and to a machine the page looks untouched. Search engines and AI systems do not read your editorial intent. They read a small set of technical signals that say when a page last meaningfully changed, and if those signals stay frozen while your content moves, the update never registers as freshness at all. Worse, if you move the signals without changing anything real, you train the engines to stop trusting them. Freshness is a technical claim you have to make correctly, not a feeling that radiates off a recent edit.

Three signals carry that claim. The dateModified field in your JSON-LD structured data, the <lastmod> value in your XML sitemap, and the visible "updated on" date on the page itself. Google reads all three, cross-checks them against its own record of when it actually saw the page change, and forms a view of how fresh the page really is. When the three agree with each other and with reality, you get credit. When they conflict, or when they claim a freshness the content does not back up, the claim gets discounted.

The line between a real update and a cosmetic one

The mistake most teams make is bumping the date on every save. John Mueller has been explicit that this backfires. His guidance from Google's own writing is that if an article has been substantially changed it can make sense to give it a fresh date, but you should not artificially freshen a story without adding significant information. In a later office-hours session he was more concrete, saying that if you are tweaking the date every time you make a small change like shuffling images, you should skip it and only update the date when you actually make significant changes.

There are two reasons this matters beyond just following the rule. The first is that faking it does not work. Mueller calls date manipulation an old trick that Google already handles, because Google keeps its own history of when each URL was discovered and when its content genuinely changed, so a fresh date stamped on stale content earns nothing. The second reason is the one people miss. Crying wolf with your dates actively damages you. When your sitemap lastmod says today but nothing changed, Google reads that as a buggy or lazy sitemap configuration and starts trusting your lastmod less, which makes it harder for Google to spot your real updates when they happen. The signal only works if you have earned the right to be believed.

Defining substantive in a way your CMS can enforce

The practical problem is that "significant change" is a human judgment, and your CMS fires on every save. We end up writing this logic for clients whose platform stamps a new modified date on every edit, because to Google their typo fixes and their genuine rewrites look identical, so the real updates stop standing out. The fix is to encode the judgment so the date only moves when the change is real. The cleanest approach is to compare the meaningful content of the page before and after an edit and update dateModified only when the difference crosses a threshold you set.

In practice that means hashing or diffing the body content, not the whole page, on save. Strip out the parts that change for cosmetic reasons, navigation, timestamps, related-post widgets, and compare what is left.

// On save, decide whether this edit counts as a real update
function isSubstantiveChange(oldBody, newBody) {
  const normalize = (s) => s.replace(/\s+/g, " ").trim().toLowerCase();
  const a = normalize(oldBody), b = normalize(newBody);
  if (a === b) return false;                 // nothing changed
  const changed = levenshtein(a, b);
  const ratio = changed / Math.max(a.length, 1);
  return ratio > 0.05;                       // >5% of the body changed
}

// Only then move the date
if (isSubstantiveChange(prev.body, next.body)) {
  next.dateModified = new Date().toISOString();
}

Treat the five percent threshold as a starting point and tune it from there. You want a fixed typo or a swapped image to slip under it, while a rewritten section or a fresh block of analysis pushes over it. On a headless stack like Sanity or Contentful, you have the document revision history to compare against, so the same diff runs in a publish webhook before you write the new dateModified. The point is that the date becomes a function of how much the content actually moved, which is exactly the relationship Google is checking for.

Keep the three signals telling the same story

Once the date logic is right, every surface that states a date has to state the same one. The structured data is where machines look first.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Your article title",
  "datePublished": "2026-02-10T09:00:00+07:00",
  "dateModified": "2026-06-25T14:30:00+07:00"
}

That dateModified should match the visible "updated on" line a human reads, and the <lastmod> your sitemap reports for the same URL. All three need to point at one moment, the last time the content genuinely changed, with no daylight between them.

<url>
  <loc>https://example.com/blog/your-article</loc>
  <lastmod>2026-06-25T14:30:00+07:00</lastmod>
</url>

When those three line up and reflect a genuine change, you are sending one coherent signal. When the schema says June, the visible date says February, and the sitemap says today, you are sending noise, and Google resolves noise by trusting its own crawl history instead of you.

The changelog as freshness proof

A visible changelog turns a date claim into evidence. Instead of a bare "updated June 25," a short note saying what changed, "added 2026 pricing data and a new section on edge caching," does three useful things at once. It gives a human a reason to trust the freshness, it gives a crawler verifiable on-page text that corroborates the date, and it builds the kind of transparency that supports E-E-A-T. A page that shows its work on updates reads as genuinely maintained. It is the cheapest freshness signal you can add, and almost no one bothers.

Why AI engines make this matter more

Freshness is a heavier factor for AI answer engines than for classic search, which raises the stakes on getting the signals right. The cross-platform data is stark. ZipTie's analysis found that 76.4% of ChatGPT's top-cited pages were updated within the last 30 days, and that half of Perplexity's citations came from content published in 2025. An engine that strongly prefers recent content is an engine where a correct, current dateModified changes whether you are eligible to be cited.

There is a structural reason to be careful here too. Google has years of crawl history to catch a fake date, but many AI crawlers fetch a page, read its stated dates, and move on without that depth of cross-checking. That makes honest, consistent dates more load-bearing for AI visibility, not less, because the AI system is leaning on the signal you provide. It also makes faking it a short-lived gain at best, since both Google and the AI platforms are getting better at catching content whose claimed freshness the body does not support.

When the date moves only on real change, and every surface reports the same value, a genuine update finally lands as freshness with every system that reads the page. That is the version of freshness that holds up, the kind that is true because the content actually changed.