Website Migration Redirect Checklist and Bulk Redirect Mapping Template

Overview

A migration can involve a new domain, platform, information architecture, URL format, protocol, subdomain or combination of changes. The technical implementation may be straightforward, but the difficult part is deciding where every valuable old URL should lead. A redirect mapping exercise turns that decision into a documented set of source and destination URLs before rules are published.

For most genuinely permanent changes, the intended destination is a server-side 301 redirect. A 302 redirect is generally reserved for a temporary condition where the original URL may return later. The correct status code is only one part of the work: the destination should also be relevant, accessible, canonical and no more than one redirect away from the original URL.

Start with a working copy of the old site and keep the final redirect map under version control or in a shared location. Record who approved changes, when rules were deployed and which platform or server handles them. This makes troubleshooting easier if a redirect chain, loop or unexpected 404 appears after launch.

For a broader planning framework, see Redirect Mapping Template: How to Plan a Website Migration Without Losing SEO.

What to track

1. Build a complete old-URL inventory

Do not rely on the current navigation alone. Combine several sources where available: a crawl of the old site, XML sitemaps, analytics landing pages, server logs, Search Console exports, internal links, external links and URLs supplied by stakeholders. Include important image, document and feed URLs if they are linked or receive visits.

Normalise the inventory without destroying evidence. Keep the full original URL, including protocol, hostname, path and query string, in one column. Add separate fields for the normalised path, URL type, status, traffic or conversion value, backlinks, priority and migration decision. This helps distinguish a genuine page from variations caused by tracking parameters, capitalisation or trailing slashes.

2. Use a one-to-one redirect mapping template

A practical bulk redirect map can use the following columns:

• Old URL: the exact source URL or path.
• New URL: the single intended destination.
• Status: usually 301 for a permanent migration.
• Page type: product, service, article, category, document or other.
• Priority: high, medium or low, based on visits, links, conversions or business importance.
• Rule owner: the person responsible for validating the row.
• Test result: pending, passed or failed, with the date.
• Notes: reasons for consolidation, removal or an exception.

Prefer a direct old-to-new relationship. Sending an old product page to a broad category, then from that category to a new landing page, creates a redirect chain and weakens the clarity of the migration. If there is no genuinely relevant replacement, document the decision rather than forcing every URL to the homepage.

3. Decide how to handle URL variations

Define one canonical format for protocol, hostname, capitalisation and trailing slash treatment. Check that HTTP-to-HTTPS, www-to-non-www or non-www-to-www rules do not conflict with page-level migration rules. Likewise, decide whether query parameters should be preserved, removed or selectively passed through.

Tracking parameters can be useful for campaigns, but they should not create thousands of unintended redirect rows. Review redirects and query parameters before setting blanket rules. If the migration changes international paths or language versions, map those relationships carefully rather than using an automatic location-based redirect; the guidance on hreflang versus redirects is useful here.

Cadence and checkpoints

Before launch

1. Freeze a dated copy of the old-URL inventory.
2. Complete mappings for high-priority URLs first, then work through the remaining list.
3. Check every destination returns a successful response and uses the intended canonical URL.
4. Test representative patterns, including uppercase paths, trailing slashes, query strings, files, pagination and old subdomains.
5. Upload rules to a staging environment or isolated test setup where possible.
6. Confirm that the new XML sitemap contains destination URLs, not old URLs or redirecting URLs.

Use a redirect checker or command-line request tool to inspect status codes and the complete response path. Test from both a browser and an automated process where relevant. A browser can hide intermediate behaviour through caching, while a header inspection can expose the exact sequence of responses.

Launch day

1. Deploy redirects at the correct layer, such as the web server, edge platform, CMS or application.
2. Check the homepage, primary templates and a sample from each URL pattern.
3. Confirm there are no redirect loops, unexpected 404 responses or destination errors.
4. Review protocol and hostname rules so the final URL is reached in one clean step.
5. Submit or update the new sitemap and check key pages manually.
6. Record the deployment time and retain the previous configuration for controlled rollback.

After launch

For the first several days, review crawl errors, server responses, analytics landing pages and redirect volume regularly. Then move to a weekly review before adopting a monthly or quarterly maintenance cycle. Keep a list of newly discovered old URLs and add approved mappings rather than editing production rules without a record.

For large lists, validate the upload format, duplicate sources, blank destinations and accidental spreadsheet transformations before deployment. The bulk redirect upload checklist covers common controls.

How to interpret changes

A rise in 404 responses usually means the inventory missed URLs, a rule pattern is too narrow or an internal link still points to the old structure. A high number of 301 responses is not automatically a problem during a migration, but investigate if many requests pass through two or more redirects.

If a redirect checker reports a loop, compare the rules in order of execution. Common causes include a broad HTTP-to-HTTPS rule combined with a hostname rule, a source pattern that also matches its destination, or CMS logic that conflicts with server configuration. A sudden drop in visits to an important page may indicate an irrelevant destination, a blocked page, a canonical mismatch or a measurement issue rather than a redirect-status problem alone.

Compare like with like when reviewing performance. Separate migration effects from seasonality, campaign changes, tracking changes and normal fluctuations. Track high-priority URLs individually and review aggregate patterns for the rest of the inventory.

When to revisit

Revisit this checklist before every domain change, redesign, CMS replacement, URL restructuring, protocol change or international expansion. During a stable period, perform a monthly review for newly reported 404s and important redirect chains, followed by a more complete quarterly audit of the redirect map, sitemap, canonical URLs and high-value landing pages.

Update the map whenever a product, service or article is retired. Do not remove a redirect simply because its traffic is currently low; first check whether it has useful external links, bookmarked use or a seasonal role. Conversely, do not keep obsolete rules indefinitely without reviewing their destination, ownership and purpose.

For the next migration, create a dated copy of this article’s template structure, assign owners to unresolved rows and set a final test deadline. Run a sample-based redirect checker test, review the first post-launch reports and log every exception. That small record turns a one-off SEO migration into a repeatable process that can be improved at the next checkpoint.

Before publishing changes, use the redirect rule testing checklist and review standardisation rules for uppercase URLs and trailing slashes.