Redirect Mapping Template: How to Plan a Website Migration Without Losing SEO

Overview

Redirect mapping is the process of recording which existing URL should send visitors and search engines to which replacement URL. It is most useful during a domain change, redesign, CMS migration, URL restructure, HTTP-to-HTTPS move, or consolidation of overlapping pages.

The objective is not to redirect every old URL to the homepage. It is to preserve a clear relationship between the old resource and the most relevant available destination. Where a page has a genuine replacement, a permanent 301 redirect is usually the appropriate starting point for a completed migration. A 302 redirect is intended for a temporary routing decision and should not be used simply because the final destination has not yet been planned.

Keep the redirect map as a working document rather than a one-off export. The same file can support developers, SEO teams, content owners and testers. It should show the original URL, the proposed destination, the redirect type, the reason for the change and the result of testing.

Reusable redirect mapping template

Set up a spreadsheet or CSV with one row per old URL. These columns provide a practical minimum:

• Old URL: the complete source URL, or the path and query string if the server rule is host-specific.
• New URL: the exact final destination, including the preferred protocol and hostname.
• Redirect type: normally 301 for a permanent move, or 302 where the routing is genuinely temporary.
• Page type: such as product, service, article, category, listing or document.
• Match reason: for example, “same product”, “replacement guide” or “category consolidated”.
• Owner: the person responsible for confirming the destination.
• Test status: not tested, passed, failed or needs review.
• Notes: record query parameters, language variants, trailing slash rules or exceptions.

Do not include several possible destinations in one row. A redirect rule should resolve to one deliberate endpoint. If a destination is uncertain, mark the row for review rather than silently sending it somewhere broad.

Checklist by scenario

1. Domain or hostname migration

• Export URLs from the old domain, including important pages that may not appear in the current navigation.
• Map each old URL to its equivalent path on the new domain.
• Decide whether the preferred version uses HTTPS, www or non-www, and apply that choice consistently.
• Confirm that the old domain remains available to serve redirects for as long as the migration plan requires.
• Test both the old hostname and common variants, such as HTTP and HTTPS, where they are expected to work.

A domain change is separate from a content rewrite. If the page has also changed subject or purpose, assess the relevance of the destination rather than copying the old path mechanically. For related international or language versions, see Hreflang vs Redirects.

2. URL structure or CMS migration

• Compare the old and new URL patterns before creating individual rules.
• Use a pattern-based rule only when the relationship is consistent and can be tested with representative examples.
• Create explicit exceptions for pages that do not follow the general pattern.
• Check capitalisation, encoded characters, file extensions and trailing slashes.
• Update internal links, XML sitemaps and canonical tags so the new URLs are used directly.

Rules for uppercase and lowercase paths or trailing slashes can be useful, but they should form one consistent normalisation policy. Supporting guidance is available in Uppercase to Lowercase URL Redirects and Trailing Slash Redirects.

3. Content consolidation

• List every old page that will be removed or merged.
• Choose the strongest surviving page based on topic, intent and user need.
• Redirect related pages to that specific replacement, not automatically to the site root.
• Record pages with no suitable replacement for a separate decision.
• Review internal links pointing to the retired pages and update them where possible.

A redirect is not a substitute for deciding what content should exist. If no relevant replacement is available, a carefully considered response may be more appropriate than a misleading redirect.

4. Campaign, QR and tracked URLs

• Identify short links, QR code destinations and campaign URLs before launch.
• Confirm whether tracking parameters should be preserved, removed or rewritten.
• Test the final landing page with representative UTM parameters.
• Keep campaign routing separate from the core migration rules where possible.
• Document any destination that is intentionally temporary.

Query strings can affect attribution and destination matching. Use the guidance in Redirects and Query Parameters and UTM Link Tracking Best Practices before applying broad query-string rules.

What to double-check

Before implementation, review the map in both directions: from old URL to new URL, and from new URL back to the pages expected to feed it. This catches missing rows and accidental many-to-one mappings.

• Status codes: check that permanent moves return 301 and temporary routes return 302 where appropriate. Avoid treating a successful 200 response from an unexpected page as a valid redirect result.
• Final destination: each source should reach the intended canonical URL directly, using the correct protocol, hostname, path and slash format.
• Redirect chains: an old URL should not go to an intermediate URL that redirects again. Replace the chain with a direct source-to-final-destination rule.
• Redirect loops: test for rules that send a URL back to itself or create a cycle between two or more URLs.
• Errors: check for 404, 410, 403 and server-error responses at both the source and destination.
• Query strings: verify that useful parameters survive and that unwanted parameters do not create duplicate or invalid destinations.
• Canonicalisation: make sure canonical tags, internal links and redirects point towards the same preferred URL. A canonical tag is not a replacement for a required redirect.
• Environment: test on a staging or controlled environment first, then repeat checks against production after deployment.

For a detailed test sequence, use the Redirect Rule Testing Checklist. A redirect checker or command-line HTTP request can confirm the status code and reveal every hop in the response.

Common mistakes

• Redirecting everything to the homepage: this removes useful context and may leave visitors without the information they expected.
• Mapping only the navigation: old landing pages, documents, feeds, campaign URLs and externally linked pages can still receive traffic.
• Using a 302 for a permanent move: choose the status based on the intended duration, not on which rule is easiest to configure.
• Creating a chain after launch: mapping to an old URL that already redirects adds an unnecessary hop. Always resolve the final destination first.
• Mixing normalisation rules: inconsistent HTTP/HTTPS, www/non-www, case and slash behaviour can produce duplicate URLs or loops.
• Ignoring parameters: a rule that works for a clean path may break a tracked campaign URL or discard useful attribution.
• Uploading an unreviewed bulk file: duplicated source rows, blank destinations, malformed URLs and incorrect delimiters can create widespread failures. Follow a controlled process for bulk redirect uploads.
• Removing redirects immediately: retiring rules before checking external links, bookmarked URLs and residual traffic can create avoidable dead ends.

When to revisit

Review the redirect map whenever the underlying URLs, rules or traffic sources change. This includes before a seasonal planning cycle, a new site section, a CMS or hosting change, a domain renewal decision, a campaign launch, or a further content consolidation project.

Use a simple recurring workflow:

1. Export recently requested old URLs and compare them with the existing map.
2. Investigate new 404s, unexpected status codes, chains and loops.
3. Check that important external and campaign links still reach the intended destination.
4. Update the source file, rule set and implementation notes together.
5. Re-test a sample of unchanged rules after every platform or server change.
6. Archive superseded versions so the reason for each major change remains traceable.

To put this template into action, first freeze the migration URL list, then fill in one row for every old URL. Resolve uncertain matches with the relevant content owner, identify the final canonical destination for each approved row, and test the rules before publishing. After launch, run the same checks against the live website and keep the map as the reference record for future changes.