dateModified that lies is worse than no date. When to bump dates, when to changelog, and how schema should reflect reality.
Your blog footer says "Updated September 12, 2026." The content is identical to last March. An assistant cites your "2026 guide," a reader finds stale screenshots, and trust drops for both of you. A lying dateModified is worse than no date.
Dates, changelogs, and freshness signals help AI when they reflect reality. They hurt when they are a ranking superstition.
What freshness means to machines
Retrieval systems and users both use dates as a relevance filter — especially for pricing, APIs, regulations, and "best tools" lists. Article schema fields like datePublished and dateModified should match visible dates. If they disagree, you taught the machine to distrust you.
| Signal | Use when | Do not use when |
|---|---|---|
datePublished | First public ship | Rewriting history on republish |
dateModified | Substance changed (facts, steps, prices) | Typo fixes, CDN redeploys |
| Visible "Updated" line | Same rule as dateModified | Auto-stamping every page load |
| Changelog entry | Product or doc sets with ongoing changes | One-off opinion essays |
| "2026" in the title | Content actually revised for the year | Cosmetic SEO title swap |
Pew Research (March 2025) observed that clicks on traditional results fall when an AI summary is present (8% with vs 15% without in their study). The citation you do get is often the only visit — stale content behind a fresh date burns that chance.
When to bump a date
Bump dateModified when a reader following old steps would fail: new UI, changed pricing, corrected data, replaced recommendations. Do not bump for:
- Whitespace and lint.
- Internal link swaps that do not change meaning.
- Author bio tweaks on a different URL.
- Purely visual redesigns with the same instructions.
Hypothetical: say you run 20 prompt checks every quarter against your "AI crawler allowlist" guide. If three user-agents changed, update the table, write one changelog line, and then bump the date. If nothing changed, leave the date alone and say so in your editorial calendar.
Changelogs that help citations
A changelog (or "Revision notes" block) gives assistants and humans a quotable delta:
## Revisions
- 2026-07-18: Added PerplexityBot WAF note; removed retired user-agent.
- 2026-03-02: First published.
Keep entries factual. "Improved for AEO" is not a revision note. "Added comparison table for GPTBot vs ChatGPT-User" is.
Product changelogs on /changelog also reinforce that the organization ships — an experience signal that pairs with E-E-A-T for answer engines. For docs sets, a single changelog index beats silent edits across fifty URLs.
Step-by-step: fix date hygiene this week
- Export URLs with
dateModifiedin schema or CMS fields. - Spot-check 10 high-traffic pages: does the visible date match schema?
- Find pages where
dateModifiedequals "today" on every build — disable that automation. - Define a house rule: "Substance change required to bump."
- Add a short Revisions section to evergreen guides.
- For pricing and legal pages, add "Last reviewed: Month Year" even if body text did not change after a review-with-no-edits (optional: "Reviewed, no changes").
- Redirect or update old URLs that still rank with obsolete plan names.
- Re-fetch as a text client to confirm dates appear in HTML.
- Align sitemap
lastmodwith the same rule set.
Sitemaps and freshness
XML sitemaps with honest lastmod help discovery. Inflated lastmod on unchanged URLs trains systems to ignore you. Keep sitemap lastmod aligned with real content changes — the same discipline as XML sitemaps for AI discovery.
If your CMS sets lastmod on every republish of the whole site, turn that off. Bots learn which sites cry wolf.
Editorial calendar without fake freshness
Quarterly reviews are enough for most evergreen AEO guides. Mark each URL: review due date, owner, "changed / no change." No-change reviews can stay undated in schema; optionally note "Reviewed July 2026 — no substantive changes" in a revisions block if you want human transparency without lying in dateModified.
Comparison and pricing pages deserve a tighter cadence because assistants reuse their numbers — coordinate with pricing page clarity and comparison pages.
Mistakes
- Title-only year updates ("Best Tools 2025" → "2026") with stale body copy.
- Future dates from timezone bugs in the CMS.
- Showing "Updated" in a client-rendered widget bots never see.
- Different dates on AMP / mirrored domains / localized copies without a policy.
- Using Gartner’s Feb 2024 forecast (traditional search volume may drop 25% by 2026) as an excuse to stamp every URL "fresh" — a forecast does not justify fake timestamps.
Coordinating dates across schema, UI, and feeds
Treat three surfaces as one contract: visible "Updated" text, JSON-LD dateModified, and sitemap lastmod. When marketing changes only the hero date widget, engineering may still emit last month in schema. Pick one CMS field as source of truth and render it everywhere — including RSS or Atom if you publish feeds assistants or aggregators still read.
For translated sites, do not bump every locale’s date because English changed. Update dateModified on a locale only when that locale’s substance changed. Otherwise you imply a French revision that never happened, which is the same class of lie as a global "Updated today" stamp.
How to verify
Pick one evergreen URL. View source: find datePublished, dateModified, and visible text. They should agree. Ask an assistant what year your guide claims; if it says 2026 and your substance is 2024, you have a trust bug, not an SEO win.
BrandKnown readiness checks whether the site is clear and reachable. A re-scan after you fix date lies proves the page changed in the checklist sense — not that rankings moved. Prefer truth over theater. See why you re-scan after fixes.
