Kill 100 pages, safely

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.

1. Start from the audit. Filter your reviewed audit CSV to the delete rows.
2. Pull. Run a Specter pull so the deletion plan matches what’s actually live.
3. 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.
4. Review the map, then apply the redirects to your host first and verify they resolve.
5. 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.
6. 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

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.