Content freshness for AI search: the 30-day rule

The recency cliff

Answer engines weight source freshness harder than classic search ranking ever did. The effect is measurable in citation data and across hundreds of Citevera audits: pages with dateModified within the last 30 days are cited meaningfully more often than equivalent pages from 90 days ago, even when the content is unchanged between them.

The 30-day rule is the simplest way to describe this: most answer engines treat content modified in the last 30 days as "fresh" and weight it up, content 30 to 180 days old as "recent" and weight it normally, content 180 days to 2 years old as "aging" and weight it down, and content more than 2 years old with no modifications as "stale" and often excluded from consideration.

This is not a ranking signal in the classic sense. It is an arbitration signal that kicks in at the moment the engine picks which of several relevant sources to cite. Fresh pages win the arbitration more often.

Why the engines do this

The reasoning is straightforward. For most informational queries, recent information is more likely to be accurate. Software changes. Benchmarks are superseded. Best practices evolve. An engine that cites older information is more likely to cite wrong information, which damages user trust in the engine more than in the cited source.

The practical consequence: engines look at page metadata - dateModified, Article.datePublished, <last-modified> headers - to make the freshness judgment. They do not re-read your whole page and decide freshness from content alone. The date is the signal.

The dateModified trap

The obvious exploitation is to update dateModified on every page every day and appear perpetually fresh. Engines detect this. The specific mechanism:

• Content that gets dateModified bumps without any actual content change is detected through hash comparison across crawls. Same content, new date, repeatedly - the engine learns to ignore the date on that domain.
• Domains that update dateModified sitewide without corresponding content changes get the date-weight discounted for the whole domain over time.

Faking freshness is worse than acknowledging staleness. If you cannot afford to genuinely update a post, leaving the old date is better than lying about a new one.

The refresh cadence by content type

Different content types have different natural refresh rhythms. Here is what we recommend to Citevera customers.

Blog posts

• Evergreen concepts ("what is AEO", "how does schema work"): full refresh every 6 months. Revisit numbers, update sources, rewrite passages where the landscape has shifted.
• Year-specific content ("AEO in 2026"): refresh quarterly if the year is current, then either archive or rewrite at year-end with the new year in the title and URL.
• News and trends coverage: 30 to 60 day lifespan. If your team cannot sustain the cadence, do not write this kind of content. A stale news post hurts more than never publishing.

Documentation

• Product docs: refresh whenever the product changes. If your last update was 6 months ago and no product changes have happened, that is fine - but confirm nothing has drifted.
• Tutorials: refresh when the underlying technology changes. Tutorials for "how to X with our plugin version 2.3" should update when version 2.4 ships.

Pricing and product pages

• Update whenever the product changes. Not more often, not less. If you have not changed prices or features in 90 days, leave the date. If you changed a bullet, bump the date.

Comparison and landscape pages

• Revisit every 90 to 120 days. These pages go stale fast because the comparison set itself changes.

What "refresh" actually means

The refresh must be substantive for the freshness signal to register. A good refresh pass includes at least two of these:

• Verify numbers. Every statistic on the page is still accurate. Update any that have moved.
• Verify sources. Every external link still resolves. Replace or remove any that 404.
• Update examples. If the post references "current state" - model names, tool versions, pricing - confirm it still matches reality.
• Rewrite one section. Not the whole post. Pick a section that could be sharper and rewrite it. This adds genuine content change the engine can detect.

A refresh pass takes 20 to 45 minutes per post. A team can realistically maintain 20 to 50 posts at a 6-month cadence with one content person part-time.

The prioritization rule

You cannot refresh every post on your site every month. You should not try. Prioritize by:

1. Traffic. Top 20 percent of pages by organic traffic get the most refresh attention. 2. Citation value. Pages your AEO monitoring shows getting cited (or potentially-cited) are high-priority. 3. Commercial intent. Pricing, product, and high-funnel pages get refreshed whenever the product changes. 4. Age. Pages older than 18 months without touches are candidates for either a big refresh or deprecation.

Low-traffic, low-citation, old pages are candidates for pruning. A site with 200 low-traffic posts has worse freshness behavior than the same site with the best 60 posts kept fresh. Pruning by deleting or consolidating is a real option.

The datePublished vs dateModified question

Both fields exist in BlogPosting and Article schema. Populate both. The distinction:

• datePublished is the original publish date. Never change it except for genuinely republished content.
• dateModified is the last substantive update. Change it on every meaningful refresh.

Engines read both. A post with datePublished: 2022-03-15 and dateModified: 2026-04-20 reads as "originally old but recently updated" - and performs well. A post with both dates set to the same old date reads as "untouched since" and performs worse.

The common mistake: CMSes that auto-populate dateModified on every save, including minor edits that do not change content. This introduces noise that eventually gets discounted. Configure the CMS to only update dateModified on meaningful changes, or accept the noise and understand it is a small tax.

A simple freshness audit

Run this on your site once a quarter.

1. Export a list of all blog posts with their datePublished and dateModified. 2. Flag any post with dateModified older than 12 months and annual traffic over 100 visits. 3. Check the flagged posts manually: is anything in them wrong, stale, or suboptimal? 4. Refresh the ones that need it; archive or delete the ones that do not.

This takes an afternoon. The delta in citation and organic performance shows up over the following 60 to 90 days.

Run a free audit to see the freshness distribution across your blog

How Citevera scores freshness

The audit checks datePublished and dateModified on every scanned page, flags pages where dates are missing, and weights pages by staleness. A blog with 10 posts all modified in the last 6 months scores higher on the AEO axis than a blog with 10 posts all 2 years old, even if the content is identical.

The audit also surfaces the distribution: how many of your pages are fresh, how many are aging, how many are stale. That distribution is usually the first surprise new customers see in their report. Sites that thought they were "keeping up" often have 60 to 80 percent of their content more than a year old.

Frequently asked questions about content freshness

Does updating dateModified hurt SEO in some cases?

No. Classic SEO also rewards fresh content, though less aggressively. An updated post is better than an unupdated one for both AEO and SEO, provided the update is substantive.

What if my post is genuinely still accurate?

Then refresh it by adding to it. A new FAQ question, a new example, a new section covering recent changes in the space. This gives the engine a real content change to register. Just bumping the date alone is where detection happens.

How do I handle archive posts that I want to keep reachable but not refresh?

Leave them as they are. They will age, their citation probability will decline, and that is fine. Sites with clearly-dated archive content do not get penalized; they get correctly-weighted as "old references".

Does deleting old posts hurt my domain?

Usually not, if the posts were low-traffic and irrelevant. Be careful with posts that have inbound backlinks - 301 redirect them to a current equivalent rather than 404-ing them, so the link equity transfers.