Your Website Has Too Many Pages Fighting Each Other
Jillian Oco, CMO

Most MSP websites convert worse than they should because too many low-value pages are competing with the handful that actually drive leads. The fix for a site full of thin service pages and old blog posts is not more content, it is consolidating what you have so authority and buyer attention both land on the pages built to convert.
Why most MSP websites are diluting themselves
Years of publishing without pruning leaves most B2B sites carrying a long tail of pages that once seemed worth writing, an old event recap, a service page for something you no longer sell, a blog post covering a topic three newer posts already cover better. Each one dilutes the site instead of adding to it, splitting internal links, search visibility, and buyer attention across near-duplicate content instead of concentrating it on the pages that actually move someone toward a conversion.
This is an architecture problem, not a content-quality problem in isolation. A page can be reasonably well written and still be actively hurting your site if it overlaps heavily with three other pages targeting the same buyer question, none of which are the one page you actually want ranking or being read.
How many of your pages are actually getting any traffic?
Fewer than you would guess. Ahrefs analyzed roughly 14 billion pages from its Content Explorer database and found that 96.55 percent receive zero organic traffic from Google. That figure is a few years old now, but it remains one of the most cited findings in SEO because nothing about how search and AI answer engines select sources has made the problem smaller since. If anything, a shrinking pool of citable, authoritative pages per topic has made it more important which pages on your site are the ones actually representing you.
Suppose an MSP blog has 150 posts and the analytics show meaningful traffic to a dozen of them. The other 138 are not neutral. They are diluting the topical authority that could otherwise be concentrated on the pages worth ranking, and they are giving a buyer or an AI crawler more low-value paths to wander down before reaching a page that actually explains what you sell.
What does Google actually say about this?
It says content that exists mainly to attract search traffic can hurt more than the page itself. In its announcement of the helpful content update, Google described a site-wide signal, under which any content on a site with relatively high amounts of unhelpful content overall is less likely to perform well. That is exactly why a long tail of thin or redundant pages is a structural liability rather than a collection of isolated underperformers.
That single point is the strongest argument for architecture over volume. Publishing another page to compete for a keyword an existing page already targets does not add coverage, it adds another data point suggesting the site is not curating what it publishes carefully. Google's stated systems are built to notice that pattern and discount it, and a discount at the site level touches your best pages too, not just the weak ones.
Does pruning actually work, or is it a myth?
The evidence is directional, though it is not as clean as case studies make it sound. CNET deleted thousands of old articles in 2023, and an analysis of estimated traffic data found a 29% rise in its estimated organic traffic over the following two months. That same write-up notes the turnaround coincided with Ahrefs adding a large number of keywords to its database, so it leaves open whether pruning caused the rise. Google's Danny Sullivan publicly pushed back, writing that the idea that Google dislikes old content is not a thing and that its guidance does not encourage deleting content for that reason.
The honest conclusion sits between those two positions. Pruning is not a traffic hack that guarantees a specific percentage gain, and anyone quoting you a precise number from someone else's case study is oversimplifying a messy result. What consolidation reliably does is remove the structural liability described in Google's own documentation and concentrate internal linking and topical signal on fewer, stronger pages, which is a sound architectural decision independent of exactly how much traffic it recovers. Google's people-first content guidance also lists removing a lot of older content mainly to make a site seem fresh as a warning sign, so prune for overlap and accuracy rather than for freshness.
What to prune, what to consolidate, and what to leave alone
Start by separating three categories instead of treating every low-traffic page the same way. Pages that are simply outdated and no longer accurate should be removed or redirected. Pages that overlap heavily with a stronger page on the same topic should be merged into that stronger page, with the redirect preserving whatever inbound links they had earned. Pages that get low traffic but serve a real, narrow purpose, a specific integration guide or a niche service explainer a small number of the right buyers actually need, should usually be left alone rather than deleted just because a traffic report flags them.
That third category is where teams most often overcorrect. Traffic volume alone is a poor filter for a B2B site where a handful of the right visitors matter more than a large number of casual ones. The filter that matters is whether a page serves a real, current purpose for a real buyer or reader, not whether it hits an arbitrary visit threshold.
| Page condition | Action | Why |
|---|---|---|
| Outdated, no longer accurate | Remove or redirect | Actively misleads readers and crawlers |
| Overlaps a stronger page on the same topic | Consolidate into the stronger page | Splits authority and confuses which page should rank |
| Low traffic, narrow but real purpose | Leave alone | Serves a small, correct audience on purpose |
This is a working checklist, not a rule to apply mechanically to every page in a spreadsheet in one sitting. A page that looks low value by traffic alone can still be the right page to keep if it is the one a specific type of buyer needs at exactly the right moment, so treat the table as a starting filter and confirm with a human read before anything gets deleted or merged.
Architecture that serves buyers and AI answer engines at once
Consolidation and clear site architecture are not separate projects from AI visibility, they are the same project. An AI answer engine choosing which page to cite on a topic favors the same signal a human buyer favors: one clear, current, well-linked page rather than three competing, partially overlapping ones. Fixing the structural dilution problem improves both audiences with the same work, rather than requiring a tradeoff between optimizing for people and optimizing for AI systems.
The internal linking work matters here as much as the deletion work. Once you have consolidated three overlapping pages into one, that surviving page needs to be linked from every other relevant page on the site, not left to rank on its own merits. Internal links are the clearest signal you control directly about which page on a given topic is the one meant to be authoritative, and most MSP sites under-use that signal badly, leaving new visitors and crawlers alike to guess which of several similar pages actually matters most.
Getting an outside, objective read on where that dilution is happening on your own site is worth more than another internal opinion about which old blog posts to keep. ActiScore evaluates site structure and content overlap against exactly this kind of criteria, surfacing where pages are competing with each other instead of reinforcing the ones you actually want buyers and AI systems finding.
Where to start this quarter
Pull a full page-level traffic report going back twelve months and sort by topic rather than by URL. Wherever you see three or more pages clustered on the same buyer question, that cluster is your first consolidation project, regardless of how much total traffic the individual pages show. Fixing the two or three worst clusters on your site will do more for conversion and AI visibility than publishing another ten pages this quarter.
You can map out a full content architecture plan for your own site with the stack builder, and see the rest of the tools built around this kind of work in the product catalog.
See the full stack to see how site structure, conversion, and AI visibility fit together as one system rather than three separate projects.