Content pruning: what to do with pages that do not belong

What content pruning is, and the six verdicts a page can get

Content pruning gives every page already on your site one verdict: keep, update, merge, redirect, remove or noindex. Each verdict does something different to three things: the page's address, its words, and the links that point at it.

The word comes from gardening, but the job is closer to editing a catalog. The goal is not a smaller site. The goal is that every address on the site has a job, and that no two addresses do the same job.

Three words in that table need a plain meaning. A 301 is a permanent redirect: anyone who asks for the old address is sent to the new one. A 404 or a 410 is the answer a server gives when a page is gone. A noindex tag is a line in the page's code that asks search engines to leave the page out of their results.

Three facts about those verdicts matter as much as the table, and none of the seven pruning guides I read on 13 November 2026 explains all three.

• 404 and 410 do the same job in Google. Google's documentation on HTTP status codes says all 4xx errors except 429 "are treated the same": the URL leaves the index and Google crawls it less over time. Bing asks for a 404 and a notice through IndexNow. Pick either code. What matters is that a removed page does not return 200 with a "not found" message, which Google calls a soft 404.
• A 301 is a strong signal, a 302 a weak one. Google's crawlers follow up to 10 redirects in a row (hops) and treat a 301 as a "strong" signal that the target should be processed in place of the old address. Bing's webmaster guidelines keep 302s for changes shorter than 2 days, and ask for redirects instead of canonical tags (a tag that only names which of two similar pages is the main one).
• A noindex that stays turns into a nofollow. In a December 2017 Google webmaster video, reported by Search Engine Roundtable, John Mueller of Google explained that once a page carries noindex long enough, "we won't follow the links anyway". So noindex is for pages people need, like a thank-you page after a form. It is not a place to park off-topic posts.

Two pages that answer the same search is a special case of merge, with its own lesson: keyword cannibalization.

Why every page needs a purpose, and where off-topic pages come from

Every page on a site needs a purpose: a search your customers make, answered on a page that feeds what you sell. That is the standard I hold every page to, and one origin of the pages that fail it is worth knowing first.

In my words, "Any website that's worked with a bad agency before has a large percentage of off-topic posts". The agency "just worked to publish as much as possible ... because that's what was in the retainer, but that's not how SEO is done properly. It's about making sure the website is a quality website and every single page has a purpose on that website. If a page does not have a purpose, it does not deserve to be on the website."

How much of a site is off topic really depends, so I will not give you a percentage. A roofer whose old agency wrote barbecue recipes to hit a monthly post count will find plenty. A clinic that only ever wrote about its own treatments may find none.

Google describes the same habit from the other side. Its guide to helpful content lists as a warning sign "producing lots of content on many different topics in hopes that some of it might perform well in search results". A retainer paid per post rewards exactly that.

A purpose has two halves, and you can check both against a topical map:

• It answers a search your customers make. The map has a row for it, with the one search the page is built for. Who your customers are follows from your source context: what the site exists to do and how it makes money.
• It feeds a page that sells. It sits in the core section, with the pages that sell, or it links into the core from the outer section, with the pages that answer questions around it. The split is explained in core section and outer section.

A page can fail the test and still hold something useful: a good paragraph, a real example, a photo of a job. That is why my first check is never "delete it". It is whether the page can be merged into a page that is more relevant, because many off-topic posts "could have been part of another post".

How to tell an off-topic page from a weak one

An off-topic page fails the map test: no row on your map would hold it, and the searches it gets come from people who are not your customers. A weak page passes the map test and fails the search test: the right subject, answered badly.

The difference decides the verdict. An off-topic page is merged into a more relevant page, redirected or removed. A weak page is updated. Mixing them up is a costly mistake, because a weak page you delete is a page your map needed.

You can read the difference in Search Console. Open the Performance report, filter by the page, and look at the Queries tab.

• Off topic: the searches have nothing to do with what you sell. On a made-up roofer's blog, a barbecue post gets "smoked brisket recipe" and "dry rub for ribs".
• Weak: the searches are your customers' searches, but the page sits on page two or lower, or shows often and is rarely clicked. The same made-up roofer's post on signs you need a new roof gets that exact search, at an average position of 18.
• Not judged yet: a page with a row on the map but no impressions over 16 months is new, hidden or not indexed. Check that it is indexed and that at least one of your pages links to it before you judge it. An off-topic page with no traffic fails the map test either way.

