Redirect Mapping for Website Migrations: How to Build, Validate, and Maintain a Redirect Map

Overview

If you only do one thing before changing URLs, do this: create a redirect map that lists every important old path, its intended new destination, the redirect type, and any implementation notes. That sounds simple, but most migration issues come from gaps around scope, logic, or validation rather than from the redirect rule syntax itself.

Redirect mapping is the planning layer behind a 301 redirect or other SEO redirect implementation. It answers questions such as:

• Which old URLs must resolve after launch?
• Which new URL should each old path point to?
• Should the redirect be permanent or temporary?
• Can a pattern rule cover a group of URLs, or is a one-to-one mapping needed?
• Are there any legacy URLs that should return a 410 or 404 rather than redirect?

For most website migration redirects, the default destination is a direct, relevant equivalent page. In practice, that usually means a permanent redirect for retired URLs that now live at a new address. If you are weighing status codes, keep the decision tied to intent: permanent moves generally use a 301, while temporary tests or short-term routing changes may need a different response. For a fuller status code comparison, see 301 vs 302 vs 307 vs 308 Redirects.

A strong redirect map usually includes these columns:

• Old URL
• Old path only if implementation is path-based
• New URL
• Status code, typically 301 or 302
• Page type such as product, category, blog post, PDF, image, landing page
• Source showing where the old URL came from: crawl, XML sitemap, analytics, CMS export, backlink list, paid campaign list
• Rule type: exact match, prefix, regex, platform tool, CDN rule
• Owner for sign-off
• Notes for edge cases, parameter handling, canonical changes, or exceptions
• Validation status for pre-launch and post-launch testing

This is why a redirect map template matters. It creates one operational document for SEO, developers, and content teams, and it reduces the risk of improvised redirects being added under launch pressure.

The implementation layer can live in different places depending on your stack: application, plugin, web server, load balancer, CDN, or platform redirect tool. The map should stay implementation-agnostic at first, then gain technical notes as the launch plan becomes fixed. If you need platform detail later, it helps to pair this process with guides such as WordPress Redirects, Shopify Redirects Guide, Nginx Redirect Guide, Apache Redirect Guide, and Cloudflare Redirect Rules Explained.

Checklist by scenario

Use this section as a working checklist. Not every migration needs every step, but most failed launches skip one of these basics.

1. Small URL changes on an existing site

Use this when: you are renaming a few pages, updating a blog structure, consolidating duplicate content, or changing a handful of slugs.

• Export the current URLs from your CMS or crawl the relevant section.
• List every old path and pair it with the most relevant new destination.
• Choose exact-match redirects where possible.
• Use a 301 redirect for permanent moves.
• Update internal links so the site points directly to the new URLs, not through redirects.
• Update canonicals, XML sitemaps, navigation links, and any hard-coded references.
• Test each redirect individually with a redirect checker before launch.
• After launch, monitor server logs, crawl reports, and analytics for missed 404s.

For small changes, the main risk is underestimating how many hidden references exist. PDFs, image URLs, email templates, campaign links, and help centre articles often still point to retired paths.

2. Section restructure or taxonomy change

Use this when: categories are being merged, folders are changing, URL depth is being flattened, or product and content sections are being reorganised.

• Gather the full old URL inventory from a crawl, sitemap exports, CMS lists, and analytics landing pages.
• Group URLs by template or page type so you can spot repeatable logic.
• Decide whether a rule-based redirect can safely replace one-to-one entries.
• Write out the rule in plain language before writing it in server syntax.
• Identify exceptions early. Pattern redirects fail when special cases are discovered too late.
• Map retired subcategories to the closest relevant parent or successor page, not just the homepage.
• Preserve high-value landing pages, especially URLs with backlinks, revenue history, or strong organic entry traffic.
• Test sample URLs from every page type before applying a bulk redirect map.

This is the point where teams often create a redirect chain without noticing. For example, old category A redirects to interim category B, which later redirects to final category C. The redirect map should always resolve old URLs directly to their final destination. If you need help diagnosing live issues, see How to Fix Redirect Chains and Redirect Loops on Live Websites.

3. Domain change or protocol/canonical consolidation

Use this when: you are moving to a new domain, changing subdomains, forcing HTTPS, or standardising www versus non-www.

• Separate domain-level redirects from path-level redirects in your map.
• Decide the preferred canonical host and protocol before implementing rules.
• Ensure old-domain URLs redirect directly to the final new-domain HTTPS canonical version.
• Avoid stacked hops such as HTTP to HTTPS, then non-www to www, then old domain to new domain.
• Document rules for all host variants: http, https, www, non-www, alternate subdomains.
• Confirm DNS, hosting, CDN, and origin behaviour do not conflict.
• Retain access to the old domain for as long as it needs to serve redirects.
• Update Search Console properties, analytics filters, campaign templates, and ad destination URLs.

These migrations often fail because teams think domain forwarding and website redirects are the same thing operationally. They are related, but not identical in how and where they are configured. For the infrastructure distinction, read Domain Forwarding vs Website Redirects. For host standardisation, see www vs non-www Redirects and HTTP to HTTPS Redirects.

4. Platform migration with changed URL patterns

Use this when: moving from one CMS or commerce platform to another, especially when default URL formats change.

• Export all current URLs from the old platform before access changes or content freezes begin.
• Export proposed or generated URLs from the new platform.
• Join the two lists using stable identifiers where possible: SKU, product ID, article ID, slug history.
• Flag pages that do not have a direct equivalent and review them manually.
• Decide whether query strings, faceted URLs, tags, and search pages should be redirected or excluded.
• Plan attachment, asset, media, and file redirects where these have independent URLs.
• Account for platform-specific redirect limits, rule precedence, and wildcard behaviour.
• Test in staging, but validate again in production because CDN and host behaviour may differ.

