Free, no signup.
A migration lives or dies on whether every old URL lands somewhere real. Paste your
old URLs and new URLs and get a suggested 301 map — each
row scored into a confidence tier with a plain-English reason, an override dropdown, a
first-class unmatched bucket, and a 410 kill-list for pages with no equivalent.
Runs entirely in your browser — nothing you paste is uploaded or stored. Sitemap import and content matching are opt-in exceptions — see below. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Feedback
Report a bug
Found something broken in Redirect Map Builder? Let us know what happened — this goes straight to a private triage queue, not a public list.
Pattern rules — bulk path transforms applied before matching
Each row’s “Why” control shows every matcher that ran. Raw scores are internal ordering only, not confidence percentages; the tier descriptions come from the labeled fixture calibration below.
Still unmatched? Match remaining by content
Fetches page metadata only (title, H1, description) — live for new URLs, from Wayback first
and Common Crawl only when Wayback has no usable capture — and ranks by text similarity. Capped per run; no full-body scrape, no
embeddings. Content guesses are styled distinctly so they're never confused with a
structural match.
Export
Pattern rules go to formats that can run them (Bulk Redirects can't — they're listed as a
note there). Rows are ordered specific → general; self-redirect no-ops are dropped; 410
rows export where the platform supports them and remain explicit notes otherwise. The
WordPress plugin CSV stays import-only; use its review companion CSV for confidence,
evidence, and Ahrefs session context.
Autosaved to this browser.
Sample report Example data — real, matcher-verified result
Say you migrated a blog and product catalogue. Your old URLs:
Two Strong matches, safe to accept. The dated blog post matched by
slug ("seo-tips") and the PHP product page matched by its numeric ID (482) — see
what each confidence tier means.
/about-us.html is actually an Exact match (extension-stripped hit
on /about-us) — here it's shown marked 410 instead, to demonstrate
the kill-list toggle overriding an automatic pick.
/blog/deprecated-tactic has no equivalent — its best candidate is
only an 18%-similar weak guess, below the accept threshold, so it lands in
unmatched for a manual decision, content matching, or a 410.
Once the map looks right, tick Check destinations are live 200s before export,
or read site migrations for the full redirect-mapping
process.
How to use it
Paste your old URLs on the left — the pre-migration set that will start
404'ing. A GSC Pages export, a crawl of the old site, or the 404 report all work; upload a
CSV/TXT and the first URL-looking column is sniffed out automatically.
Paste your new URLs on the right — the live destination set — or drop in a
sitemap URL and press Load to pull its <loc>
entries.
Press Build redirect map. Each old URL gets a suggested destination, a
confidence tier, and a plain-English reason. Use Load sample first if you just
want to see it work.
Work the list: change any pick from the dropdown, click 410 to mark a page
gone, or hit Accept all Exact + Strong to lock in the confident rows and focus
on the rest. The unmatched and 410 filters isolate what still
needs a decision.
Export to Apache .htaccess, nginx, Cloudflare
_redirects/Bulk Redirects, or CSV — and optionally
Check destinations are live 200s before you ship.
What the results mean
Each row carries a confidence tier and a status. The summary pills tally them:
Exact (green) — the path is identical, or identical once the file extension is
ignored (/about-us.html → /about-us). Trust these.
Strong (blue) — a matching last slug segment, a shared numeric ID, or a match
asserted by one of your pattern rules. Very likely correct; skim them.
Fuzzy (amber) — the whole path is similar in tokens and scored at or
above your accept threshold. Plausible, but review each one.
Unmatched (red) — no candidate cleared the bar (a below-threshold Weak best is
demoted here too). These need a manual pick, content matching, or a 410.
Already exists (grey) — the old URL is also in your new list, so no redirect is
needed; it is dimmed and excluded from the map.
410 Gone (purple) — you flagged the page as retired; it exports as a kill-list
entry, not a redirect.
In a loop (purple, left-barred) — chain flattening found the target itself
redirects back, which would create a loop. Fix the destination before shipping.
When you run Check destinations are live 200s, each destination also gets a small
badge: 200 (clean), N redirects → … (you're mapping to a redirect,
not the final URL), or 404/unreachable (a broken destination to fix first).
How it works
The matching engine runs entirely in your browser. Both lists are normalised first — optionally
treating /a and /a/ as equal, comparing paths case-insensitively, stripping
tracking params (utm, gclid, fbclid), and ignoring file extensions. Then each old URL runs a matcher
cascade, strongest first: exact path, exact path minus extension, last-slug match, numeric-ID
extraction, and finally whole-path token similarity. The first matcher that fires sets the tier; a
below-threshold token best is demoted to unmatched rather than shown as a shaky guess.
The optional trailing-slash normalisation is migration matching only: it lets /a
and /a/ represent the same content candidate. The Redirect Chain Mapper keeps them
distinct because its job is to expose an actual slash redirect hop.
After matching, a chain-flattening pass detects cases where an old URL points at another old URL and
rewrites the map to the final destination (or flags a genuine loop). Correct a row by hand and the
tool offers to induce a pattern rule — e.g. /blog/* → /articles/* — and apply it
to every similar row at once. The only server calls are opt-in: sitemap import, Tier 2 content
matching (fetches title/H1/description only, live for new URLs and from Wayback or Common Crawl for dead old ones),
and the destination-liveness check.
Features
Calibrated confidence tiers (Exact, Strong, Fuzzy, Weak) with a plain reason per row, not a bare
percentage.
A first-class unmatched bucket and a 410 kill-list so retired
pages never get silently dropped or dumped on the homepage.
Per-row override dropdown with alternates, plus Accept all Exact + Strong to
clear the easy rows in one click.
Pattern rules (wildcard or regex) with a live match-count preview, auto-detected directory remaps,
and correction-driven rule induction.
Import from CSV/TXT upload or a sitemap URL; adjustable normalisation and fuzzy-accept threshold.
Optional Tier 2 content matching and a destination-liveness check that reuses the bulk status
checker.
Exports to Apache .htaccess, nginx, Cloudflare _redirects and Bulk
Redirects, and CSV — ordered specific → general, with self-redirect no-ops dropped.
Autosaves to your browser; download/import the whole project as JSON.
Limitations
It matches on URL structure, not meaning — two unrelated pages that happen to share a slug can
match, which is why Fuzzy rows are flagged for review. It does not crawl your site to discover URLs
(paste or import them). Sitemap imports follow nested indexes within explicit depth, document, and URL caps.
The destination check and content matching are capped
per run and only reach public URLs. And it builds the map — it doesn't deploy the redirects;
you export the rules and add them to your server or CDN.
Frequently asked questions
What is a redirect map?
A redirect map is a list that pairs every old URL with the new URL it should 301 redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. to after a site migrationA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once. or restructure. It is the deliverable you hand to whoever configures the redirects, and getting it right is what preserves rankings and stops visitors hitting 404s. This tool builds that list for you by matching your old URLs to your new ones and scoring each pairing so you know which rows to trust and which to review.
How does it decide which old URL matches which new URL?
It runs a cascade of matchers, strongest first: identical path (Exact), identical path ignoring the file extension (Exact), a matching last slug segment or a shared numeric ID (Strong), then token similarity of the whole path (Fuzzy above your threshold, Weak below it). The first matcher that fires sets the tier, and the row shows the plain reason — for example "slug match" or "shared ID token 482". You can override any pick from the dropdown, and correcting one row offers to generalise the fix into a pattern rule for similar URLs.
Is my URL list uploaded anywhere?
No. Parsing, normalisation, matching, chain-flattening and every export run entirely in your browser, and your project autosaves to that browser only. The only network calls are optional and clearly opt-in: importing a sitemap by URL, the Tier 2 "match remaining by content" step, and the destination-liveness check. If you paste your URLs and export, nothing leaves your machine.
What should I do with the unmatched URLs?
Unmatched rows are the whole point of the tool being loud about them — they are the old URLs with no confident new equivalent, and they are exactly what you would otherwise miss. For each one, either pick a destination manually from the dropdown, run Tier 2 content matching to get suggestions, or mark it 410 GoneA 410 Gone status code tells search engines a page was intentionally and permanently removed, prompting slightly faster de-indexing than a standard 404. if the page genuinely has no replacement. Leaving them unmatched means those URLs 404 after launch.
When should I use a 410 instead of a 301?
Use a 301 when the old page has a real equivalent on the new site. Use 410 Gone when the content is genuinely retired with no replacement — a discontinued product, an old campaign page, thin content you are pruning. A 410 tells search engines the URL is intentionally gone so they drop it faster than a soft 404A soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing., and it keeps you from redirecting dozens of dead pages to the homepage, which Google treats as a soft 404 anyway. The tool exports 410 rows as a separate kill-list.
Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Common issues & how to fix them
Redirect Map Builder · one finding
Legacy URL has no redirect match
Recommended action: Choose the closest destination with equivalent intent and content, or deliberately return 410 when no useful replacement exists.
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
Implementation for your setup
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
Steps
Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
Verify on this platform
Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
Rollback
Retain the prior redirect configuration and the exact deployment revision.
If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
Caveats
A similarity score is evidence for review, not permission to publish a redirect.
Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
Implementation is controlled by the platform or vendor.
Verify on this platform
Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
Verify the final public responses independently against the reviewed source-to-destination map.
Caveats
Do not treat an accepted import as proof that every rule is active or ordered as intended.
Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
Escalate when
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
Redirect Map Builder · one finding
Legacy URL already exists on the destination site
Recommended action: Do not redirect a legacy URL that already resolves on the destination site; keep it live or explicitly decide which version should be canonical.
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
Implementation for your setup
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
Steps
Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
Verify on this platform
Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
Rollback
Retain the prior redirect configuration and the exact deployment revision.
If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
Caveats
A similarity score is evidence for review, not permission to publish a redirect.
Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
Implementation is controlled by the platform or vendor.
Verify on this platform
Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
Verify the final public responses independently against the reviewed source-to-destination map.
Caveats
Do not treat an accepted import as proof that every rule is active or ordered as intended.
Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
Escalate when
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
Redirect Map Builder · one finding
Proposed map creates a redirect loop
Recommended action: Change one side of the proposed circular mapping so every source points to a destination that never redirects back.
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
Implementation for your setup
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
Steps
Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
Verify on this platform
Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
Rollback
Retain the prior redirect configuration and the exact deployment revision.
If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
Caveats
A similarity score is evidence for review, not permission to publish a redirect.
Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
Implementation is controlled by the platform or vendor.
Verify on this platform
Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
Verify the final public responses independently against the reviewed source-to-destination map.
Caveats
Do not treat an accepted import as proof that every rule is active or ordered as intended.
Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
Escalate when
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
Redirect Map Builder · one finding
Proposed destination creates a redirect chain
Recommended action: Replace the proposed destination with the chain’s final live URL before exporting the redirect map.
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
Implementation for your setup
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
Steps
Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
Verify on this platform
Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
Rollback
Retain the prior redirect configuration and the exact deployment revision.
If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
Caveats
A similarity score is evidence for review, not permission to publish a redirect.
Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
Implementation is controlled by the platform or vendor.
Verify on this platform
Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
Verify the final public responses independently against the reviewed source-to-destination map.
Caveats
Do not treat an accepted import as proof that every rule is active or ordered as intended.
Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
Escalate when
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
Redirect Map Builder · one finding
Redirect match confidence is low
Recommended action: Choose a verified equivalent destination manually or mark the old URL 410 when no replacement exists.
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
Implementation for your setup
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
Steps
Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
Verify on this platform
Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
Rollback
Retain the prior redirect configuration and the exact deployment revision.
If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
Caveats
A similarity score is evidence for review, not permission to publish a redirect.
Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
Implementation is controlled by the platform or vendor.
Verify on this platform
Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
Verify the final public responses independently against the reviewed source-to-destination map.
Caveats
Do not treat an accepted import as proof that every rule is active or ordered as intended.
Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
Escalate when
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
Redirect Map Builder · one finding
Multiple destinations have similar match confidence
Recommended action: Review the equally ranked candidates and manually select the destination that preserves the old page’s intent.
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
Implementation for your setup
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
Steps
Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
Verify on this platform
Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
Rollback
Retain the prior redirect configuration and the exact deployment revision.
If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
Caveats
A similarity score is evidence for review, not permission to publish a redirect.
Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
Implementation is controlled by the platform or vendor.
Verify on this platform
Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
Verify the final public responses independently against the reviewed source-to-destination map.
Caveats
Do not treat an accepted import as proof that every rule is active or ordered as intended.
Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
Escalate when
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
Redirect Map Builder · one finding
Multiple legacy URLs map to one destination
Recommended action: Confirm each consolidation is intentional and maps to a true equivalent rather than a generic page.
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
Implementation for your setup
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
Steps
Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
Verify on this platform
Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
Rollback
Retain the prior redirect configuration and the exact deployment revision.
If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
Caveats
A similarity score is evidence for review, not permission to publish a redirect.
Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
Implementation is controlled by the platform or vendor.
Verify on this platform
Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
Verify the final public responses independently against the reviewed source-to-destination map.
Caveats
Do not treat an accepted import as proof that every rule is active or ordered as intended.
Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
Escalate when
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
Redirect Map Builder · one finding
Matched pages have weak content similarity
Recommended action: Compare the old and proposed pages’ title, H1, and main topic, then choose the closest true replacement.
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
Implementation for your setup
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
Steps
Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
Verify on this platform
Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
Rollback
Retain the prior redirect configuration and the exact deployment revision.
If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
Caveats
A similarity score is evidence for review, not permission to publish a redirect.
Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
Implementation is controlled by the platform or vendor.
Verify on this platform
Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
Verify the final public responses independently against the reviewed source-to-destination map.
Caveats
Do not treat an accepted import as proof that every rule is active or ordered as intended.
Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
Escalate when
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
