The Content Pruning Workflow for Agency SEO Teams

Every agency has one: the client with 4,200 blog posts, eleven years of history, three CMS migrations, and a content team that left in 2019. Organic traffic is flat. The client asks why. You know the answer is buried somewhere in those 4,200 URLs, but nobody wants to open that spreadsheet.

A content pruning workflow is what turns that dread into billable, trackable, defensible work. Not a one-off audit deliverable — a repeatable process with data inputs, decision rules, batched execution and measurement. This is how we run it.

Why pruning fails at agencies (and it's not the analysis)

Most pruning projects die at one of three points:

• The spreadsheet becomes the deliverable. You send 4,200 rows with a "recommendation" column. The client opens it once, panics, and asks for "a summary." Nothing ships.
• Approval has no boundaries. The client wants to review every deletion individually. At 90 seconds per URL that's 105 hours of their time. They'll do forty and stall.
• Implementation has no owner. Redirects need a dev. Merges need a writer. Noindex needs CMS access. None of that was scoped, so the work sits in "pending client" for five months.

The fix is to decide the rules before you touch the data, get those rules approved once, and then execute in batches where the client approves a batch summary rather than individual URLs.

Step 1: Build the URL inventory (one source of truth)

Pull five datasets and join them on URL. This takes about three hours the first time, ninety minutes once you have a template.

1. Full crawl — Screaming Frog or Sitebulb. Export URL, title, word count, status code, canonical, indexability, internal inlinks, last-modified.
2. Search Console — 16 months of page-level clicks, impressions, and query count. Use the API or Looker Studio export; the UI caps at 1,000 rows.
3. GA4 — sessions, engagement rate, conversions and assisted conversions by landing page, 12 months.
4. Backlinks — referring domains per URL from Ahrefs or Semrush. This is your redirect-protection list.
5. Business context — a client-supplied list of pages that must never be touched: legal, careers, sales collateral, that one case study the CEO loves.

Join it all in one sheet. Every row is one URL. Every column is a signal. No commentary yet.

Segment before you score

Never score a product page with the same rules as a 2016 blog post. Split the inventory into segments — blog, service pages, location pages, resources, PDFs, tag/archive pages, pagination — and prune each segment separately. On most sites, tag and archive pages alone account for 30-40% of the URL count and generate under 1% of clicks. That's your fastest win and you should handle it as a technical fix, not a content decision.

Step 2: Set disposition rules before you look at pages

Write the rules first so you're not making 4,000 judgment calls. A version that works for most B2B and ecommerce blogs:

• KEEP — 100+ clicks in 12 months, or converts, or 3+ referring domains. No action.
• UPDATE — 20-100 clicks, ranks 5-20 for a target term, content is stale but the intent is still valid. Goes into the content calendar, not the prune list.
• MERGE — two or more URLs targeting the same intent, none dominant. Combine into the strongest, 301 the rest.
• REDIRECT — under 20 clicks, has backlinks or internal links, but a clearly relevant parent page exists.
• NOINDEX — serves users or the business but shouldn't compete in search: thin location stubs, gated asset landers, thank-you pages, author archives.
• DELETE (410) — zero clicks, zero conversions, zero referring domains, no relevant redirect target, no business value. Expired event pages, old job posts, 2014 press releases.

Send these six rules to the client as a one-page doc. Get written sign-off. This single approval replaces hundreds of individual ones and is the difference between a project that ships in eight weeks and one that never does.

The judgment cases that need human eyes

Roughly 10-15% of URLs won't fit the rules cleanly. Flag them into a "review" bucket: seasonal pages with spiky traffic, pages ranking for branded queries only, YMYL content with compliance implications, and anything with 10+ referring domains regardless of traffic. Budget one focused hour per 100 flagged URLs.

Step 3: Turn the spreadsheet into actual project work

Here's where most audits stop and most results never arrive. A 4,200-row sheet is not a project plan. Convert it.

Group the prune list into batches of 50-150 URLs by action type and by implementation owner. A typical shape for a mid-size site:

• Batch 1 — 340 tag/archive URLs → noindex (dev, 2 hours)
• Batch 2 — 180 expired event and job pages → 410 (dev, 1 hour)
• Batch 3 — 62 URLs → redirect to parent category (dev, 2 hours)
• Batches 4-9 — 24 merge clusters, ~90 source URLs → writer + dev (6 weeks)
• Ongoing — 210 UPDATE pages feed the editorial calendar over two quarters

Each batch becomes a task with an owner, an estimate and a due date. Merge clusters are the expensive part — a real merge means rewriting, not concatenating — so treat each cluster as a content brief and run it through your normal brief-to-publication process rather than inventing a parallel workflow. If a freelancer is doing the merges, the same rules about scope and handoff apply as in any other freelance writer workflow.

This is also the point where the tool you use starts to matter. A pruning project has phases, per-batch time tracking, a dev dependency and a client-visible status — which is a project, not a to-do list. We built PeakKR around that shape, but the honest test for any tool is whether a PM can see "batch 5 is blocked on dev access" without opening a spreadsheet. If you're evaluating options, our roundup of PM tools for agencies covers the trade-offs.

Step 4: Implement without breaking the site

Pruning is a migration in miniature, and the same failure modes apply — the mapping file is the deliverable, not the redirect plugin. If you're touching more than ~500 URLs, borrow the discipline from a full website migration project plan.

Non-negotiables per batch:

• Redirect map in a versioned file — source URL, destination URL, action, batch number, date implemented, implementer.
• One hop only. If the source already redirects, point to the final destination, not the chain.
• Fix internal links first. Redirecting a URL that's linked from 40 pages leaves 40 links pointing at a 301. Update the links in the same batch.
• 410, not 404, for true deletions. It tells Google the removal was intentional and drops the URL from the index faster.
• Post-deploy crawl. Re-crawl the batch within 24 hours and confirm every source URL returns the expected status and lands on the expected destination.
• Annotate GA4 and log the date. You will need to explain a traffic movement three months from now.

A second pair of eyes on the redirect map catches the expensive mistakes — a mistyped destination or a redirect loop is far cheaper to find pre-deploy, and it's exactly the kind of check that AI-assisted QA handles well at volume.

Step 5: Measure, then run the next batch

Wait 21-28 days after each batch before judging it. What to watch:

• Total indexed pages in Search Console — should fall roughly in line with what you removed.
• Clicks on retained URLs — the whole point. Compare the KEEP segment period-over-period, not sitewide totals.
• Merge targets specifically — a good merge shows the destination URL absorbing impressions the sources used to get within 4-6 weeks.
• Crawl stats — average