A published split test shows what is at stake. On 11 April 2025 SearchPilot, a company that sells SEO split testing, wrote up a test on thin nutrition pages of a large retailer ("The SEO impact of enriching page content"). The retailer's team had leaned toward removing them and redirecting their addresses to the product pages. An earlier test had shown the two page types served different needs, so the thin pages were enriched instead, with a specification table and related products.

Organic traffic to those pages rose by nearly 20%. Their click rate went from 3.43% to 4.27%, while the untouched group fell from 4.91% to 3.53%. SearchPilot's own reading: the pages were "underperforming due to content limitations, not intent mismatch". Those pages were on topic all along. They were weak, and the test shows what happens when a weak page is mistaken for one that has to go.

There is a hint that Google measures the off-topic half. Google's internal documentation that leaked in 2024 has a field called siteRadius, "the measure of how far page_embeddings deviate from the site_embedding": how far each page drifts from what the site is about. Google has not said how it is used. Read it as context for the map test, not proof that drift is punished.

One case sits between the two: a page that answers your customers' search, but the same search as another page. It is neither weak nor off topic. It is a duplicate, and the fix is a merge. Whether a search deserves a page at all is covered in when a search deserves its own page.

How to audit a site by hand against its map

List every URL, give each one the map row it belongs to, and add five facts per URL from free tools: 16 months of clicks and impressions, its top searches, the sites that link to it, the leads or sales it starts, and the internal links pointing at it. Add AI citations if you can get them.

You need the map first. A topical map is the plan of every page your site needs, and without one a cleanup is a guess about what the site is for. If you do not have one yet, the steps are in how to build a topical map.

1. List every URL. Combine three lists, because each one misses pages: your XML sitemap, the Pages tab of Search Console's Performance report, and a crawl of the site with any crawler. Old posts that nothing links to often show up only in the sitemap or in Search Console.
2. Give each URL its map row, or "none". This is the first column, before any number. A URL with a row passes the map test. A URL with "none" is off topic until you find a row it could join.
3. Pull 16 months from Search Console. Clicks, impressions and average position for each page, over the full 16 months Search Console keeps, a window Google introduced in 2018. Three months hides seasonal pages: a post about ice dams looks dead in July.
4. Note each page's top searches. From the Queries tab, filtered to that page. This is how you tell off topic from weak.
5. Count the sites linking to it. Search Console's Links report lists your top linked pages and the sites that link to each one. A page that relevant sites cite never goes without a merge or an honest redirect.
6. Add the leads or sales it starts. In GA4 (Google Analytics), the landing page report with your key events (form sends, calls, purchases) shows which pages start the visits that convert.
7. Check AI citations if you can. Bing Webmaster Tools' AI Performance report, released as a preview in February 2026, counts how often each page is cited as a source in Copilot and Bing's AI answers. A page that AI answers quote has a job, even with few clicks.
8. Count the internal links pointing at it. A crawler reports them. A page with none may be failing only because nobody can reach it.

The columns, in this order, are in the audit sheet at the end of this lesson, with a worked example filled in.

The decision path that gives every URL one verdict

Ask the questions in order and stop at the first one that sends the page somewhere. Does the page belong on the map? If it does, does another page answer the same need, and does this one serve its search well? If it does not, can it merge, do people still need it outside search, and can a relevant page take its links?

Two choices in that path matter more than the rest.

• Merge comes before delete, on both branches. On a page that belongs, a merge fixes a duplicate. On a page that does not, a merge saves whatever it says that a more relevant page can use. Koray Tuğberk Gübür calls the result ranking signal consolidation: signals that were split across pages gather on one. In a March 2024 case write-up the first block of his advice is about cutting pages, including "Decrease the total page number to prevent ranking signal dilution."
• A redirect has to be honest. Ask whether a person following one of the page's links would accept the target as their answer. A barbecue post redirected to a roof replacement page fails that test, and so does a redirect to the homepage. Google's 2011 note on 404s names a site that redirects missing pages to its home page as an example of a soft 404, and its crawling help says to return a 404 or 410 when "there's no replacement page on your site with similar content".

