Refreshing an existing page sounds easier than writing a new one. The structure is already there, and an AI tool can replace stale sentences quickly.

The existing page also carries claims, links, screenshots, metadata, translations, approvals, and performance history. A small product change can make several of those fields unsafe to reuse.

A refresh is a new decision about an old asset. The old version is evidence, not a complete brief.

Find what changed before rewriting#

Start with the event that triggered the refresh:

Trigger	Questions
Product change	Which feature, limit, or workflow changed?
Pricing change	Which amounts, plans, or comparisons are affected?
Security or legal update	Which claim or disclosure needs review?
Source expiry	Which facts can no longer be reused?
Performance decline	Did the audience or search intent change?
Brand update	Which terminology or visual treatment changed?

The trigger should define the first set of pages. A site-wide rewrite because “the copy feels old” creates a large queue without a clear acceptance rule.

Use refresh tiers#

Tier	Example	Required work
1: factual touch	Change a link or product name	Source check and owner approval
2: section change	Update a feature, price, or workflow	Claim review, metadata, and link QA
3: message change	Reposition the page for a new audience	New brief, source set, and performance plan
4: regulated or high-risk	Change a security, legal, or customer claim	Named specialist review and evidence

The tier determines who reviews the page and what cost belongs in the forecast. A Tier 1 link fix should not wait for the same path as a regulated claim. A Tier 3 message change should not be disguised as a small edit.

Build an impact inventory#

For every affected page, list:

page owner and source owner;
claims that mention the changed item;
links and destinations;
screenshots, diagrams, and alt text;
structured metadata;
translated versions;
approval class;
last accepted version;
performance window and baseline.

The source-freshness guide explains why a page can look current while relying on an old fact. The inventory gives the team a way to find related assets before customers find the inconsistency.

Example: one product change, 120 pages#

Suppose a feature name changes:

Asset group	Pages	Review path
Main product pages	18	Product marketing and web
Help and onboarding	44	Product education
Campaign and lifecycle	27	Marketing and lifecycle owners
Regional translations	23	Local reviewers
Partner material	8	Partnerships and legal

The model can draft the replacement string for all 120 pages. That does not mean all 120 have the same decision. Ten may contain a claim about the old feature, five may have a screenshot, and 23 may need local terminology review.

Prioritize by customer exposure and claim risk. Do not spend the same review time on a private draft and a page that drives a high-volume signup path.

Measure the refresh separately#

Track:

pages selected and why;
pages changed;
pages accepted;
pages published;
review minutes by tier;
claims returned;
links or metadata repaired;
translations updated;
pages closed because their value was low;
performance after the new version has a fair window.

Do not count every unchanged page as a completed refresh. A page can pass a text search and still need a source, image, or destination check.

The rework-rate guide gives the return denominator. Use a separate label for a refresh that expands into a new brief so maintenance work does not distort new-content metrics.

Choose when to close an old page#

Some pages should be retired rather than repaired. Close an item when:

its audience no longer exists;
the product path has changed;
the source cannot support the claim;
the page has no useful traffic or destination;
the replacement page is already live;
the owner cannot approve it before its deadline.

Record the reason and redirect or archive decision. A closed page still consumed planning or review time, but the cost is easier to understand when the outcome is explicit.

Keep the previous version available for comparison#

Preserve enough to answer:

what claim changed;
which source caused the change;
who approved the new version;
when the page became live;
whether links, metadata, and translations changed;
how performance was compared.

The old version should not remain customer-visible when it is unsafe. It can remain an internal reference with the source and decision attached.

Deixic can make current agent activity, spend, approvals, and missing evidence visible while a refresh queue is open. Use the product view to identify work waiting on a source or owner, and use the web and analytics systems for publication and performance history.