When Should You Consolidate Two Pages Instead of Optimising Both?

You have two pages about the same thing. One is three years old, sits on a URL nobody would choose today, and quietly picks up traffic from queries it was never written for. The other went live last quarter, is better written in every visible way, and ranks below it. The proposal on the table is to optimise both.

That is almost always the wrong move. The question worth asking is not which page to improve. It is whether these should still be two pages at all. Content consolidation is unglamorous work, and it is one of the few interventions that changes an outcome rather than decorating one, because it fixes something no amount of on-page editing can reach: a search engine choosing between your own documents, and choosing badly.

What follows is a test with three conditions, the mechanics of merging without losing what the older page already earned, and the case where two pages are correct and consolidating would cost you both. Read that last part before you touch anything. A merge is a one-way door once the redirect is live and the internal links have been rewritten.

The test: three conditions, and you need all three

Merge when all three of these hold at once. Two out of three is a reason to look harder. One on its own is how sites delete pages that were quietly earning, and then spend the next quarter working out what changed.

The intent is the same, not just the topic

Two pages about pricing are not automatically competing. One might answer what something costs; the other might answer how a contract is structured. Same topic, different jobs. Intent is what the reader wants to be holding when they leave, and you can usually name it with a verb: compare, decide, buy, fix, diagnose, learn.

So run the exercise. Without opening either page, write one sentence describing what each one is for. If you write the same sentence twice, the first condition is met. If you write two sentences and have to strain to keep them apart, the condition is met and you are arguing with yourself. Do this before you look at any data, because the data will happily talk you into whichever answer you already prefer.

The queries genuinely overlap

Now the data. Filter search performance by each URL and read the two query lists beside each other. You are not looking for a shared word. You are looking for the same query appearing on both lists, and particularly for the pattern where one URL serves a query on some days and the other serves it on others. That flapping is the clearest evidence available that the engine cannot decide, and it is worth more than any tool’s cannibalisation score.

Position matters as much as overlap. One page near the top of the results and another buried far below it for the same query is usually harmless; the second page is a footnote, not a rival. Two pages stuck in the same middling band, neither of them improving, is the pattern that responds to a merge.

Neither page is winning

The third condition is the one people skip, and it is the one that protects you. If one of the two pages is clearly working, you do not have a consolidation problem. You have a page that works and a page that does not, and the fix is to give the second page a different job or retire it on its own terms.

Consolidation earns its keep when authority is split and neither half is enough on its own: links pointing at one URL, rankings attached to the other, both of them sitting below where a single well-supported page would sit. Merge those and you are adding two halves together. Merge a winner into anything and you are gambling with the half that already pays.

What cannibalisation is, and what it is not

Most cannibalisation findings we are shown are wrong. A tool flags two URLs because they share a keyword, an audit turns that into a row on a slide, and the recommendation arrives as a count of pages to delete. A shared keyword is not a diagnosis. Read that kind of finding the way you would read any other automated one, as a place to look rather than a conclusion; our parent company has written directly about how to read an audit you were sold, and the principle transfers without modification.

Real cannibalisation has symptoms you can see without a tool. The ranking URL for a query changes while neither page changes. A new page fails to take a query that a weaker old page holds on to. A page that used to rank drifts down in the same week another page went live on the same subject. Two of those together are worth investigating. One on its own could be almost anything.

And two pages ranking for one query is not automatically damage. If you hold two places in a result, you own more of that result than one page usually can. The problem is not plurality. The problem is indecision: the engine alternating, splitting the signals and settling on neither. An SEO audit worth paying for names the specific pairs and shows the evidence for each, instead of handing you a number.

Choosing which page survives

The instinct is to keep the better page. That instinct is usually wrong. Keep the URL with the history, then move the better writing into it. Text is portable. The trust attached to a URL is not.

So the survivor is often the older, uglier URL carrying the newer page’s words. That reads as a demotion to whoever wrote the newer page, and it is not one. The exception is a URL that is genuinely wrong in the structure you are keeping, sitting under a section you are removing or spelling a product name you retired. There, take the loss and move once on purpose rather than twice by accident.

Merging substance, not word count

The common failure here is the staple. Two pages get glued end to end, headings and all, and the result is longer than either, worse than either, and slower to answer the query than either. A merged page should come out shorter than the sum and better than both halves.

What to carry across

• The passages the query attaches to. Find the sections of the retiring page that its impressions actually land on, and move those wholesale. They are the reason it ranked at all.
• Anything original. A worked example, a procedure written from doing it, a screenshot of a real interface, a definition somebody wrote instead of borrowing. Original material is the part you cannot regenerate later.
• The questions. Objections, FAQs and the awkward bits. They often sit on the weaker page precisely because it was written closer to a real conversation with a customer.
• The outbound internal links. The retiring page points at other pages on your site. That flow has to survive the merge, or you will quietly demote a third page nobody was thinking about.
• The marks of first-hand experience. Named methods, specific constraints, the details that make a page read as written rather than assembled. This is the substance behind E-E-A-T, and it is the first thing lost in a careless merge.

What to leave behind

Both introductions, because the merged page needs one and it is probably neither of them. Every definition stated twice. The second call to action. Any paragraph that exists to hold a keyword variant rather than to say something. And whichever headings were written for a table of contents instead of for a reader.