The other exits follow from the table at the top. A page that belongs, has no duplicate and serves its search well is kept. A page that belongs and serves its search badly is updated. Noindex comes before the redirect on purpose: a page people still use, like a thank-you page after a form or a page for a print campaign, keeps working even if something links to it. A page that does not belong, holds nothing worth moving, is needed by nobody outside search and has no honest redirect target is removed.

What librarians learned about weeding that applies to your pages

Libraries have weeded their shelves by a written method, CREW, since 1976. The method, published by the Texas State Library and Archives Commission, weighs three things about each book: its age, its use, and six faults known as MUSTIE. The sixth fault, "Elsewhere", is the library's closest thing to merge first: a book can go when what it holds is available somewhere else. On a site, "somewhere else" is the more relevant page, and the merge is how you make sure it is there.

MUSTIE stands for Misleading, Ugly, Superseded, Trivial, Irrelevant and Elsewhere. The 2008 edition of the CREW manual defines each fault. The verdicts beside them are my reading for web pages, not part of CREW.

Three more lines from the manual fit a website almost word for word.

• Age is one lens of three. CREW's formula "8/3/MUSTIE" means: consider a book when its copyright is more than eight years old "and/or" it has not been used in three years "and/or" it has a MUSTIE fault. Age alone is a reason to look, never a verdict. That is the mistake in pruning by publish date.
• Fix the catalog before you judge the book. "It is perfectly acceptable to recatalog a book to make it more accessible to patrons." On a site, a page with no traffic and no internal links may be hidden, not useless. Link it from the right page first.
• Keep your local history. CREW's exceptions relate "mainly to items with local history value". On a site, that is anything only you can publish: your case studies, your own data, photos of your own jobs. Low traffic is no reason to delete those.

Above all of it, the manual puts judgment: "guidelines are not intended to act as a substitute for professional judgment calls and common sense." The American Library Association's policy toolkit says the same, that some titles "may be worth keeping on the shelves despite low usage statistics".

The checks to run before you delete or redirect a page

Before a page goes, check six things: the sites that link to it, the leads or sales it starts, a full 16 months of traffic, citations in AI answers, uses outside search, and the internal links and old redirects pointing at it. Any one of them can turn a remove into a redirect or an update.

Most pages that vanish from the web are deleted by owners whose sites are still running. The Pew Research Center checked a sample of nearly a million pages collected between 2013 and 2023. By October 2023, 25% were gone, and 16% of the sample were single pages removed from websites that still worked. Of the pages from 2013, 38% had disappeared.

Those dead links were someone else's citations. Pew found at least one broken link on 23% of news pages and 21% of government pages, and a dead reference link on 54% of Wikipedia pages. Legal writing shows how common it is: in 2014 Jonathan Zittrain, Kendra Albert and Lawrence Lessig found that more than 70% of the URLs in three Harvard law journals, and 50% of the URLs in U.S. Supreme Court opinions, no longer led to the information cited.

So run the six checks, in this order:

• Links from other sites. Search Console's Links report, under top linked pages. A page with relevant links gets a merge or an honest redirect, never a bare 404.
• Leads and sales. GA4's landing pages with key events. A page can start visits that convert weeks later on another page, so a guide with no sales of its own can still earn its place.
• 16 months of traffic. A page with no clicks since spring can be your best page every winter.
• AI citations. Bing Webmaster Tools' AI Performance report counts them per page.
• Uses outside search. Links in your emails, ads, flyers, QR codes, PDFs and partner sites. Search Console cannot see these, so ask whoever runs them.
• Internal links and old redirects. Every internal link to the page has to change, and every older redirect that points at it has to be pointed past it, or you build a chain.

One check is on you, not the data: legal and policy pages (privacy, terms, returns) fail every traffic test and stay anyway.

How to merge two pages without losing what the old one earned

Keep the stronger address, move in only what the retired page adds, and redirect it with a 301. Then point every internal link and every older redirect straight at the page that stays, so nothing runs through a chain.

