Callum.REditor
Do not ask a writer to ‘refresh this page’. Give them a precise update brief that says what is wrong, what still works, what must change and how the finished public page will be checked. An existing URL already has a purpose, internal links, source references and readers who may depend on it. Rewriting without examining those assets can replace a useful answer with a tidier but weaker one. A small UK agency can prepare a workable brief from the current page, verified evidence and a short set of editorial decisions. The aim is to fix a demonstrated problem, not merely make the wording different or change the date.
State why the page is being reviewed
Record the trigger: outdated facts, weak coverage, changed services, overlapping content or another evidenced issue. This gives the writer a reason for editing and prevents generic rewriting whose only purpose is to make the copy different.
Open the existing published page and identify the exact reader task it currently serves. Write the problem in one sentence: ‘The service page no longer explains the approved eligibility conditions’ or ‘The migration guide refers to an interface that the provider has replaced’. A declining search chart alone is not a sufficient diagnosis. It might reflect lower demand, a new search layout, a technical exclusion or competition rather than inadequate prose. If a crawl reports an issue, capture the exact URL and test the public behaviour before turning the warning into a rewrite brief.
Record when the issue was observed, who supplied it and which pages or customer enquiries it affects. Distinguish a factual correction from an expansion of scope. A page about checking redirects should not quietly become a generic migration sales page simply because someone identified another commercial phrase. Where the trigger is a product or policy change, establish the source version and date. A good brief gives the writer a solvable problem and the approver a clear reason to spend time on it.
Identify what should be preserved
Mark explanations, examples, structure or links that remain useful. Existing strengths are part of the brief. Without this step, a writer may remove good material simply because they assume every sentence is open for replacement.
Review the article section by section. Note which procedures remain accurate, which examples still illustrate the decision and which links reach appropriate current resources. Identify a useful comparison table, source-backed caveat or customer explanation that should survive. If an article includes a relevant licensed diagram, preserve its source, creator, licence and meaningful alternative text. An unrelated visual may be removed for a documented reason, but there is no value in discarding a correct diagram just to change the page's appearance.
Keep the URL, canonical purpose and navigation relationships in the brief. Existing links from other guides may rely on the page's specific answer. When the writer revises headings, check whether links using fragments or descriptions still make sense. Replacing technical instructions with broad promotional language can create a misleading destination even when the HTTP response is successful. Mark material that should remain untouched until a subject reviewer provides stronger evidence. Preservation does not mean freezing mistakes; it means changing only what has a good editorial or factual reason.
Ask the editor to distinguish retained material from newly researched additions in the internal review copy, without displaying internal labels publicly. This lets the reviewer see what changed and reduces the risk of accidental content loss. It also gives future maintainers a record of why a page still contains particular explanations after a substantial update.
List factual claims that need rechecking
Highlight dated, product-specific or externally attributed information. Provide suitable sources where available and require unsupported claims to be removed or qualified rather than refreshed with equally unsupported alternatives.
Build a small claim list with the original wording, proposed change, primary evidence, applicable jurisdiction or product version and reviewer. For search-engine mechanisms, Google Search Central's canonical documentation is appropriate evidence about duplicate URL signals; it cannot prove that a client's own implementation works. A company's approved service records may establish what it offers but cannot establish a universal search ranking outcome. Keep source type and inference apart. The writer should never turn a conditional recommendation into a guaranteed result.
Check dates that matter, not merely those that appear old. An evergreen explanation of how ordinary hyperlinks work might still be accurate, while a screenshot showing a discontinued console menu could mislead readers. When official guidance has changed, note the change accurately and avoid inventing effective dates. Google cautions against changing publication dates or adding and removing copy merely to make content appear fresh in its people-first content guidance. If research cannot confirm a material claim, mark it unresolved and keep it out of approved public copy.
Do not fabricate customer results, professional credentials, costs or dates in order to meet an update deadline. Where the client must verify its own service information, identify the authorised contact and what they need to confirm. A source link is valuable only if it actually supports the statement beside it.
Explain gaps in reader usefulness
Describe what a reader cannot currently understand or decide after using the page. These gaps give the update editorial direction and are more useful than a list of additional keywords to insert.
Set out the intended reader, starting knowledge and practical outcome. A business owner reading about redirects may need to know why an old URL should lead to a genuinely relevant successor rather than the homepage. A developer may need to know which response and rendered destination to test. Their questions overlap, but the required depth differs. Identify which audience the existing page is intended to serve and what additional explanation, comparison or procedure would make it complete.
Ask for information gain rather than generic length. The useful addition might be a worked decision sequence, clear limitations, an explanation of failure conditions or an accessible comparison of two genuinely different approaches. A paragraph restating that SEO matters does not solve a practical gap. Likewise, adding a large list of keyword variations makes a page harder to read without improving the answer. A comparison must name the decision, use equivalent row criteria and explain when each option applies. Where credible numerical evidence is absent, use a qualitative comparison rather than invented percentages.
Define a final task for the reviewer: after reading the revised article, can a person identify the appropriate next action and recognise where more evidence is needed? A page about an audit should not imply that every detected warning needs fixing; it should distinguish reproduced defects from speculative findings. The best revised sections make the decision easier rather than simply expanding the word count.
Address overlap with neighbouring pages
If another page covers similar material, define the boundary between them. The update may need to differentiate the page, consolidate information or reduce duplicated sections. Do not let both pages expand into the same territory independently.
Review the actual text of nearby resources, not just their titles or target keywords. A service page describing a real agency audit and an educational article showing how to perform one can legitimately coexist. Two introductory articles with the same answer, examples and next step may not. Write down each page's primary purpose and what it adds. Keep useful specialist depth where it serves a different reader; combine genuinely repetitive material only through a deliberate editorial decision.
If consolidation is approved, retain independently valuable information, select a meaningful successor and plan relevant redirects and internal link changes. Google's site-move guidance recommends mapping old URLs to appropriate new destinations and avoiding irrelevant blanket redirects. It does not promise identical rankings after a merge. The content brief should identify which team owns URL implementation; the writer may not be authorised to alter the server. Do not move an existing slug for cosmetic keyword reasons.
When pages remain separate, make their relationship navigable. Use descriptive links that lead from an overview to deeper instructions or from a guide to a genuinely relevant service. Check the targets rather than inserting generic ‘read more’ anchors. The goal is a coherent content library with identifiable responsibilities, not a larger number of loosely connected URLs.
Define the acceptance test
State what should be true when the update is complete: facts verified, missing decisions addressed, preserved material retained and page purpose clear. This makes review more objective than judging whether the new version simply sounds fresher.
Write acceptance criteria before the writer begins: the current H1 and title still represent the page; retained material remains; each changed factual claim has suitable support; the identified reader question is answered; and source links, imagery, comparison and FAQ are relevant. Assign an editor and factual reviewer, and specify who has authority to approve commercial or technical claims. For a significant update, maintain a concise record of what was changed, which sources were checked and which limitations remain unresolved.
Then separate editorial completion from production acceptance. A saved CMS record, or even a native database UPDATE and READ-BACK, establishes data persistence; it does not prove the public renderer includes every field or that images, tables and forms work. Check the actual canonical page when authorised tools are available, including mobile widths, keyboard interaction, internal links and the appropriate customer action. If such testing is unavailable, record the specific unverified item rather than reporting a full pass. Public editor notes must remain restricted to internal systems.
Finish with the smallest defensible action. If one factual paragraph is wrong, correct and verify it rather than rewriting the whole page. If the article genuinely lacks critical information, commission the substantive addition with an owner and evidence. If its purpose has disappeared, make an approved lifecycle decision rather than disguising deletion as a refresh. A useful brief names the problem, protects the good material and states exactly what improvement will count as success.