In platform migrations, the best redirect map is often assembled from multiple sources rather than from a single crawl. CMS exports tell you what exists; crawls show what is discoverable; analytics shows what users actually land on; backlink exports show which old paths still carry external value.

5. Ongoing legacy URL clean-up after launch

Use this when: the main migration is complete, but long-tail 404s and overlooked paths continue to surface.

• Review 404 logs, top landing-page errors, and support tickets weekly after launch, then monthly.
• Classify each missed URL: typo, obsolete page, old campaign URL, scraper noise, or genuine missed legacy path.
• Add redirects only where there is a valid relevant destination.
• Do not redirect every unknown path to the homepage. That hides issues and can confuse users.
• Version-control your redirect map so additions are documented over time.
• Retest bulk rules whenever new exceptions are introduced.

This maintenance phase is where a redirect map stops being just a migration document and becomes an operational asset.

What to double-check

Before launch, and again immediately after launch, review these items in order. This is the part teams revisit most often because the underlying inputs change whenever URLs, hosting, rulesets, or campaign destinations change.

Redirect relevance

• Every high-value old URL points to the closest matching new page.
• No important pages are redirected to broad category pages just for convenience.
• No retired URLs are sent to the homepage unless that is genuinely the best fit.

Status code choice

• Permanent moves use the correct permanent redirect status.
• Temporary campaign or test redirects are not accidentally left in place long term.
• Mixed signals between canonicals and redirects have been resolved.

Directness

• Old URLs resolve in one hop to the final destination.
• There are no redirect chain patterns introduced by older rules still being active.
• There is no redirect loop caused by conflicting host, protocol, or path rules.

Canonical and internal signals

• Canonical tags on destination pages point to themselves or the intended canonical URL.
• Internal links have been updated to the final destination URLs.
• XML sitemaps list final URLs, not redirected ones.
• Hreflang, structured data, and navigation references have been refreshed where relevant.

Pattern rule safety

• Wildcard or regex rules have been tested with edge cases.
• Trailing slash behaviour is consistent.
• Uppercase, lowercase, URL-encoded characters, and special characters are handled predictably.
• Query string behaviour is documented: preserved, stripped, or conditionally matched.

Coverage

• The redirect map includes URLs from more than one source: crawl, CMS, analytics, backlinks, paid landing pages, and offline assets such as QR codes if used.
• Media files, PDFs, and downloadable assets have been considered where they receive traffic or links.
• Subdomains and alternate hostnames are included if users or bots can still request them.

Implementation location

• You know whether redirects are being applied at the application, web server, load balancer, CDN, or registrar level.
• Rule precedence is understood so one system does not override another unexpectedly.
• Staging and production environments are not behaving differently because of hidden platform defaults.

Common mistakes

Most redirect mapping problems are operational rather than theoretical. The concepts are usually understood; the handoff is where quality drops.

Mapping too late

If URL decisions are still changing days before launch, the redirect map becomes unstable and validation quality falls. Freeze old and new URL lists early enough to review them properly.

Using the homepage as a catch-all

This is one of the most common migration shortcuts. It may look tidy in a spreadsheet, but it weakens relevance and makes troubleshooting harder. Redirect to the nearest equivalent, or allow a true 404/410 where there is no meaningful replacement.

Relying on one data source

A crawl may miss orphaned pages. Analytics may miss low-traffic but important legacy URLs. CMS exports may include draft or blocked content. Good url mapping for migration combines several inputs.

Ignoring host and protocol variants

A clean path-level redirect plan can still fail if HTTP, HTTPS, www, non-www, or old subdomain rules are not unified into a single destination path.

Leaving chains in place

When migrations happen in stages, older redirects tend to remain active. Your redirect map should be periodically normalised so historical paths point straight to the current destination.

Forgetting non-HTML URLs

PDFs, images, feed URLs, attachments, and campaign landing URLs can continue receiving traffic long after a redesign. If they matter, map them explicitly.

Not updating internal references

A website redirect should mainly serve old external or bookmarked URLs. Internal links, canonicals, and sitemaps should already use final destinations. Otherwise, you force both users and crawlers through unnecessary hops.

Confusing canonicalisation with redirecting

Canonical tags suggest a preferred URL; redirects enforce one. They solve different problems and should not be treated as interchangeable. In migrations, server-side redirects generally carry the operational load for retired paths.

When to revisit

Redirect mapping is not a one-off launch task. Revisit it whenever the underlying routing assumptions change. A practical review schedule keeps small issues from compounding into crawl waste, analytics confusion, or lost landing-page equity.

Re-open your redirect map when:

• You are planning a redesign, platform move, or taxonomy change.
• You are introducing a new canonical host, HTTPS policy, or domain strategy.
• You are retiring products, consolidating service pages, or merging content libraries.
• Your team changes redirect tooling, such as moving rules from plugin level to CDN or server level.
• You see traffic drops after URL changes or a rise in legacy 404s.
• You are preparing for seasonal planning cycles and need to confirm campaign destinations still resolve correctly.

A practical maintenance routine looks like this:

1. Keep a master redirect map in a shared location, not scattered across tickets and chat threads.
2. Version it so each launch or cleanup pass has a date and owner.
3. Review 404 logs and top redirected URLs on a set schedule.
4. Collapse chains whenever a destination changes.
5. Retest high-value paths before major campaigns, seasonal peaks, or infrastructure changes.
6. Document exceptions so future teams know why a rule exists.

If you want one final working rule, use this: every old URL should either resolve directly to the best current equivalent or fail clearly for a good reason. A durable redirect map makes that decision explicit, testable, and maintainable. That is why it remains useful long after the migration launch itself.