To decide which pages to refresh first, rank them by evidence rather than by age: a fact on the page that is now wrong, a source that AI engines cite for your topic that has changed, a fall in how often engines cite the page, and how much the page matters to buyers. A page can be five years old and correct, or four months old and out of date. Give every refresh a written reason drawn from at least one observation, score it, and schedule the highest scores into the calendar. The method below gives you the signals, a scoring rubric and a copyable register.

In short

Age tells you when a page was last edited. It does not tell you whether the page is wrong, whether engines still cite it, or whether a buyer cares.
Four signals justify a refresh: an outdated or contradicted fact, a change in a source engines cite, a citation trend for the page, and a known change in your business that the page has not caught up with.
Multiply the evidence by buyer importance, then sort. Every row in the queue must carry a reason a colleague could check.
A refresh is a hypothesis. Whether it worked is a separate question, answered in a before-and-after review.

Why is article age a poor trigger for a refresh?

Article age is a poor trigger because it is a proxy for the things that actually matter, and a noisy one. It ignores whether the content is still true, still cited and still important to the people you want to reach.

Calendars built on age tend to produce two errors. They send writers to rewrite stable, accurate pages that nobody was going to ask about, and they leave a recent page untouched even though the pricing on it changed last month. For AI search this deserves attention, because an engine may repeat an out-of-date statement in an answer to a buyer, with your brand attached.

Age is still worth recording. It is a useful tie-breaker and a sanity check. It just should not be the reason a row is in the queue.

What evidence should trigger a content refresh?

Four kinds of evidence justify a refresh, and each one can be collected without guessing: a fact problem, a source change, a citation trend, and an internal change. Together they answer "is this page wrong, is the landscape around it different, is it losing ground, and has our business moved?"

A fact problem means an engine states something about your brand that contradicts what you know to be true. A source change means a page that engines cite for your topic now says something different from before. A citation trend means engines cite one of your URLs more or less often than they did over a comparable earlier period. An internal change means you changed a price, feature, policy or announcement, and the page still describes the old state.

Most of these signals can be read in DiscoveredBy, described next. None of them is proof that a refresh will improve your visibility. They are reasons to look at a page first.

How do you find outdated facts on your own pages?

Start with your approved facts. In Fact check you keep a list of statements about your own brand (pricing, company, product, availability, policy or other), and the screen shows whether engines state them correctly. A contradiction appears in the review queue with the engine's quote and the sources it cited for that sentence.

Two review outcomes matter for the calendar. Confirmed wrong means the answer really is wrong about your fact, so check the sources the engine cited for that sentence and which of your pages state the fact. Our fact is out of date means the answer may be right and your approved fact wrong: edit or archive the fact, then look for pages that still state the old version.

Fact check also reports a Change per fact against the previous comparable study: newly wrong, fixed, still wrong, still right, or no comparison. "Newly wrong" is a strong reason to find the pages that state that fact this week. The product does not map a fact to a page, so that search is yours.

Limits to state plainly: the check covers only the facts you entered, and only the answers it reads (a weekly study of questions about your brand, plus the tracked prompts you selected). It shows a contradiction; it does not change any answer. A claim that matches none of your facts is not reported, so a page can be stale in ways this signal never sees.

How do you spot a change in a source that engines cite?

Look at the third-party and competitor pages engines cite for your topic, and note which ones changed. Use Source mention history: you save a snapshot of the most-cited pages in a 7, 28 or 90 day window, then compare it with an earlier snapshot of the same window length.

The comparison labels each page, for a chosen brand, as a gained match, a lost match, unchanged or not comparable. A gained or lost match says the brand evidence on that cited page differs between two observations. That is a reason to read the page and ask whether your own page still answers the same questions. An "unchanged" label only says the match state is the same; other text on the page may have changed.

Be careful with what this proves. The docs are explicit that these comparisons do not establish when a page changed, an endorsement, or a causal effect on AI visibility. A page dropping out of the window or the page cap is not a lost mention. And fetch dates are separate from snapshot dates. Treat a difference as a prompt to read, not as a finding.

How do you read a citation trend for a single page?

Compare how often engines cite that URL in two equal windows, and write down both numbers. In Citations, the Sources tab groups citations by URL and shows which engines cited each one and how many times.

