Should You Merge Thin Pages or Just Make Them Better?
Should You Merge Thin Pages or Just Make Them Better?
Merge two pages when they chase the same question and neither one wins. Improve a page when it owns a distinct question but answers it badly. The test is not word count. It is whether a reader searching for one thing would be happy landing on both.
We get asked this on almost every site revival. A marketing team has published for three or four years, the blog has two hundred posts, and most of them do nothing. Somebody read that thin content hurts the whole site, so the plan becomes a big merge project. Sometimes that is right. Often it destroys pages that were quietly doing a job.
Here is how we decide, and what the source material actually supports.
What Counts as a Thin Page, Really?
A thin page is one that does not add value beyond what a reader could get elsewhere. Length is not the definition. Google Search Central describes thin affiliation as content where "the product descriptions and reviews are copied directly from the original merchant without any original content or added value." The problem is the missing value, not the missing words.
That distinction matters because short pages can be excellent. A 400 word page that answers one narrow question completely, with a real example and a number, is not thin. A 2,000 word page that restates what five other posts already said is thin, and padding it further makes it worse.
Google's own self assessment questions point the same way. It asks whether "the content provide original information, reporting, research, or analysis" and whether content "draws on other sources" while failing to "provide substantial additional value and originality." Those are questions about originality, not length.
Why Do So Many Pages Get No Traffic at All?
Most published pages never get search traffic, and that is normal rather than a crisis. Ahrefs studied its Content Explorer index of around 14 billion pages and reported in December 2023 that "96.55% of all pages in our index get zero traffic from Google." A further 1.94% get between one and ten monthly visits.
We quote that figure carefully. It describes the open web, not a well maintained B2B site, and a page with zero search traffic is not automatically a page with zero value. Sales teams send links. Support teams send links. A page can earn its keep in an email without ever ranking.
What the number does tell you is that having many zero traffic pages is the default state of the internet. It is not by itself evidence that your site has a content quality problem. Treat it as context, not as a verdict.
When Should You Merge Two Pages Into One?
Merge when two pages compete for the same intent and both underperform. The signal we trust most is Google Search Console showing the same query impressing on two URLs, with neither reaching the first page. That is a split signal, and consolidating it usually helps both the ranking and the reader.
The second case for merging is when a reader would be annoyed to find both. If you have one post on picking a CRM and another on CRM selection criteria, nobody wants to read both. They want one page that handles the decision. Merging respects the reader's time.
The third case is maintenance load. Two pages on the same subject drift apart. One gets updated, the other keeps the old pricing or the old screenshot. We have seen a site contradict itself on two URLs that ranked for the same term. That is worse than either page alone.
When Is Improving the Page the Better Call?
Improve rather than merge when the page owns a distinct question that a real person types. A narrow page that ranks on page two for its own query is not a merge candidate. It is a page with a specific job that has not been given enough material to do it well.
We look for three fixable gaps before considering a merge. The page may be missing a direct answer near the top. It may be missing the specifics, meaning named tools, real numbers, and a source. Or it may be missing internal links, so nothing on the site points at it and search engines read it as an orphan.
Fixing those three things is cheaper than a merge and carries none of the redirect risk. It is also reversible. A merge is not, in practice, because the traffic patterns you would need to undo it are gone by the time you notice.
What Does Google Actually Say About Consolidating URLs?
Google's documentation on consolidating duplicate URLs is clear about mechanism, and quieter about strategy. It says consolidation "helps search engines to be able to consolidate the signals they have for the individual URLs (such as links to them) into a single, preferred URL." That is the real benefit: the links pointing at two URLs start counting for one.
On method, Google ranks the options. A redirect is "a strong signal that the target of the redirect should become canonical." A canonical link annotation is also "a strong signal." Inclusion in a sitemap is only "a weak signal." Google also notes that "these methods can stack and thus become more effective when combined."
So if you merge, redirect. Do not simply add a canonical annotation and leave the old page live, and do not rely on removing the URL from your sitemap. We wrote more about the mechanics in our guide to canonical URLs and duplicate content, and the same rules apply to paginated sets, which we covered in our pagination and SEO guide.
Should You Delete a Page Instead?
Deleting is right when a page has no audience, no links, and no future. An event page for a webinar in 2023 with nothing pointing at it can go. Anything with inbound links should be redirected to the closest relevant page instead, because deleting throws away the link signal that Google says consolidation preserves.
Be careful with the middle case. A page with a handful of referring domains and no traffic is not a deletion candidate. It is a redirect candidate. The cost of a redirect is one line of configuration. The cost of a wrong delete is a broken link on somebody else's site that you cannot get back.
| Situation | What we do | Why |
|---|---|---|
| Two pages, same query, both on page two | Merge and redirect the weaker URL | Consolidates link signals into one URL |
| One page, own query, ranks poorly | Improve in place | Reversible, no redirect risk |
| Dated page, no links, no traffic | Delete or redirect to the parent topic | Nothing of value is lost |
| Dated page with referring domains | Redirect, never delete | Keeps external link equity |
How Does This Change Now That AI Answers Read Your Site?
Answer engines change the maths slightly in favour of merging. Systems like Google AI Overviews, ChatGPT, Perplexity, and Claude pull passages, not whole pages. A merged page that answers a question completely in one place gives them a cleaner passage to lift than two half answers spread across two URLs.
It also raises the cost of contradiction. When two of your pages disagree, a retrieval system may surface either one, and you have no control over which. One authoritative page removes that coin flip. We went deeper on how retrieval systems split a page in our piece on page chunking and AI retrieval.
That said, we would not merge two genuinely distinct pages just to feed an answer engine. Distinct questions still deserve distinct pages. The gain is in removing overlap, not in removing coverage.
What Does a Safe Consolidation Process Look Like?
Start by exporting queries and pages from Google Search Console for the last twelve months, then group URLs by the query they share rather than by the folder they sit in. Overlap shows up in queries long before it shows up in your content calendar. Screaming Frog or Semrush can add the internal link and backlink picture.
Next, pick the survivor. The survivor should be the URL with the most referring domains, not the one with the nicest slug, because links are the part you cannot recreate. Move the genuinely useful material from the loser into the survivor, then set a permanent redirect from the loser to the survivor.
Then fix your own links. Google recommends that "when linking within your site, link to the canonical URL rather than a duplicate URL." Leaving internal links pointed at a redirected URL works, but it wastes a hop and it makes future audits confusing. Finally, resubmit the survivor in Search Console so the change gets picked up rather than waiting on a recrawl.
How Do You Know If It Worked?
Judge a consolidation on the combined performance of the pages you merged, measured against what both were doing before. If page A had 40 clicks and page B had 30, the survivor needs to beat 70 to count as a win. Teams often forget the baseline and celebrate a number that is actually a loss.
Give it time. Google has to recrawl both URLs, follow the redirect, and reassign the signals, and on a small site with slow crawl rates that takes weeks rather than days. We would not read anything into the first two weeks, and we would not reverse a merge inside a month.
Watch for the failure mode too. If the survivor loses a query that the merged page used to own, you merged two things that were not the same. That is recoverable early and expensive later, which is the whole reason we start with improving pages rather than merging them.
What Should You Do First This Quarter?
Pull twelve months of Search Console data, find the queries where two of your URLs show up, and count them. If that list is short, you do not have a consolidation project, you have a few pages to improve. Most sites we audit are in that position, and the merge project they were planning would have cost more than it returned.
Build the depth case first as well. Coverage across a topic is what earns authority, and we set out how we think about that in our piece on topical authority.
If you are staring at a few hundred posts and cannot tell which ones are carrying the site, we are happy to walk through how we would triage them. Come and find us at phoenix.studio and we will tell you honestly whether it is a merge job or a writing job.
Want a site that performs like this?
Tell us about your project. We will come back with a clear next step, no pressure.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Have a project like this?
Tell us where you want to go. We'll tell you how we'd get you there.