Prune 100 dead pages and generate the 301 redirect map

Deleting content feels like losing, which is exactly why most blogs never do it — and why most blogs are weighed down by a long tail of thin, dated, traffic-less posts that dilute their topical authority. Google judges a domain holistically, so a few hundred dead pages can drag down the rankings of the good posts that share the domain. Pruning that dead weight is one of the most counterintuitive and highest-return moves in technical SEO. The catch is that deleting pages carelessly creates a field of 404s and lost backlink equity, which is worse than doing nothing. The safe version is a recipe, not a delete key — and Specter’s dry-run is what lets you see the exact blast radius before anything unpublishes.

What you need

Specter synced to your blog
An AI assistant you already use
The delete rows from the thin content auditor — never delete from a list you didn’t review
Access to your host’s redirect config (Cloudflare rules, a _redirects file, Nginx, or your CMS’s redirect manager)

The recipe

The order of these steps is the whole safety model — redirects go live before anything is deleted.

Start from the audit. Filter your reviewed audit CSV to the delete rows.
Pull. Run a Specter pull so the deletion plan matches what’s actually live.
Generate the redirect map. Run the redirect prompt — it picks the best surviving target for each doomed post (or marks it 410) and writes a CSV.
Review the map, then apply the redirects to your host first and verify they resolve.
Run the delete pass (removes the local files only), then dry-run to check the blast radius — count the deletes, read the slug list, restore anything wrong with git.
Push. Specter unpublishes those posts; combined with your live redirects, the URLs now 301 to their replacements. Then file removal requests in Search Console.

The prompt

The redirect map is a planning pass — it deletes nothing:

You are building a redirect map for posts about to be deleted. For each post
marked delete: read its title, slug, and topic, then search the surviving posts
for the best target. Decide: "301 to <surviving-slug>" if there's a clearly
better post on the same topic; "301 to /" or a category page if that's the right
home; "410 gone" only if there is genuinely no good target. Write
source_slug, source_url, redirect_type, target_url, reason to a CSV. Default to
301 over 410 — 301s preserve inbound backlink equity. Delete nothing.

Then the delete pass acts on the reviewed map:

For each row in the reviewed redirect map, find posts/<slug>.md and delete it
from the working tree; log slug, redirect_type, target. Do NOT push to the CMS
and don't modify anything else — I'll run a Specter dry-run and review before
pushing. If a file is already gone, log "SKIPPED — not found" and continue.

Cost and time

Blog size	Tokens	Cost	Wall-clock
50 deletes	~80k	$0.15	20 min
200 deletes	~320k	$0.60	60 min
500 deletes	~800k	$1.50	2 hr

Most of the wall-clock is the review steps and redirect deployment, not the model.

Pitfalls

Redirects MUST go live first. Non-negotiable. Live redirects, then delete — skip this and you’ll 404 traffic and lose backlink equity.
Backlink check. Run any flagged URL through a backlink tool before pushing. More than a handful of referring domains means redirect, don’t 410.
Don’t delete brand pages. Lock the homepage, about, contact, and pricing out of this recipe categorically. Consider a slow rollout — 25/week — so you can stop if you see unintended drops.

Where to go next

Pair it with the thin content auditor on a quarterly cadence so the long tail never builds back up. If you’d rather not hard-delete, push as status: draft first — unindexable but recoverable — and convert to a real delete after 30 days of monitoring.