dateModified. The most underrated SEO lever in 2026.

Of all the SEO and AI visibility levers available in 2026, dateModified is the cheapest to fix and the most often neglected.

Here's why it matters, how to use it without crossing into spam, and the specific failure modes we see in customer audits.

#Why dateModified matters more than it used to

AI engines weight recency aggressively. Google does too, but mildly, and only for certain query intents. For LLM answer engines the weighting is much stronger across the board, especially for fast-moving topics (which in 2026 is basically anything related to AI, software, finance, healthcare, or policy).

The mechanism is logical. The engines train on a snapshot. They have no idea what's current at query time. The strongest signal they have that "this content is still accurate" is the page's own assertion of when it was last reviewed. They lean on it.

In practice: a page from 2022 you updated last week beats a page from 2023 you haven't touched. By a lot. We've seen citation rate climb on customer pages after a genuine refresh-and-update pass.

#Where to set it

Three places, in roughly decreasing order of importance:

1. Article / BlogPosting JSON-LD schema. The dateModified property. This is what AI engines read first.
2. HTTP Last-Modified header. Most CDNs set this automatically from your file mtime. Worth verifying it tracks real edits.
3. Visible on the page. "Last updated Jan 18, 2026." Helps human trust signals; the engines may also lift this if the schema is absent.

If you can only do one, do the schema. If you can do two, do the schema and visible. The HTTP header is the bonus tier.

#The fake refresh trap

The obvious "growth hack" is to set dateModified to today's date on every page, every week, without actually editing the content. Don't do this.

Both Google and the major AI engines (Perplexity in particular) have been increasingly willing to penalize sites where dateModified diverges from actual content change. The detection mechanisms vary:

• Comparing crawled content hash week-over-week against the asserted dateModified
• Watching for sites where dozens of dateModified values move in lockstep, suggesting a batch update
• Cross-referencing with archive.org snapshots for sites that matter

Once a site is flagged for this pattern the recency boost disappears AND the engine becomes more skeptical of the site's other claims. It's a "use it or lose it" lever where "use it" means real edits.

#The honest pattern

What works:

1. Quarterly refresh on your top 20 pages. Real edits. Update one stat, add a new example, remove a dead link, sharpen the lead. 30 minutes per page if you've prepared.
2. Smaller refreshes more often on the top 5. If your homepage or pricing page is updated once a year, you're leaving a lot on the table.
3. updatedOn field in your CMS that triggers dateModified on actual content commits. If your CMS or static-site generator doesn't already do this, fix it. The right pattern is "git commit on the markdown file flips the timestamp." Drive-by date updates without content changes shouldn't pass review.

#A six-month refresh cadence we like for SaaS blogs

• Top 5 highest-traffic pages. Quarterly. Substantive edits.
• Top 6 to 20. Every 6 months. Lighter pass.
• The rest of the blog. Annual review, prune what's no longer accurate, redirect what's no longer useful.

This cadence is enough to keep dateModified honest and current across the pages that matter, without committing your team to content treadmill territory.

#How to check yours

In one minute: open your site's most important page, view source, grep for dateModified. Is it within the last 6 months? If yes, good. If no, that's your starting point.

Crawlmind's audit flags every page where dateModified is older than the threshold you set per page type (default 180 days for blog, 90 days for pricing, 365 days for legal). It's the kind of check that's trivially easy to automate and disproportionately valuable to do.