The test for keeping a paragraph is whether removing it would make the page answer the query later. If removing it makes the page answer sooner, it was never substance, and it was probably somebody hitting a word count.

The mechanics, in order

Order matters more than speed. Nearly every failure in a consolidation is an ordering failure: the redirect placed before the replacement exists, the internal links updated a fortnight later, the sitemap left pointing at a URL that now answers with a redirect.

1. Snapshot both pages. Record the queries, positions and landing-page sessions each URL currently receives. Without a before, you cannot judge the after, and somebody will eventually ask you to.
2. Publish the merged page on the survivor’s URL. Not a fresh one. A new path means two redirects, no inherited history, and an argument later about whether the merge worked or the move did.
3. Redirect the retired URL permanently. One hop, server-side, straight to the merged page. Never to the homepage and never to a category listing: a redirect that does not answer the original intent gets treated as a removal, and deserves to be.
4. Rewrite every internal link that pointed at the retired URL. Navigation, body links, related cards, footers, old articles, campaign pages. This is the step that gets postponed, and the step that decides whether the merge holds.
5. Update the sitemap. The retired URL comes out. The survivor stays, with an honest last-modified date. A sitemap listing redirects is a sitemap nobody trusts, including you.
6. Ask for the survivor to be recrawled, then leave it alone. Resist the urge to keep editing it while you wait. You cannot read a result you are still changing.
7. Diarise two checks. One soon enough to catch a broken redirect or an orphaned link, one late enough that the ranking has settled. Put both in a calendar, because nobody remembers a consolidation they finished.

Step four deserves more attention than it gets. Technical SEO on a site with a long history is mostly this work: finding every reference to a URL that no longer exists, including the ones in content nobody has opened for years. Search your templates, your content files and your database for the old path, not only for the old page title, and remember that navigation links are usually stored somewhere different from body links.

When two pages are correct

Now the concession, because this advice reverses more often than people who enjoy pruning tend to admit. Plenty of overlapping pairs should stay as pairs, and merging them costs you the better half.

Keep both when the pages sit at different stages of one decision. A comparison page and a product page share vocabulary and share almost nothing in purpose: one is for a reader still choosing a category, the other is for a reader choosing you. Merge them and you get a page that argues with itself, and the reader closest to a decision pays for it.

Keep both when the audience is genuinely different. A page written for a particular place serves people whose questions include availability and proximity, which a national page cannot answer without going vague. Local pages earn their place when they carry information that is actually local, and deserve to be merged the moment they turn out to be the same page with a place name swapped in.

Keep both when the format is the difference: a calculator and an explanation of what the calculator does are not two attempts at one page. And keep both when one of them is not competing for a query at all. A profile page exists so a specific person can be found, understood and contacted, which is the job a profile site like Nichevio is assembled to do from structured, mobile-first widgets. Judge a page like that on whether someone leaves it able to act, not on whether its wording overlaps a service page.

The failure to avoid is merging two pages that serve different stages and calling the result thorough. Pages like that serve one intent adequately and the other badly, and the one they serve badly is usually the one closer to revenue.

How you know it worked

Do not judge a merge by the sessions on the surviving URL, at least not first. Judge it by query coverage: how many distinct queries the survivor now appears for, and whether it has taken the queries that used to belong to the retired page. A merge is working when the survivor starts ranking for things neither page held before, which happens because the combined page finally answers a question completely instead of answering it twice at half strength.

The gap between finishing the work and seeing the ranking is where most programmes lose their nerve. There are honest things to report in that window: coverage restored, redirects resolving in one hop, internal links repointed, the queries the survivor has begun to pick up. We wrote about that problem in reporting SEO progress before the rankings move, and consolidation is the case that needs it most, because the work is done long before the result is visible.

There is a second reason to care about completeness. Assistants and generated answers quote passages, not domains. One page that answers a question fully is easier to quote than two that each answer half of it, which is a quiet argument for consolidation that barely existed a few years ago. Getting quoted in AI answers goes further into how that selection works.

A merge is working when the surviving page ranks for queries neither original page ever held. That signal arrives before the traffic does.

Where we would start

If you have a list of suspected overlaps, do not start with the pair carrying the most traffic. Start with the pair where the intent sentences came out identical and both pages are weak. Nothing is at risk, the mechanics get rehearsed on a page nobody will miss, and you will find out which of your internal links are hard to locate before that discovery costs you anything.

Then a rule for the rest of the list: if you cannot say in one sentence what the merged page is for, you are not ready to merge it. That sentence is the page. If two people on the team write it differently, the disagreement is about the content model rather than the URLs, and a redirect will not settle it.

And the honest reversal: if your site is small and thinly covered, consolidation is not your problem. Publishing is. Merging four pages into two on a site that needs twenty more is tidying an empty room. The teams that get the most out of this work are the ones with years of accumulated pages and no record of who wrote what for which query, which is a content and organic growth problem at least as much as a search one.

If you are staring at a spreadsheet of suspected overlaps and cannot tell which of them are real, tell us which pairs you are looking at. The diagnosis is usually faster than the argument about it.