Create a Source-Refresh Calendar for Articles That Depend on Changing Facts

Not every article needs the same review interval. A conceptual explanation of how to prioritise work may remain useful for years, while a page describing a changing product interface can become inaccurate after a redesign. Reviewing every URL quarterly wastes time; reviewing none of them allows important instructions to decay.

A source-refresh calendar ties maintenance to the claims inside a page. Instead of asking only “When was this article published?”, it asks “Which facts could become wrong, what source proves them today, and how costly would the error be?”

Inventory claims, not just URLs

For each important article, identify statements that depend on external facts: product capabilities, interface steps, policy requirements, fees, dates, eligibility rules, technical specifications or legal procedures. Record the exact source supporting each claim. A general homepage link is not enough when a specific help page defines the behaviour being described.

Separate those statements from editorial recommendations. “Google's help page says business hours can be edited from the profile” is a source-dependent factual claim. “A small team should assign one person to review the change” is an operational recommendation. Both can be useful, but they need different forms of support.

Assign review priority by risk

Use three practical dimensions: volatility, consequence and exposure. Volatility estimates how likely the fact is to change. Consequence considers the harm if a reader follows outdated advice. Exposure reflects how many people or important decisions depend on the page. These are internal ratings, not an official scoring standard.

A high-exposure page describing a sensitive policy or customer-facing process deserves more attention than a low-traffic note about a stable concept. A product tutorial with many interface screenshots may require a review after a known product change. A general checklist might only need a source check when an external rule changes or a reader reports a problem.

Set triggers as well as dates

A calendar date is useful, but event-based triggers are often more effective. Schedule a review when the official source announces a change, a product owner confirms a new workflow, a policy page is updated, a link fails, or a customer reports that a step no longer works. The trigger should lead to a specific action: verify the affected claim, not rewrite the entire article by default.

Build the register

Field	Purpose
Article URL	Identifies the content being maintained
Claim or instruction	Makes the review target precise
Source URL	Points to the supporting evidence
Volatility	Low, medium or high internal rating
Consequence if wrong	Describes reader or business impact
Trigger or review date	States when to check again
Responsible reviewer	Prevents ownership gaps
Outcome	Verified, changed, withdrawn or escalated

One article may have several claims with different review needs. Avoid assigning one blanket date if a critical product instruction is more volatile than the article's general advice.

Verify the source, not just the hyperlink

A URL that opens is not necessarily evidence that the claim remains accurate. Read the source and confirm it still supports the exact statement. Check whether the source is official, whether the relevant section has changed, and whether the article has overgeneralised a feature that applies only in certain situations. If the source has moved, locate the replacement documentation rather than leaving a citation to a generic page.

When no authoritative source can be found, narrow the statement, mark it as an unverified hypothesis for editorial review, or remove it. Do not keep a claim simply because it has been on the website for a long time.

Use an update threshold

Not every source change requires a rewrite. Ask whether the change affects the reader's decision, the correctness of a procedure, the eligibility of a claim or the meaning of the page. A minor wording change in documentation may not require a content edit. A change to a business profile setting or policy requirement may demand a correction before the next scheduled review.

When a substantial update is made, record what changed, which source justified it, who reviewed it and when it went live. If the page no longer has a valid purpose, consider retiring or consolidating it rather than keeping a useless URL alive through repeated cosmetic edits.

Monthly maintenance routine

At the beginning of each month, review the highest-risk items and any triggered changes. Assign a reviewer and a deadline. At the end, inspect unresolved claims and escalate those that cannot be verified. Do not let a “pending” status quietly become permanent. A page with an important unsupported claim should be corrected, qualified or temporarily removed from circulation according to the risk.

Google's people-first guidance values accuracy and original usefulness, and cautions against changing dates without substantive changes. A source-refresh calendar supports those principles by making factual maintenance specific and defensible rather than cosmetic.

Ready-to-use checklist

• Volatile claims are listed separately from recommendations.
• Every critical claim has a direct supporting source.
• Review priority reflects volatility, consequence and exposure.
• Event triggers are defined for known sources of change.
• Review outcomes are recorded.
• Unverifiable claims are qualified, removed or escalated.
• Dates are changed only when the page has materially changed.

Schedule reviews around facts that can break, so limited time goes to outdated information most likely to mislead customers.