Should we prune or merge the underperforming content?

This is a content strategy question — the kind that usually shows up from editorial, SEO lead. It rarely has a one-line answer, because the honest version of “Should we prune or merge the underperforming content” is a shortlist of rival explanations, not a single cause. The job is to work through that shortlist with evidence and stop as soon as one of them is confirmed — not to write a report that mentions all of them.

The rival explanations

Direct answer: A large content inventory needs a four-way sort, not a single delete decision — some posts never earned impressions and never will, some decaying winners just need a refresh, some cannibal groups should collapse onto the strongest URL, and a small set attracts spammy links and should genuinely go.

Treat these as competitors, not a checklist. The point of naming five up front is to stop the first plausible-sounding one from becoming the story before the others have been checked.

• A set of posts never earned impressions and never will (wrong intent or duplicate).
• Decaying winners need refresh, not deletion.
• Cannibal groups should collapse onto the strongest URL.
• Some thin URLs attract spammy links and should go.
• Pruning without redirects will leak the little equity they have.

What the evidence has to show

Direct answer: Sixteen months of GSC clicks/impressions plus GA4 conversions per URL, crawl data on word count/last-modified/inlinks/status, topic clustering to mark cannibal groups, a traffic-trend classification (rising/flat/decaying/never-lived), and a backlink count on kill candidates are what turns a vague 'this feels stale' instinct into a defensible rubric.

None of the five above survives on a hunch. Here is what actually needs pulling before any of them can be ruled in or out:

• Export every URL with 16 months of GSC clicks/impressions + GA4 conversions.
• Crawl: word count, last-mod, inlinks, status, indexability.
• Cluster by topic; mark cannibals.
• Traffic trend: rising / flat / decaying / never-lived.
• Backlink count on candidates for kill.

The decision rule

Direct answer: Keep if it converts or supports a cluster. Improve if it once ranked and intent still exists. Combine cannibals onto the strongest URL with a 301. Kill and 301 (or gone) only if it has no unique intent and no meaningful links. Never mass-delete without a map.

What to tell the people around you

Direct answer: Editorial needs the four-bucket rubric approved, time allocated for the Improve set, and engineering time for the redirect map — not a one-time cleanup sprint with no ongoing process.

The analysis is not finished until it produces something a non-specialist can act on. That means naming the situation, the cost of getting the first move wrong, and a specific ask — not a summary of the investigation.

• Situation — The inventory is now large enough that inaction is a quality decision — just a bad one.
• So what — Unpruned thin URLs drag updates and crawlers. Reckless pruning deletes the wrong assets. The labelled list is the work.
• The ask — Approve the four-bucket rubric. Editorial time for the Improve set. Eng for the redirect map.

SEO labels. Editor confirms. Eng redirects.

How to act on this

1. Export every URL with 16 months of GSC clicks/impressions and GA4 conversions, plus crawl data on word count, last-modified date, inlinks, and status.
2. Cluster URLs by topic to identify cannibal groups competing against each other for the same intent.
3. Classify each URL's traffic trend as rising, flat, decaying, or never-lived.
4. Apply the four-bucket rubric: keep (converts or supports a cluster), improve (once ranked, intent still exists), combine (cannibals onto the strongest URL with a 301), or kill-and-redirect (no unique intent, no meaningful links).
5. Never execute kill/combine decisions without a redirect map — even a low-traffic page can hold link equity worth preserving.

Frequently asked questions

How do we know if a decaying page needs a refresh instead of pruning?

Check whether it once ranked and the underlying search intent still exists. If both are true, it belongs in the improve bucket — refreshing is usually cheaper than losing whatever ranking history the URL retains.

Is zero traffic automatically a kill signal?

Not on its own — check whether the URL supports a cluster (internal links, topical coverage) even without direct traffic, and whether it has meaningful backlinks before deciding it has no unique intent.

What happens to backlinks pointing at a page we want to kill?

That's exactly why the backlink count is checked before killing anything — a page with meaningful inbound links usually gets redirected (or merged) rather than deleted outright, to avoid leaking that equity.

How do we handle two pages that are cannibalizing the same query?

Combine them onto whichever URL is stronger (by traffic, links, or ranking history) with a 301 redirect from the weaker one — competing against your own content for the same query wastes both pages' potential.

Should this be a one-time cleanup or an ongoing process?

Ongoing — content inventories keep growing, so the same four-bucket rubric should run on a recurring cadence rather than treating pruning as a single project.

What if editorial disagrees with a kill recommendation from the data?

The rubric labels a page from evidence, but the editor confirms the final call — this is a deliberate check so a data-only process doesn't delete a page with strategic value the traffic numbers don't capture.

Should older content automatically be treated with more suspicion than newer content?

Age alone isn't the signal — the traffic-trend classification (rising/flat/decaying/never-lived) is what matters, and some older pages remain rising or stable performers that don't belong anywhere near the prune list.

Sources

1. Consolidating duplicate URLs — Search Central
2. Creating helpful, reliable, people-first content
3. Content strategy — Wikipedia
4. Content management — Wikipedia

Where nqzai fits

nqzai runs this same rival-hypothesis framework against your own connected Search Console, Analytics, and audit history, and returns a keep / change / stop decision with the evidence named — including which of the explanations above it could not test, and what to connect to close that gap. No extra cost for the analysis itself; it reads measurements already on file.

Ask nqzai: “Should we prune or merge the underperforming content?”