1. Pick the page that stays. The one with more sites linking to it, then the better position for the shared search, then the cleaner address. If Google shows a different kind of page for that search, such as a service page or a collection, the keeper should be that kind.
2. Move only what the retired page adds. A fact, an example, a table, a photo of a real job, a question its visitors asked. Leave out what repeats. Put each addition where it answers a question, not in a block at the bottom.
3. Redirect the retired address with a 301. One hop, straight to the page that stays.
4. Point the internal links at the keeper. Every link to the retired page now goes to the page that stays, with the keeper's own name as the words of the link. How those links should run is in internal links inside a topical map.
5. Update the older redirects. If an even older address already redirects to the retired page, change it to point at the keeper. Otherwise you build a chain: old address to retired page to keeper. Google's crawlers stop after 10 hops, and every extra hop is one more place to break.
6. Update the sitemap and tell the engines. Take the retired address out of your XML sitemap, as Bing asks. IndexNow, used by Bing and other engines but not by Google, accepts added, updated and deleted addresses in one request.
7. Write down the date. You need it to read the result.

Two things decide whether a merge keeps what the old page earned.

• The target has to be about the same thing. A Google patent from a 2003 filing, granted in 2013, with Jeffrey Dean and Paul Haahr among its inventors, describes a page whose text "differs significantly from the anchor text associated with its back links", meaning the words other sites used to link to it. Links from before that change "may then be ignored or discounted." Its case is a different one, an expired domain bought by someone new, and Google Patents lists the original 2003 filing as expired. I read it as a hint that old links can stop counting when the page they point at no longer matches them, not as proof. It points the same way as my rule to merge into a page that is more relevant, not just a page that exists.
• A merge must add, not disguise. Google's best practices for news article pages call it "against our guidelines to create a very slightly updated story from a previously published one, then delete the old story and redirect to the new one." That rule is written for news publishers, but the shape is the same on any site: folding two weak posts into one page that is no better than either is a disguise, not a merge.

What a real update is, and why a new date is not one

A real update changes what the page says: facts corrected, a missing answer added, an example replaced, the page re-aimed at its row on the map. A new date, a new sidebar or a few changed words at the edges is not an update.

Google says so in its guide to helpful content. Among its warning signs is this question: "Are you changing the date of pages to make them seem fresh when the content has not substantially changed?" The next one asks whether you add or remove content to make the site seem "fresh", and answers it: "(No, it won't)".

The same Google patent describes how a change could be weighed. It scores how much a page changes over time, and says changes to "Javascript, comments, advertisements, navigational elements, boilerplate material, or date/time tags, may be given relatively little weight or even ignored altogether". Boilerplate is the text repeated on every page, like a footer. Changes to the title and to the words of the page's own links may count more, and the rest of the main text sits in between. The 2024 leak has a field for the idea in its per-document record: lastSignificantUpdate, the "last significant update of the document", worked out "from various signals". That shows Google stores the idea, not that it ranks by it.

So an update worth doing touches the parts that count:

• The answer to the page's search, under the heading where it belongs, with facts that are true today.
• What the page still misses. Compare it with what ranks for its search and add what a reader still needs.
• The links in and out, so the page sits where its map row says it should.
• The date, last, and only once the page really changed.

Koray describes updating as a loop he calls content configuration, in his 2023 article on entities and attributes: "content revision based on semantic networks", then "re-ranking the documents", and repeat. Revise, wait for the results to move, read them, revise again.

On a real map, an existing page that passes the purpose test gets a row like any new page. We published a 12-row excerpt from one branch of a 391-page map we built for a US apparel store. These five rows of it were pages the store already had, given a row and rebuilt rather than deleted. The numbers jump because the excerpt is a slice of the map, and the role says where a page sits: the pillar at the top, hubs that gather a group, cluster pages under them.

Row 203 is one of those existing pages. The map puts it under the style hub and links it to the oversized tees collection, which sells what it talks about.

A worked example: twelve pages, one verdict each

Here is a made-up example, invented for this lesson: a roofing company in Columbus, Ohio, whose blog grew to eleven posts under an earlier agency, plus the thank-you page its booking form uses. Run through the decision path, the twelve pages get all six verdicts: two keep, three update, three merge, one redirect, two remove and one noindex.

Four rows show the path doing its job:

• Post 4 has traffic and still goes. It drew 620 clicks over 16 months, every one from someone looking for a recipe. Its one link comes from a recipe roundup, and no roofing page is an honest target for it.
• Post 8 looks dead and stays. It had no clicks from March to November. Over 16 months it is the busiest post on the blog, with 6 leads last winter.
• Post 9 is weak but linked. 14 sites link to it, so it is updated and never removed.
• Post 10 holds one fact worth keeping. "We have exhibited at the Columbus home show since 2019" moves to the About page as a line of proof, and the post's address redirects there.

