When to refresh a page and when to retire it

A page review often begins with a vague instruction to update old content. That can produce a lot of editing without resolving whether the page still serves a useful purpose. Some pages need corrected facts. Others need a new structure, a replacement elsewhere or a deliberate retirement. The decision becomes easier when the reviewer separates the reader's task from the age of the text. A recent page can be unhelpful, while an older page can still answer its question well.

Give the review a bounded scope

For an illustrative exercise, choose five pages from a membership organization's help section. Include a current application guide, an old event page, two overlapping eligibility articles and a checklist with an outdated contact link. Create a decision log with the URL, intended reader, current job, factual owner and proposed action. Do not start rewriting yet. The first pass is an inventory of what each page is for and whether someone can explain why it still belongs on the site.

Record evidence separately from interpretation. A broken link is observable. A claim that readers are confused needs supporting information, such as support questions or a small usability exercise. A low number in a reporting system does not explain the cause by itself. Note the time period and limitations of any data used. The decision log should make it possible for another editor to understand why a change was proposed without reconstructing the whole investigation from memory.

Check whether the task still exists

Read the page's opening and ask what the visitor is trying to do. Then ask the relevant team whether that task remains part of the service. The old event page may need an archive treatment because the event has ended but the record remains useful. A discontinued application process may need a different response. The right action depends on the visitor's likely need and the organization's obligation to preserve information, not a simple rule that every old page should be removed.

For the application guide, walk through the process from the reader's perspective. Does the page point to the current form? Are required documents still correct? Is the final step available? A page can have accurate paragraphs and still fail at the handoff to a system that has changed. Record those dependencies and assign an owner. The reviewer should be able to distinguish a copy edit from a service change that requires someone outside the editorial team.

Separate factual drift from a broken explanation

The checklist with an outdated contact link may be a straightforward refresh. Confirm the new route, correct it and check the surrounding instructions. The article's structure may remain useful. By contrast, a guide that mixes first-time applications with renewals may need a more substantial rethink even if all its facts are current. State the problem precisely. “Outdated” is too broad when the actual issue is that two reader journeys have been combined and neither is easy to follow.

Use a simple test script with a colleague unfamiliar with the page. Give them the scenario and ask them to find the next action. Watch where they hesitate and record what they say rather than leading them toward the answer. This is a small editorial exercise, not a claim about all users. It can reveal unclear labels or missing context that a factual review misses. The W3C page structure guidance provides a useful reference when improving the organization of the answer.

Resolve overlapping pages deliberately

The two eligibility articles require a comparison. List the questions each answers, the sources each uses and the links pointing to them. Perhaps one is a short overview and the other covers a distinct exception. In that case, clearer titles and cross-links may be enough. If both attempt to answer the same question with different rules, choose a single source of truth with the policy owner. Merging text before resolving the policy disagreement would only hide the conflict inside a longer page.

When a page is replaced, plan the technical handoff with the publishing team. A permanent redirect has a specific meaning: the resource has moved to another URL. The MDN reference for HTTP 301 explains that behavior. Use an appropriate destination that serves the original reader's need. Sending every retired URL to the homepage can leave the visitor searching again. The editor should document the intended destination and the producer should verify the actual response.

Treat retirement as a publishing decision

Retirement may mean archiving, replacing, redirecting or removing a page, depending on the situation. The decision log should name the chosen action and the reason. An archived event page can clearly show its date and status. A replaced guide can lead to the current process. A page with no continuing purpose may require a removal plan. Consult the relevant owner when records, contractual commitments or other obligations affect retention. The editorial task is to make the decision visible rather than assume that deletion is always the cleanest option.

Before changing anything, check inbound navigation and internal links. A retired page may still appear in a help menu, an email template or a downloadable document. Assign the related updates alongside the page action. Otherwise, the site continues sending people toward a decision it has already reversed. For a small batch, a checklist is enough: source page, destination, navigation links, system references, owner and verification date. The producer can use that record to confirm that the change is complete.

Close the loop after publication

After the refresh or retirement, visit the old route and the new route as a reader. Check the links, status labels and next steps. Ask the factual owner to confirm any changed policy language. If the team used a test scenario before the edit, repeat that scenario and record what improved and what remains unclear. This creates evidence for the decision without turning the review into a promise of search or business performance.

Finish the five-page exercise by giving every remaining page a review owner and a trigger. A trigger might be a policy revision, the next event cycle or a change to the application system. Dates can help, but a named owner and a reason to revisit the page are more useful than an unattended annual reminder. The result should be a small set of defensible decisions: one accurate refresh, one clear archive treatment, a resolved overlap and a publishing record the next editor can use.