Which Page Survives a Merge? Not the One With More Clicks

When two of your pages genuinely compete for one query and one of them has to go, keep the page with the stronger footprint on that query, not the page with more clicks overall. Total clicks measure every search a page already wins. The contested query is the only one the merge is actually about.

This post gives you the four signals to read on that one query, the two inputs Search Console structurally cannot hand you, and the honest finding from a live account: this decision comes up far less often than the checklists imply.

TL;DR:

• Total clicks are the wrong tiebreak. They aggregate every query the page ranks for, and Google reports position as "the topmost position occupied by a link to your property or page in search results, averaged across all queries." Both numbers are blended across searches the merge has nothing to do with.
• Read four signals on the contested query alone: position, impressions, whether the page genuinely answers it, and what the losing URL would take with it.
• The two inputs that most often overturn the call, conversions and links, are not in Search Console. Settle the ranking half there, then check the other half somewhere else.
• On a live account with 257 known URLs and roughly 60,000 impressions in 28 days, the number of genuine merge decisions waiting right now is zero.

Which page should survive when two of yours compete?

The one that owns the contested query, judged on that query alone. Pull the page-and-query view for the search in question, then compare the two candidates on their position and impressions for that specific query. The page with the better standing there is your survivor, even when the site-wide totals point the other way.

Before you get this far, two checks have to pass. Collapse the competing URLs at the # first, because anchor and fragment rows inflate the count and a merge instruction is actively wrong when there was only ever one page. Then confirm the pages serve the same intent, which is the gate that decides whether this is a real conflict at all. Only after both pass does the survivor question mean anything.

Why is "keep the better page" the wrong instruction?

Because "better" is never defined, and the number closest to hand is the wrong one. Nearly every cannibalization guide says to keep the strongest or best-performing page. Read literally, that points you at the page with more total clicks, which is a measure of every other query that page wins and says nothing about the one you are resolving.

Picture two pages splitting one query. Page A has 400 clicks a month and sits at position 14 for the contested search. Page B has 60 clicks and sits at position 6 for it. Page A is the better page by every dashboard summary. Page B is the one Google already prefers for the query you are trying to win, and folding B into A means asking Google to re-learn a ranking it has already awarded.

The reason the shortcut fails is baked into how the metrics are built. Google defines position as the topmost placement "averaged across all queries," so a page's headline position is a blend that can hide a strong ranking behind a hundred weak ones, or the reverse. Clicks work the same way. A page total is a sum across searches, and the merge concerns exactly one of them.

How do you read the contested query in Search Console?

Filter to the query, switch to the pages view, and read both candidates side by side. Four signals decide it, and they are worth taking in order, because the first two are numeric and the last two are judgment that the data can only inform.

• Position on the contested query. Not the page's average. The query-level rank tells you which URL Google currently considers the better answer, and that is the single strongest input you have.
• Impressions on the contested query. Which page does Google actually put in front of people for this search, and how often? A page that ranks slightly worse but is shown far more is doing the real work.
• Whether the page genuinely answers the query. Covering a topic and mentioning it are different things. If the better-ranking page only mentions the subject while the other one answers it properly, you are choosing between a URL with standing and a URL with substance, and the honest move is often to keep the standing and move the substance into it.
• What the losing URL takes with it. This is the cost nobody computes. A merge does not just resolve one query, it retires a URL that may be earning impressions on dozens of others. Before you redirect a page, read its full query list. Retiring a URL that ranks for one contested query and forty uncontested ones to win a single search is a bad trade, and it is invisible if you only look at the query you came for.

That fourth signal is the one that flips real decisions most often. A page can lose the contested query outright and still be the page you keep, because it is quietly earning on a long tail the other one has never touched.

What can't Search Console tell you about this decision?

The two inputs most likely to overturn your call. Search Console stops at the click, so it cannot tell you which page converts, and it has no view of the web pointing at you, so it cannot tell you which page carries the links. Either one can outrank every signal above, and neither is in the data.

