Verified against ChatGPT · 2026-07-30
Build a 301 redirect map for a site migration without losing rankings
Maps every old URL to its correct new destination by matching topic and intent rather than URL-structure guesswork, flags every 1-to-many and many-to-1 case that needs a human decision, and calls out chains and loops before they ship.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are a technical SEO managing URL equity through a site migration. A wrong or missing redirect on a page that currently ranks is one of the most common causes of a post-migration traffic collapse, so precision here matters more than speed. MIGRATION TYPE: full replatform from WordPress to a custom Next.js site, with a new information architecture OLD URL LIST (with topic and current traffic/ranking importance if known): /services/seo — SEO service page, high traffic /blog/seo-tips-2022 — old tips post, low traffic /blog/seo-tips-2023 — newer tips post, medium traffic /about/team — team page, low traffic NEW URL STRUCTURE OR NEW SITE'S PAGE LIST: /solutions/search-optimization — new SEO service page /insights/seo-strategy-guide — new consolidated evergreen guide /company/our-team — new team page TASK 1. MAP EACH OLD URL to the single best-matching new URL by topic and search intent, not by superficial URL-path similarity — a URL restructure often means /services/seo maps to /solutions/search-optimization despite sharing no path segments at all. 2. FLAG 1-TO-MANY CASES. If an old URL's content has been split across multiple new pages, list every plausible destination and recommend the one most topically central as the 301 target, but state explicitly that this needs a human decision if the split is genuinely ambiguous — don't silently pick one and hide the ambiguity. 3. FLAG MANY-TO-1 CASES. If several old URLs would all map to a single new page (several old blog posts consolidated into one pillar page, for example), confirm this is intentional consolidation and not an accidental collision, and note that all of them redirecting to the same destination is expected here, not a mistake to fix. 4. FLAG ORPHANS. Any old URL with no reasonable match in the new structure at all should be flagged explicitly, with a recommendation to either redirect to the closest parent category page or, if the content is genuinely gone, redirect to a relevant hub rather than leaving it to 404 — a hard 404 on a page that used to rank forfeits its link equity entirely instead of passing any of it forward. 5. CHECK FOR CHAINS. If any new URL in /solutions/search-optimization — new SEO service page /insights/seo-strategy-guide — new consolidated evergreen guide /company/our-team — new team page is itself scheduled to redirect elsewhere (a page that's new today but already planned to be replaced), flag the chain so the map can point directly to the final destination instead of hopping through an intermediate redirect, since a chain of 301s adds latency and, beyond a couple of hops, risk of a search engine not following the full chain. 6. HIGH-VALUE PRIORITY FLAG. Mark any old URL noted as high-traffic or high-ranking-importance so its redirect gets manually verified first and separately from the bulk of the map, since a mistake there costs disproportionately more than a mistake on a low-traffic page. OUTPUT A table: Old URL | New URL (target) | Match type (1-to-1 / 1-to-many / many-to-1 / orphan) | Priority | Notes. Close with a summary count of each match type and a list of anything flagged for human decision.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Matching old URLs to new destinations by topic and intent rather than path-structure similarity is the difference that actually prevents most migration traffic loss, because the whole reason a site migrates its URL structure is usually that the old structure no longer reflects how the business or content is organized — matching by superficial path similarity in that exact situation reliably produces wrong mappings, since the old and new paths were never designed to line up in the first place. Explicitly separating 1-to-many and many-to-1 cases from clean 1-to-1 matches matters because these are the cases where an automated or rushed redirect map most often goes wrong silently: a many-to-1 consolidation that's actually intentional looks identical, on a spreadsheet, to several accidental collisions onto the wrong page, and a script or a fast pass through the list won't distinguish "this is planned" from "this is a mistake" without a human flag calling out the difference explicitly. The orphan-handling instruction — redirect to a relevant parent rather than let a previously-ranking URL hard-404 — targets a specific and costly failure mode: a 404 on a URL that used to carry real link equity and ranking signal forfeits all of it outright, while even an imperfect redirect to a topically related parent page passes some of that equity forward, which is a meaningfully better outcome even when it isn't a perfect 1-to-1 match. Flagging redirect chains matters for a more mechanical reason — each additional hop adds latency for every visitor and search engine crawler that follows it, and a chain beyond a couple of hops risks not being followed to its final destination at all, so pointing every redirect at its true final URL directly, rather than at an intermediate page that itself redirects onward, is both faster and safer.
What you get back
/services/seo | /solutions/search-optimization | 1-to-1 | HIGH PRIORITY | Direct topical match despite unrelated path structure; verify manually given high current traffic. /blog/seo-tips-2022 + /blog/seo-tips-2023 | /insights/seo-strategy-guide | many-to-1 | Medium | Intentional consolidation of two overlapping posts into one evergreen guide — confirm this is the plan, not an accidental collision. /about/team | /company/our-team | 1-to-1 | Low | Straightforward match. Summary: 2 clean 1-to-1, 1 many-to-1 (confirmed intentional), 0 orphans, 0 chains detected. No cases requiring further human decision beyond the consolidation confirmation above.
Verified against
ChatGPT GPT-5.1 · 2026-07-30
Claude Claude Sonnet 5 · 2026-08-05
Changelog
- 2026-07-30 — Initial publish, verified against ChatGPT.
- 2026-08-05 — Re-verified against Claude Sonnet 5; added the redirect-chain check after a generated map pointed several old URLs at a new page that was itself scheduled to redirect elsewhere.
Building this for real?
This is a free starting point. If you'd rather have SEO built and running for your business, that's Scult's day job.
EXPLORE SEO
