Pruning thin content: merge, improve, noindex or delete

Large numbers of thin, outdated or overlapping pages can weigh on how search engines see a site. Pruning helps when it is done page by page with data, and hurts when it becomes a mass deletion of anything with low traffic.

DeskSEO editorial team · Nov 8, 2026 · 6 min read

An arborist trims an overgrown branch from a large tree in a sunny park, seen from below

Over the years most sites accumulate pages that nobody would publish today: short news items about events long past, tag pages with one post each, product pages for things discontinued in 2019, duplicate articles written by different people about the same topic, and pages produced quickly to target keywords. Individually each is harmless. Together, on a site where they outnumber the good pages, they can affect how search engines judge the whole site, waste crawling, and make the site worse for visitors.

Pruning means reviewing those pages and deciding, one by one or rule by rule, whether to improve, merge, keep out of the index, or remove them. It is one of the more effective content projects, and also one of the easiest to get badly wrong.

Why it can help

Google has said that its systems assess sites partly as a whole, and that a large amount of unhelpful content can affect how the rest of the site performs. It also recommends removing or improving such content rather than leaving it in place. Separately from any site-wide assessment, pruning has practical benefits:

Merged pages combine links and relevance that were split across several URLs.
Crawlers spend more time on pages that matter; see crawl budget.
Internal search, navigation and related-content blocks show better pages.
Reports become easier to read, because the long tail of near-empty pages disappears.

Why it can hurt

The classic mistake is to export all pages with traffic data, filter "fewer than 10 clicks in 12 months", and delete everything in that list. Pages in that list can still:

Have backlinks that pass value to the rest of the site.
Rank for long-tail queries too small to show up clearly in reports.
Support conversions: a specification page people read before buying.
Be new and simply not have had time to rank.
Be needed by existing customers, even if search does not send traffic.

Low traffic is a reason to look at a page, not a reason to remove it.

An archivist sorts folders into an archive box and a recycling bin in a bright room

Step 1: build the inventory

Create one sheet with every indexable URL from a crawl, joined with:

Clicks and impressions for the last 12 months from Search Console (the API or bulk export handles large sites better than the interface; see Search Console data limits).
Sessions and conversions from analytics, all channels, not just organic.
Referring domains per URL from a backlink tool.
Word count, publish date and last update date.
Content type or section.

Step 2: shortlist candidates

Filter for pages that are weak on several measures at once: low clicks, no conversions, few or no referring domains, old, short or obviously outdated. Then add pages that are not weak on traffic but are problematic on quality: duplicates, near-empty templates, doorway-style pages. Review each candidate by opening it. A page that looks thin in data can be a perfectly good short answer, and a page with decent traffic can be embarrassingly outdated.

Step 3: choose one of four actions

Action	When	How
Improve	Topic matters to your audience and business; the page is just weak	Rewrite with current information and real substance; see refreshing old content
Merge	Several pages cover the same need	Combine the best parts into one page, 301 the others to it, update internal links
Noindex	Users need the page but searchers do not	meta robots noindex; keep it linked where users need it
Remove	No value for anyone, no meaningful links	404 or 410 (or 301 to a close equivalent if one exists); remove internal links and sitemap entries

A useful question for each page: if this page did not exist, would we create it today? If yes, improve it. If yes but it already exists elsewhere, merge. If only for users, noindex. If no, remove.

Typical page types and what usually happens to them

Tag archives with one or two posts: noindex or remove the tags; merge useful tags into categories.
Old event announcements: remove, or merge into a single archive page if they have historical interest.
Short news items that were never updated: remove unless they have links; merge into evergreen articles where the information still matters.
Overlapping blog posts: merge into the strongest one; see keyword cannibalization.
Discontinued products: follow the rules in the out-of-stock guide.
Location or service pages that differ only by a name: consolidate into fewer, genuinely distinct pages; see location pages.
Thank-you, login and utility pages: noindex.
Auto-generated pages from plugins or old features: remove and make sure nothing generates new ones.

A worked example

A hypothetical gardening retailer has a blog with 1,400 posts built up over ten years. The inventory shows that about 900 of them received fewer than five organic clicks in the last year. Opening a sample reveals what they are: 300 short "new in store" announcements for products long gone, 250 tag pages, around 200 posts that overlap with each other ("when to plant tulips" appears in five versions), and 150 thin posts written quickly for keywords.

The decisions look like this. The announcements are removed with 410s, except fourteen that have external links, which are redirected to the relevant category. Tag pages are noindexed and most tags are retired. The overlapping posts are merged into 45 stronger guides, with redirects. Of the thin keyword posts, about a third cover topics customers genuinely ask about and go on the refresh list; the rest are removed. Not one of the 300 posts that bring in most of the traffic is touched.

The blog shrinks to under 500 indexable pages, every one of which someone could defend. Whether rankings rise depends on much more than this project, but crawling, internal linking and the reader's experience all improve immediately, and the merged guides have something to offer that no single old post did.

A note on AI-generated pages

Sites that published large batches of quickly generated articles are now among the most common pruning projects. The content often reads smoothly, which makes it hard to spot in a quick review. Look for pages with no specific detail, no first-hand information, no sources, and the same structure as twenty other pages on the site. Treat them like any other thin content: improve the few that cover something your audience needs, and remove the rest. The AI-assisted content guide covers how to avoid creating the next batch.

Step 4: execute in batches

Work section by section, not all at once. For each batch:

Record the date and the list of URLs with their action.
Implement merges first (content plus redirects), then removals and noindexes.
Update internal links to point to the surviving pages directly.
Remove pruned URLs from XML sitemaps.
Crawl the section to check for broken links and redirect chains created by the changes.

Status codes matter here. A redirect to an unrelated page or to the home page is treated as a soft 404 and wastes the effort; if no close equivalent exists, a 404 or 410 is the honest answer. The HTTP status codes guide covers the details.

Step 5: measure

Compare the section's total organic clicks and the clicks of merged target pages for equal periods before and after, ideally year over year. Watch the Page indexing report for the expected increase in "Not found" and "Page with redirect" entries, and for any unexpected changes. Results from pruning tend to appear over weeks to months; any site-wide effect, if it comes, may only show after search engines have recrawled much of the site.

If a batch causes a clear loss, the inventory lets you see which pages were involved and restore the ones that were carrying traffic or links.

Preventing the next pile

Pruning is a clean-up; prevention is cheaper. Agree on rules for what gets published (no page without a brief and a reader in mind), what gets created automatically (tags, archives, plugin pages), and when content is reviewed. Schedule a light review every year, using the same inventory approach on a smaller scale.

Questions

Will deleting pages improve my rankings?

Sometimes. Removing or consolidating genuinely unhelpful pages can improve how search engines assess the site, and merging overlapping pages often strengthens the survivor. Deleting pages just because they have little traffic, without checking their value, can lose links and long-tail visits.

Is low traffic a reason to remove a page?

Not on its own. Some pages are useful to a small audience, support conversions, or attract links. Low traffic plus low quality plus no other value is the combination that justifies removal.

Should I use noindex or delete?

Use noindex for pages users need but search does not, such as some account or utility pages. For content that has no value for anyone, delete it (404 or 410) or redirect it to a better page.

How many pages should I prune at once?

Work in batches you can measure, for example one section at a time. Removing thousands of pages in one go makes it impossible to tell which change helped or hurt.