Three cautions keep this honest. First, both tabs are built from the newest 500 citations in the window, so a busy project needs a narrower filter before a per-URL count means anything. Second, use the same window length, the same engines and the same prompts on both sides, or the difference reflects the setup rather than the page. Third, a citation is an observation of one answer. It does not say why the engine chose or dropped the page.

If your page was cited for a prompt last month and is not now, that is a candidate. The reason to refresh might be that the page fell behind, or the cause might be elsewhere, such as an engine change. Note both possibilities in the register, and decide before you look how large a fall counts, so that a drop from 2 to 1 does not set the queue.

Which existing DiscoveredBy queues already hold refresh candidates?

Actions → To do collects open work from seven parts of the product in one list, highest priority first, with a reason line under each item. Two of its kinds are directly relevant: open fact check findings (always High) and citation gaps and optimizations, which carry an impact or opportunity score.

The Actions To do tab, On your site view, showing High priority items, each with a title and a reason line under it. — Demo data. Each open item in To do carries a reason line for its priority.

Two things to know. The list has no status of its own: each item is a record from another page, and acting on it changes that record. And it does not know your business. It cannot see that your pricing changed last month or that a page is the one your sales team sends to every prospect. Treat it as one input to the calendar, not the calendar.

A citation gap names the missing piece on a page compared with the pages engines cite for a prompt; an optimization drafts a fix for one page. Their suggestions, such as "content that reads newer" or a fresher date, are hypotheses to test. To see this work grouped by page, open Page issues. It covers known inventory, not a complete site crawl, so "no saved issues" on a page does not mean the page is healthy.

How do you turn the evidence into a queue?

Give each page a score from its evidence signals, multiply by buyer importance, and sort. The rubric below is a planning device we suggest, not a metric the product computes; adjust the weights to your team, but keep them written down and stable across cycles.

Signal	Code	Points	Evidence required
A fact this page states is contradicted or out of date	F	3	A Fact check finding about a fact the page states, or an approved fact edited after the page was last updated
A known internal change is not on the page	X	3	A dated change (price, feature, policy, announcement) with an owner
A cited source changed	S	2	A saved comparison or a read of the source, with the date
Citations for this URL fell between equal windows	C	2	Two counts, same window length, engines and prompts
An open gap or optimization targets the page	G	1	The gap or optimization record

Buyer importance is a 1 to 3 rating you assign: 3 for pages a buyer meets at the decision point (pricing, security, a core product page), 2 for pages that support evaluation, 1 for background content. Base it on how buyers use the page, using what your sales and support teams see, not on traffic alone.

Score = sum of evidence points × buyer importance. A page with no evidence scores zero, however old it is. Break ties by preferring pages with an F or X signal, then the older page.

The refresh register (copy this)

Keep one row per candidate page, and never enter a row without a reason and an evidence link.

REFRESH REGISTER

Page URL:
Page type / buyer importance (1-3):
Last edited (date, and age in months):
Signals present (F / X / S / C / G):
Reason, in one sentence a colleague could check:
Evidence (links, dates, both windows for any trend):
Evidence points:
Score (points x importance):
Proposed change (hypothesis, not a promise):
Owner:
Slot in the calendar (sprint / week):
Refresh done (date):
Recheck date (same prompts, engines, windows):
Outcome logged in: (before-and-after log)
Not doing because: (if deferred, say why)

And the queue view:

Rank	Page	Age (months)	Signals	Points	Importance	Score	Slot
1

A worked example

Illustrative example: Quillstone and its competitors are fictional, and the numbers are made up to show the method.

Quillstone sells document-review software. Its content lead has six pages to consider. Its competitor Brieflane appears in some of the cited sources.

Before scoring, the lead gathers evidence:

/pricing: a Fact check finding says an engine states the old per-seat price. The price changed four weeks ago, and the page was last edited four months ago. Signals F (3) and X (3).
/integrations/sharepoint: the integration launched two months ago and the page still calls it "coming soon". Signals X (3) and G (1) from an open optimization.
/blog/contract-review-checklist: 26 months old. Own citations for the URL were 9 in the earlier 28-day window and 4 in the latest one, same engines and prompts (C, 2). A saved comparison shows a cited Brieflane comparison page gained a Brieflane match since the earlier snapshot, and reading it shows it covers a section this page lacks (S, 2).
/security: nine months old, accurate. A cited source changed (S, 2) but nothing else.
/features/redlining: seven months old, with an open citation gap (G, 1) and citations down from 6 to 3 (C, 2).
/blog/2019-year-in-review: 60 months old. No signals.

