Recipe
The redirect map builder
Pruning dead weight is one of the highest-leverage things you can do to an old archive — fewer, stronger pages outrank a sprawl of thin ones. But pruning has a failure mode that quietly undoes the win: you unpublish a page that still had inbound links, residual rankings, or the odd loyal reader, and all of that turns into a 404. The equity doesn’t transfer to your better pages; it evaporates. A 301 redirect is what moves it instead — it tells search engines and browsers “this moved here,” carrying the rankings and the backlinks to the replacement. The hard part isn’t writing redirects, it’s deciding the right target for each retired URL across a hundred of them. This recipe does the matching: it reads what each retiring page was about and pairs it with the closest surviving page, then hands you a map you apply in your platform.
This is the safety net for killing 100 pages and for the consolidation step of the cannibalization report. Build the map first; unpublish second.
What you need
- Spectersync synced to your blog
- The list of URLs you’re retiring (from your prune shortlist or a merge plan)
- An AI assistant you already use
- Access to add redirects in your platform — this recipe produces the map; where you load it depends on your CMS (Spectersync syncs content, not host redirect rules)
The recipe
- Pull and stage. Spectersync pull so the retiring pages and every live page are local Markdown to compare against.
- Mark the retire set. Tag the URLs you’re removing — the output of your prune shortlist or merge decisions.
- Run the matcher (read-only). For each retiring URL it finds the single best live replacement by topic and intent, or marks it “no good match → redirect to section/home.” It outputs a clean two-column map. No files change.
- Review the matches. Skim the map — a wrong target is worse than a generic one. Downgrade any weak match to the parent category page.
- Apply, then unpublish. Load the 301s where your platform manages them (WordPress redirect plugin, Shopify URL redirects, your host/CDN rules, etc.), confirm a few resolve, then unpublish the old pages with Spectersync. Order matters: redirects live before the pages die.
The prompt
The matcher is read-only:
You are building a 301 redirect map. For each URL in the RETIRE list, choose the
single best replacement from the LIVE list — the page a visitor to the old URL
would most want instead, judged by topic and search intent. If no live page is a
good match, output the most relevant section or category page and mark it
GENERIC. Output a three-column table: old URL, new URL, match confidence
(high/medium/generic), plus a one-line reason. Never map two retiring URLs into a
redirect chain — always point at a live destination. Do NOT modify any files.
RETIRE: {RETIRE_URLS}
LIVE: {LIVE_URLS}Cost and time
| Prune size | Tokens (matcher) | Cost | Wall-clock |
|---|---|---|---|
| 30 URLs | ~120k | $0.30 | 10 min |
| 100 URLs | ~400k | $1 | 30 min |
| 300 URLs | ~1.1M | $2.80 | 70 min |
Cost scales with the live set it matches against, not just the retire list — it has to read the survivors to pick targets.
Pitfalls
- No redirect chains. Redirecting A→B when B is also being retired just moves the 404. The prompt forbids it; verify no target in the map appears in your retire list.
- Generic beats wrong. A precise-looking redirect to an unrelated page frustrates readers and signals low quality. Send weak matches to the category page instead.
- Redirects first, unpublish second. If you unpublish before the 301 is live, you ship a window of 404s to every crawler that visits in between.
- Spectersync doesn’t write host redirects. It generates the map and syncs your content; loading the 301s happens in whatever layer your platform uses for URL rules.
Where to go next
This is step two of a safe prune. Pair it with killing 100 pages for the full sequence: shortlist the dead weight, map the redirects, apply, then unpublish.