Conversions. Two pages splitting a query can convert at wildly different rates, and the one earning fewer clicks is sometimes the one worth keeping. A comparison page pulling 60 clicks that turn into trials beats a guide pulling 400 that turn into nothing. That read lives in your analytics or your own product data, and if the two pages have genuinely different commercial jobs, you should probably be differentiating rather than merging, which is the same call the wrong-intent check makes across your pages.

Links. Redirects pass signals, but a page that has accumulated real external links over years is a stronger foundation than one that has not, and Search Console shows you none of that. Check it wherever you track links before you decide the direction of the redirect, because getting this backwards is the version of the mistake that is expensive to reverse.

Two more limits ride along, and they are the same ones that shape every conflict list you will ever read. Query-level counts under-report, because Google drops rare queries from the tables while still counting them in your totals, so read volume at the page level and use the query view for the comparison, not the sum. And the page-and-query join is the view Google degrades most, for privacy and for compute, so the conflict never looked complete to begin with.

How often do you actually have to make this call?

Less often than the volume of advice suggests. We read a live SaaS account through QueryScope every day: 257 known URLs, roughly 60,000 impressions in the last 28 days, a real content library with a real long tail. The number of genuine two-page conflicts sitting in its queue right now is zero.

That is not because the check never fires. It has fired twice, and both were false alarms. One was nine URLs competing for a single query that turned out to be one blog post and its own section anchors. The other was the brand name returning the homepage, the about page, a tool page, and the blog index together at position 1, with the homepage taking every click, which is Google handing one site a block of results for its own name and working exactly as intended.

So the practical shape of this is worth stating plainly. The survivor decision is real and it matters when it lands, but most of what gets flagged as cannibalization dissolves under the three gates before you ever reach it. If you find yourself making this call weekly, the more likely explanation is a counting problem, not a content problem.

What happens after you pick the survivor?

You fold the best of the loser into the winner and redirect, then you wait, because the change has to be re-crawled and re-scored before anything moves. Google's guidance is direct about the method: use a permanent redirect, and prefer server-side redirects for "the quickest effect."

The mechanics of the fold are their own job and the decaying-page playbook covers them, including the one that bites most often: redirect straight to the final URL rather than through a chain of hops. What is worth adding here is the part that catches people after the work is done. Your redirect is a strong signal but not a command. Google states that "indicating a canonical preference is a hint, not a rule," and that it "may choose a different page as canonical than you do, for various reasons." Redirects, sitemap presence, HTTPS, and rel="canonical" all feed that choice.

Then measure the contested query, not the page. The whole point of the merge was to stop splitting one search, so the number that proves it worked is that query's position and clicks on the surviving URL. A page total will move for a dozen unrelated reasons and tell you nothing about whether the merge did its job.

Making the call without reading every query by hand

By hand this is slow enough that it usually goes unmade. You filter to a query, switch views, compare two URLs, then open each page's full query list to work out what a redirect would cost you, and then you do it again for the next candidate. That last step is the one that gets skipped, which is how pages get retired for a query they were never really losing.

QueryScope reads it from your editor instead. It groups your URLs by query, applies the numeric gates before it says anything, and collapses fragments to documents first, so what reaches you is a short list worth actual judgment rather than a pile of counting artifacts. It leaves the intent call to you, because that gate is not in the data, and it is honest about the ceiling: it can show you two pages splitting a query, not whether merging them will win it. For the one-line meaning of position or impressions, the Search Console glossary defines each metric with its caveat.

Sources

• Google Search Console Help, What are impressions, position, and clicks? (position is "the topmost position occupied by a link to your property or page in search results, averaged across all queries").
• Google Search Central, What is URL canonicalization ("indicating a canonical preference is a hint, not a rule"; "Google may choose a different page as canonical than you do, for various reasons"; canonicalization factors include "whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel="canonical" link annotations").
• Google Search Central, How to specify a canonical URL with rel="canonical" and other methods (on removing duplicate pages: "All permanent redirection methods have the same effect on Google Search"; "For the quickest effect, use HTTP (also known as server-side) redirects"; without a specified canonical, "Google will identify which version of the URL is objectively the best version to show to users in Search").