Rank	Page	Age (months)	Signals	Points	Importance	Score	Slot
1	/pricing	4	F, X	6	3	18	Sprint 1
2	/features/redlining	7	G, C	3	3	9	Sprint 1
3	/integrations/sharepoint	2	X, G	4	2	8	Sprint 1
4	/blog/contract-review-checklist	26	C, S	4	2	8	Sprint 2
5	/security	9	S	2	3	6	Sprint 2
6	/blog/2019-year-in-review	60	none	0	1	0	Not scheduled

The arithmetic: pricing is (3+3) × 3 = 18; redlining (1+2) × 3 = 9; SharePoint (3+1) × 2 = 8; checklist (2+2) × 2 = 8; security 2 × 3 = 6; year-in-review 0 × 1 = 0. SharePoint and the checklist tie at 8, so SharePoint goes first because it carries an X signal.

The oldest page ranks last and is not scheduled, and a four-month-old page with a wrong price ranks first. That is the whole point of the method. With capacity for three refreshes per sprint, Sprint 1 holds ranks 1 to 3 and Sprint 2 holds ranks 4 and 5. Each row has a recheck date, and results go into the log you would use for a before-and-after review.

A flow from four evidence signals into a scoring step, then a ranked queue, then sprint slots, then a recheck logged separately. — Evidence in, ranked queue out, outcome measured separately.

How do you keep the calendar from filling with noise?

Set a cap and hold it. Decide how many refreshes fit in a sprint, fill the slots from the top of the queue, and carry the rest over unchanged. Re-score at the start of each cycle rather than mid-cycle, because signals move: a fact contradiction may resolve after a study, and a citation dip may recover on its own.

Add two standing rules. Deferred rows need a written "not doing because", so they stop resurfacing without an answer. And pages with zero evidence get a light-touch annual read only, not a rewrite; a quick check that the facts still hold is enough.

It also helps to sort the queue by the kind of fix, since the work differs. Correcting a price is an edit. Adding a missing section is a brief; turning a citation gap into a content brief covers that handoff.

What this method cannot tell you

The method ranks evidence you happened to collect, so it inherits every gap in that collection.

Unchecked facts are invisible. Only facts you entered are checked, against the answers the check reads, and a wrong claim you never listed goes unreported.
Source changes are not dated. The comparison shows a difference in brand evidence between two snapshots, not when the page changed or why.
Citations are observations. A fall in citations does not prove your page is the cause, and a rise after a refresh does not prove the refresh worked.
Weights are judgment. The points and importance ratings are yours. Two teams will rank the same pages differently, and that is fine if the reasons are recorded.
A refresh is a hypothesis. Do not promise a stakeholder a citation lift. Promise a documented reason, a dated edit and a planned recheck.

Frequently asked questions

How often should I rebuild the refresh queue?

Once per planning cycle, such as each sprint or month, and immediately when a dated internal change lands, such as a price change. Re-scoring daily creates churn without new information.

Should I ever refresh a page just because it is old?

Only as a low-priority read. Check that its facts, links and product descriptions are still true. If nothing is wrong and no signal points at the page, leave it alone and log that you checked.

What if I have no citation history for a page yet?

Score it on the signals you do have. A newly tracked project has no earlier window to compare, so the C signal stays at zero until you have two comparable windows. The X signal works from day one, and F works from your first fact study.

Can this replace my SEO refresh process?

No. It adds evidence about how AI engines describe and cite your pages. Your existing search-performance and analytics work still applies, and pages can qualify for the queue on either basis.

How do I know if a refresh worked?

Do not judge it inside this queue. Record the edit date, keep prompts, engines and windows consistent, and compare before and after; "no clear change" is a valid result. For a worked method, see the before-and-after review.

What should I do when an engine states a wrong price?

Confirm the fact in your list is current, review the finding, then check which sources the engine cited for that sentence. See what to do when AI gets your pricing or product facts wrong.

Next step

Start with the signals you can collect today: list your approved facts in Fact check, open Actions → To do to see what is already waiting, and note the dates of your last internal changes. Then fill the register above for your top ten pages and schedule the first sprint. Sign in to DiscoveredBy to check your facts and see your open items in one list; which of these features you have depends on your plan.

Build a content refresh calendar from evidence, not article age