How Do You Set Refresh Dates for Claims, Screenshots and Tool Instructions?

Set evidence refresh dates from observed source changes, release schedules, consequence and detection coverage instead of one universal content cadence.

Short answer: answer: Measure how often the source or interface has changed, identify the next scheduled release, and shorten the interval when an error would cause greater harm or when change detection is weak. Use event alerts plus a dated manual review. As a baseline, recheck high-consequence platform instructions every 30 days, volatile evidence every 60–90 days and stable historical facts annually—but replace those defaults with observed history as soon as you have it.

The usual content audit treats every page alike: refresh quarterly or annually. That wastes time rechecking fixed historical records while a screenshot-dependent platform workflow can fail days after publication.

Recency labels also mislead. Updating a date without re-running the instruction is cosmetic, while an old article can remain correct. CDM's position is that evidence units, not articles, need refresh dates, and volatility must be multiplied by consequence—not popularity.

The Evidence Half-Life Calendar

The Evidence Half-Life Calendar uses half-life as an operational metaphor: the point at which confidence should be renewed, not a statistical claim that truth decays exponentially. It assigns each evidence unit a source history, consequence, detection route, next check and replacement action.

1. Split the page into evidence units

Register statistics, policy statements, feature availability, step sequences, screenshots, UI labels, prices, legal requirements, definitions and historical facts separately. One article may contain a stable statute citation beside a volatile menu path.

Link every unit to the exact source and active uses. A screenshot and the sentence beneath it are separate objects: the instruction may remain correct while button placement changes, or the screenshot may look current while the policy changed.

2. Build an observed change history

Collect source revisions, release notes, documentation changelogs, prior snapshots and your own verified checks. Record changed, checked-no-change, change type and impact. Do not treat a copyright year or page last updated label as complete version history.

Use at least three intervals when available. Calculate the median days between material changes—not copy edits—and retain the range. With fewer observations, use the source's release schedule plus a conservative default. State the uncertainty; a new tool has little history precisely when volatility may be high.

3. Separate volatility from consequence

Score volatility from 1 (fixed historical record) to 5 (UI or policy changes several times a quarter). Score consequence from 1 (minor visual mismatch) to 5 (could cause noncompliance, data loss, unauthorized spend or material factual error).

A stable regulation can still deserve monitoring because consequence is high. A frequently changing decorative screenshot can tolerate a slower replacement if the text does not depend on it. Keep the two scores visible so editors understand the schedule.

4. Credit reliable change detection

Subscribe to official RSS, changelog, release feed, API version notice or regulator alert. Monitor source hashes or semantic diffs when terms allow it. Alerts reduce exposure between manual checks, but they do not eliminate review: sources can change silently and automated diffs produce noise.

Google Search Central publishes a dated documentation update page and RSS feed. Schema.org publishes versioned release history. These are stronger detection surfaces than a dynamic help page with no public log, so the latter needs more frequent manual checks.

5. Calculate the next review

CDM recommends this operational rule:

``text base_interval = median observed material-change interval caution_factor = 0.50 high consequence; 0.75 medium; 1.00 low next_review = earliest of: last_verified + (base_interval × caution_factor) next scheduled release date source-specific maximum interval ``

When history is insufficient, use defaults and label them provisional. Event triggers always override the date: source correction, policy announcement, support ticket, failed reader attempt, product release or unusual performance change.

The formula is a CDM recommendation, not a validated probability model. Backtest it quarterly: how many material changes were caught by alerts, scheduled review or readers, and how long did incorrect content remain live?

6. Match the review test to the evidence

A statistic review checks new releases, revisions, denominator and method. A tool instruction is re-executed in a clean or representative account. A screenshot review compares both content and accessibility text. A legal claim checks current authoritative text and effective dates with qualified review.

Record observed result, environment, reviewer and evidence. Looked current is insufficient for a five-step integration; perform the steps without making unsafe external changes and mark any untested branch.

7. Choose update, annotate, retire or preserve

Update when the same claim or procedure has a current successor. Add a dated note when historical context matters. Retire when the feature no longer exists or evidence no longer supports the proposition. Preserve a historical screenshot only when it is clearly labeled and valuable.

Changing a claim creates a correction workflow, not merely a new updated date. Trigger every dependent use in the claim register.

Observed histories and recommended schedules

These examples use public change records available on 26 September 2026. The recommended intervals are CDM judgments, not publisher promises.

Google Search documentation: fast and consequential

Google's update log records numerous 2026 documentation changes. It announced FAQ rich-result deprecation on 8 May and removal of its documentation on 15 June; it also logged AI-search guidance, robots notes and structured-data changes across months. A current-step SEO article should therefore subscribe to the official feed and receive a 30-day manual check; a feature-specific instruction gets an immediate event review.

Schema.org vocabulary: versioned but active

