Keep, fix, merge, or retire

Content Refresh & Consolidation

A useful refresh leaves no module in limbo. The record shows what still earns its place, what needs correction, and what no longer has a job.

Each page is checked against current facts, current audience questions, and its neighbors. Every module then receives a documented decision: preserve, correct, merge, expand, or retire. Every page in the library gets a written keep, fix, merge, or retire decision, backed by the evidence that drove it. Content owners managing an aging library who need a documented reason behind every page that stays, merges, or goes.

Specialist sorting page modules into preserve, correct, merge, expand, and retire decisions

Some of the 500+ brands we've worked with

See all references
  • BMW
  • Mustela
  • Yemek.com
  • Madame Coco
  • Obilet
  • Aksigorta
  • AVVA
  • Amazon
  • Shell
  • Hyundai
  • PepsiCo
  • Red Bull
  • Decathlon
  • MediaMarkt
  • Bayer
  • Sanofi
  • EY
  • KPMG
  • GE
  • 3M
  • Domino’s
  • Lexus
  • Trendyol
  • Hepsiburada

From frozen baseline to release

The evidence behind every keep, merge or retirement

Published claims are checked against approved facts before we examine new questions or overlap elsewhere in the library. Editorial owners decide wording. Domain owners settle facts, while SEO and technical owners approve merges and retirements.

How we hold ourselves to it

  • One decision per module
  • A date is not freshness
  • Merges need an approved destination
  • External movement measured separately

  1. Freeze the current page and its job

    The exact version under review becomes the baseline. Later edits can then be judged against the page's original job and the value it already carried. The content owner confirms the page job and the modules that need explicit protection.

    A versioned baseline of the live page, its primary intent, protected modules, links, and first-party signals.

  2. Diff published claims against approved facts

    The published claim, current approved source, original wording, and review date remain visible in the same comparison. The domain owner confirms the authoritative fact set and whether each discrepancy is material.

    A claim-and-source freshness diff with correct, stale, disputed, and unverifiable states.

  3. Identify new questions and evidence gaps

    Current search, support, sales, and product evidence shows which questions are genuinely new. The strategist approves question validity, priority, and whether this page should answer it.

    A question-and-evidence-gap map with audience, intent, proof need, and proposed destination.

  4. Choose preserve, correct, merge, expand, or retire

    Every module receives one decision and a written reason. When the current version still works, the ledger records the evidence for leaving it alone. Content, SEO, technical, and client owners approve the page job and intervention for each module.

    A module decision ledger with preservation notes, merge targets, and retirement dependencies.

  5. Draft the smallest defensible change

    The revision closes the verified gap. Untouched claims stay untouched, and a new section appears only when a documented question requires one. Domain, editorial, legal, and brand owners approve changes inside their boundary.

    An annotated revision with source, reason, owner, and acceptance check for every material edit.

  6. Release, annotate, and run regression checks

    Factual, link, extraction, accessibility, and page-job checks run again before we start watching external outcomes, which are measured over their own separate period. An independent reviewer decides accept, correct, or roll back without changing the frozen baseline.

    A post-refresh validation report with accepted changes, defects, confounders, and the next review date.

The decisions and the record

A handoff built for the next publishing decision

Publishers receive the decision, its evidence, and the frozen baseline in one place. The same record also shortens the next review.

  • Evidence-led refresh brief

    Page-by-page instructions saying which claim or module to preserve, correct, merge, expand, or retire, and why.

  • Reviewed content and consolidation specification

    Approved copy, canonical destinations, merge instructions, internal-link changes, redirect requirements, and unresolved claims that still need evidence.

  • Freshness, coverage, and preservation measures

    These measures tell us whether the refresh solved the actual maintenance need. Traffic and citation movement stay in a separate report.

  • Post-refresh issue report

    The accepted changes, the defects that surfaced, the confounders we could name, and the next review date. It gets rebuilt at every affected release, with due or disputed claims reviewed monthly and page jobs, owners, and retirement candidates reassessed quarterly.

When aging pages need real decisions

Aging content needs a documented decision for every page

Bring this method into libraries where pages have aged, begun to overlap, or accumulated sections without a clear job. A current page that only needs a better opening answer calls for a smaller edit.

A good fit when

  • A page looks current and reads out of date — Product facts change and sources age while the publish date still looks recent.
  • Refresh means a new date and more words — The team expands pages without a documented question, a source, or a reason the section belongs on this URL.
  • Several URLs are doing one page job — Useful material sits across overlapping URLs, and nobody can say which page stays, which absorbs the rest, or what redirects.
  • The working record already exists somewhere — Live pages, approved facts, old versions, and the questions behind the review are available.
  • Published claims need checking against policy — We check each material fact, cited source, and regulated statement against its review date and owner.
  • Coverage expands only on a validated question — A search, sales, support, or product question needs evidence behind it before we expand the page.
  • Every module carries one named treatment — Preserve, correct, consolidate, expand, or retire, with its evidence and an owner who can reject the call.
  • Every change records where it came from — We record what changed, why, from which source, and how the released version performed against the original page job.

Better handled as other work when

  • You want length added for its own sake — Length alone earns nothing, so useful modules stay protected and expansion needs a documented question with evidence.
  • A newer date is expected to prove freshness — A recent timestamp is metadata. Freshness means the material claims, sources, and page job have actually been reviewed.
  • You want post-refresh movement credited — Ranking, citation, referral, and conversion move for other reasons, so none of it excuses a factual or usability defect.

People who watch how AI cites a brand

GEO work starts with recording what AI answers actually say about a brand today, then moves to the parts you can influence. The consultants below work on the specific capability this page covers.

Tools we use

Tools behind this work

  • Ahrefs

    shows what a retirement would cost in external links, before a destination is approved

  • Screaming Frog

    checks every page against its neighbors in one pass, the overlap this method decides on

  • Sitebulb

    maps duplicate modules across URLs, which is the overlap evidence a merge decision needs

  • Google Search Console

    the traffic history this page's own FAQ says is evidence, but not a keep decision on its own

  • Airtable

    holds the named treatment for every page alongside the evidence behind it

  • Google Analytics

    supplies the first-party value evidence, which this page refuses to treat as an automatic keep

A recent date is not evidence of freshness

Put the next content decision on record

Share the current library, its approved facts, and the questions reaching your team. The review will show what stays, what needs correction, and where an approved merge path exists.
Review your content library

Questions we hear

How do you decide whether to update, merge, or delete a page?

We look at the page's current job, factual freshness, question coverage, overlap with its neighbors, and any proven first-party value. The evidence may support an update, a merge, retirement, or a documented decision to leave the module alone.

Will you keep content just because it still gets traffic?

Not automatically. Traffic can be useful evidence that a page still serves a need, but it doesn't excuse a stale claim. We preserve the useful part, correct the facts, and only merge or retire when the user path has a verified destination.

Does changing the publish date count as a refresh?

Without a review of its material claims, sources, and page job, changing the date alone does not refresh a page and leaves you with nothing more than new metadata.

How do you stop a consolidation from losing useful content?

We freeze the baseline first, so nothing about the original page can get quietly redefined mid-project. Every module we're keeping gets flagged as protected before any edit starts. Anything we remove still gets mapped to an approved destination before it goes. Before release, we replay the same link, extraction, accessibility, and page-job checks we run on every refresh.