Post 11 is the plain redirect. The offer is over and the page says nothing worth moving, but three coupon sites still link to it. A person following those links wants a deal on a roof, which the roof replacement page answers.

What the evidence on pruning shows, and what it does not

I found no published controlled test showing that deleting pages lifts a whole site (I searched on 13 November 2026). Google has said two things that sound opposed and are not: removing unhelpful content can help your other pages, and deleting content only because it is old does not. The rest of the evidence is cases without a control.

• Google, 2022: unhelpful content weighs on the site. Announcing its helpful content update in August 2022, Google said content on sites with "relatively high amounts of unhelpful content overall is less likely to perform well", and that "removing unhelpful content could help the rankings of your other content."
• Google, 2023: age is not the test. In August 2023 Gizmodo reported that CNET had deleted thousands of old articles. Danny Sullivan, Google's public liaison for Search, answered: "That's not a thing!" and "Just don't assume that deleting something only because it's old will improve your site's SEO magically." He allowed that on a massive site, removing pages might help Google crawl the rest.
• The two fit together. Both statements point at whether a page helps the people who land on it. Unhelpful pages can weigh on a site; old pages that still help do not. Google's 2011 note adds that pages which no longer exist do not affect "how your site's other URLs" perform. I read that as: the removal itself is neutral, and what counts is what is left.
• CNET published no results. Gizmodo's summary of the memo lists the factors CNET weighed: "SEO, the age and length of the story, traffic to the article, and how frequently Google crawls the page," plus historical significance. The memo promised a signal "that says CNET is fresh, relevant and worthy of being placed higher". I found no before and after published by CNET. Set those factors beside CREW's: age, use and historical value are there, and the quality faults are not.
• Split tests point both ways. SearchPilot's enrich-instead-of-delete test is above. In its review of 2025 tests, removing an expert video carousel from listing pages gained 4.1%, and removing a map from location pages lost 7%. Those removed parts of pages, not pages, but they show that a cut is something to test, not a rule.
• Practitioner reports rarely isolate the cut. In a 2019 roundup by Orbit Media, a web agency, most of the seven practitioners who reported results had changed other things at the same time. Of the cleanups done mostly on their own, one saw no change, one saw organic traffic rise about 50%, and one saw its remaining pages rank higher while total traffic did not rise.
• Koray's cleanups changed several things at once. His case studies that include pruning and merging, such as the review site above, also changed templates, content and technical setup, so the share due to fewer pages cannot be separated.
• The leak says Google stores focus, not how it uses it. The 2024 documentation lists siteFocusScore, a "number denoting how much a site is focused on one topic", beside siteRadius. That fits the purpose test. It shows no weight, and Google's spokesperson told The Verge to "caution against making inaccurate assumptions about Search based on out-of-context, outdated, or incomplete information."

So I work by a fixed order: merge first, update second, remove last, and measure before and after. Why fewer, clearer pages can help a site at all, in terms of what it costs an engine to crawl and judge them, is covered in cost of retrieval.

The audit sheet to keep, and how to run the changes

Copy the audit sheet, fill it in the column order shown, and make the changes in small batches: merges first, then redirects, then removals. Write down the date of each change, and leave a few similar pages alone to compare.

Download the audit sheet (CSV)Fifteen columns in the order to fill them, with the twelve made-up roofing posts from the worked example filled in. Opens in Google Sheets or Excel.

Then run the changes in this order:

1. Merges first. They decide which pages stay, and so where every redirect points.
2. Then plain redirects, each straight to its final target.
3. Then removals, after one last look at links and uses outside search.
4. Then noindex, on the pages people still use.
5. One batch at a time, with its date written down and a handful of similar pages left alone as a comparison.

Read the result the way the keyword cannibalization lesson describes: clicks for the affected searches over the 28 days before the change, against a 28-day window at week 4 and again at week 8, beside the pages you left alone. If those rose as much, the season did it, not the cleanup. What a map should do over the months after publishing is in how to tell if a topical map is working.

Run the audit again after any big change to the site, and once a year otherwise. If you would rather have the map built for you, with your existing pages placed on it, that is the growth plan.