Schema.org's release page records 29.0 on 24 March 2025, 29.1 on 25 April, 29.3 on 4 September, 30.0 on 19 March 2026 and 30.1 on 16 September 2026. Recent material intervals range from about a month to six months. CDM would check implementation claims at each release and at least every 90 days, while pinning examples to a version when exact vocabulary matters.

FTC endorsement guidance: slower, high consequence

The FTC says its Endorsement Guides were revised in June 2023; the preceding major version dated to 2009. The change interval is long, but consequences can be high and related rules or staff guidance can change between major revisions. CDM would monitor alerts continuously, conduct a 90-day link-and-effective-date check and require specialist review annually or on an announced change.

Published survey statistics: scheduled by series

A dated Pew survey result does not become false when a new wave appears, but current usage does. Store the historical field period permanently and check the publisher's release stream before any current-tense use. Schedule the next review from the known series cadence; do not assign an arbitrary quarterly refresh to a closed historical claim.

Reader asset: evidence half-life calendar

In production, add claim ID, source URL, last three material changes, median interval, score rationale, owner, last verified evidence and dependent uses.

Related guides

• How Do You Use data-nosnippet to Keep Volatile Claims Out of AI Answers?
• How Can You Tell Whether Five Sources Repeat the Same Original Claim?

Frequently asked questions

How often should evergreen marketing content be updated?

There is no sound universal interval. Break the article into evidence units and schedule each from source volatility, consequence and release cadence. Stable historical facts may need only an annual link check; live platform steps may need monthly execution plus alerts. Refresh the page when a material unit changes, not to create cosmetic freshness.

Measure overdue errors, not calendar activity. The caveat is sparse history: start with conservative CDM defaults, label them provisional and adjust after measuring how changes were actually detected.

Should every screenshot be replaced when the interface moves?

Replace it when the visual would misdirect a reader, conceal a required setting or materially conflict with the current workflow. A minor color or spacing change may only need alt-text and caption verification. Store screenshot date, account context, locale, feature version and the instruction it supports.

Test with a representative account because staged rollouts differ. Preserve the replaced image in controlled version history. The caveat is historical content: an old interface can remain when explicitly presented as a dated record rather than current guidance.

Can automated page monitoring replace manual evidence review?

No. Hash and text-diff monitors can detect a change, but dynamic components, localization and navigation produce noise, while a meaningful behavior change can occur without visible wording. Use official feeds and semantic diffs to trigger review, then have an owner evaluate scope and rerun the relevant test.

Monitor only in ways allowed by site terms and technical controls. The caveat is machine-readable versioned sources: reliable APIs can automate more comparison, but editorial meaning and downstream impact still require a decision.

What if a source has no changelog or last-updated date?

Create your own verified history with dated snapshots, source hashes or structured extracts where lawful, and shorten the manual interval. Check related release notes, support announcements and authoritative archives. Record that the public change history is unavailable; do not invent a publication date from search snippets.

A direct source can remain authoritative despite poor versioning, but uncertainty increases maintenance cost. Assign a named owner to that manual check. The caveat is that snapshots prove what you observed on one date, not every change between checks.

Does a new report require replacing every historical statistic?

No. Preserve a dated statistic when the article discusses that period or forecast. Replace it when the wording promises a current value, and compare versions only when definitions and methods remain compatible. Create a successor claim record instead of overwriting provenance.

A 2024 survey found... statement can remain accurate after a 2026 wave, though context may merit a link. Label both periods clearly for readers. The caveat is publisher correction: if the old value itself was revised or withdrawn, trigger correction across all uses.

Who should own the evidence refresh calendar?

Assign one editorial operations owner for queue health and a subject owner for each evidence unit. The central owner monitors overdue reviews and dependencies; research, legal, product or platform specialists perform the appropriate test. Article authors should not remain permanent owners after role changes. A small site can use one person with documented review types and escalation contacts.

Record backup ownership for staff changes. The caveat is high-consequence material: an editor can schedule it but should not substitute for qualified legal, statistical or technical validation.

Next decision: Build a correction dependency map before changing a shared fact

Related reading: Build a claim evidence register · Trace circular citations · Verify marketing statistics

Sources and research notes

• Google Search Central, documentation updates — checked 26 September 2026. Official dated changelog used for observed examples; documentation changes do not always mean product behavior changed.
• Schema.org release history — checked 26 September 2026. Official version dates and summaries used to calculate observed intervals.
• FTC, Endorsements, Influencers and Reviews — checked 26 September 2026. Official U.S. hub noting the 2023 guide revision.
• FTC, Endorsement Guides: What People Are Asking — checked 26 September 2026. Current staff guidance; changes outside major guide revisions remain possible.
• Pew Research Center, Teens, Social Media and Technology 2024 — checked 26 September 2026. Example of a dated field period and newer-wave notice.

Research limitation: observed histories cover selected public records, not every silent source or product change. Review intervals, scores and the formula are CDM recommendations that require backtesting against each site's actual correction and change data.