Website Migration Redirect Checklist: 15 Checks Before You Flip DNS

A website migration succeeds or fails on redirect discipline more often than design, code, or launch messaging. Before you flip DNS, the critical question is simple: can every important old URL reach the correct new destination in one clean hop?

This checklist is designed for teams moving:

• to a new domain
• to a new CMS
• from monolith to headless
• from subdomain to root domain
• from legacy docs or blog structures to a cleaner URL system

If you need a Shopify-specific example, read our guide to migrating Shopify URLs to headless storefronts. This article is the broader checklist you can apply to almost any stack.

If your move also includes a domain change with wildcard forwarding, keep how to redirect a domain without losing paths or UTM parameters nearby while you work through the checklist below.

The non-negotiable goal

Before launch, you want all five of these to be true:

1. high-value old URLs map to the right new URLs
2. permanent moves use permanent redirect intent
3. redirects resolve in one hop whenever possible
4. internal links already point to the new canonical URLs
5. post-launch monitoring is ready before traffic shifts

If one of those is missing, your migration risk goes up fast.

The redirect checklist

1. Inventory your current URLs

Do not plan redirects from memory.

Pull URLs from:

• XML sitemaps
• analytics landing pages
• Search Console top pages
• paid campaign URLs
• email templates
• backlinks and partner docs
• old blog and docs archives

If a URL gets search traffic, conversion traffic, or support traffic, it belongs in the migration inventory.

2. Choose the final canonical hostname early

Decide the final destination standard before writing redirect rules:

• https://newsite.com
• or https://www.newsite.com

Do not leave host decisions vague. This is how chains like http -> https -> www -> final appear.

3. Keep a redirect map in a real sheet or CSV

At minimum, track:

old_url,new_url,status,priority,owner,notes
https://oldsite.com/pricing,https://newsite.com/pricing,301,high,marketing,core landing page
https://oldsite.com/docs/api,https://newsite.com/docs/api,301,high,engineering,docs migration

This gives marketing, SEO, engineering, and support one shared source of truth.

4. Protect the highest-value URLs first

Prioritize pages that matter most:

• homepage
• pricing
• docs
• top organic landing pages
• campaign pages
• support URLs linked from emails

Do not give low-traffic archive pages the same attention as your top conversion paths on day one.

5. Match old URLs to the best new destination

The goal is not always one-to-one path preservation. The goal is best destination fit.

Good examples:

• old product page -> new product page
• old docs page -> equivalent docs page
• removed campaign page -> closest current offer page

Bad examples:

• everything -> homepage
• retired docs -> homepage
• broken deep links -> generic category page with no context

6. Use permanent redirects for permanent moves

If the old URL is not coming back, use a permanent redirect policy.

If you are not sure which code to choose, see 301 vs 302 vs 307 vs 308 redirects.

The key point is not to leave a permanent site move running on temporary intent for months.

7. Preserve path structure where it still makes sense

If your new site keeps a similar structure, path-preserving rules reduce manual work.

Examples:

• /docs/* -> /docs/*
• /blog/* -> /blog/*
• /features/* -> /features/*

When structure changed substantially, use explicit one-to-one mappings for the high-value paths instead of blind wildcards.

If you need the implementation pattern for that setup, read how to redirect a domain without losing paths or UTM parameters.

8. Preserve important query strings

This matters for:

• campaign attribution
• affiliate parameters
• tracking and lifecycle links
• functional parameters used by the app or page

Not every query string deserves to survive forever, but important ones should be handled deliberately.

9. Eliminate redirect chains before launch

Do not wait for PageSpeed or users to tell you the redirect path is messy.

Collapse chains now:

old-url -> old-intermediate -> final-url

should become:

old-url -> final-url

If you need a deeper debugging workflow, read Redirect Chains and Loops.

10. Test on staging or controlled hosts

Before public cutover, test:

• homepage
• top landing pages
• docs paths
• blog posts
• parameterized URLs
• mobile-targeted paths if they exist

Run both browser checks and simple command-line checks:

curl -IL https://oldsite.com/docs/api

11. Update internal links before or immediately after launch

Redirects are a safety net. Internal links should still point directly to the new canonical URLs.

That includes:

• nav links
• footer links
• in-content links
• product CTAs
• docs sidebars
• email templates if the migration changes public URLs

12. Update sitemap, canonicals, and navigation

The redirect map is only one part of the migration. Also update:

• XML sitemap
• canonical tags
• hreflang if relevant
• main navigation
• structured data URLs where necessary

If your redirects say one thing and your canonicals say another, you are creating cleanup work for yourself later.

13. Prepare post-launch monitoring before launch

Have a plan for the first 7 to 14 days:

• watch 404s
• inspect top redirected URLs
• monitor traffic to high-value pages
• review campaign links
• confirm docs and support links still land correctly

This is where analytics, redirect checking, and broken-link monitoring become operationally useful instead of theoretical nice-to-haves.

14. Keep the old redirect layer stable long enough

One launch mistake is to treat redirects as a one-week task. In reality, old links can keep receiving traffic for months or years.

That is especially true for:

• backlinks
• bookmarks
• PDF links
• partner docs
• old social posts

Plan for redirect durability, not just launch-week survival.

15. Document exceptions and edge cases

Not every URL deserves a redirect. Some should return 404 or 410. Some legal or support pages may need special handling. Some old app routes may require device-aware logic instead of plain redirects.

Document those cases explicitly so they do not become mystery behavior later.

A practical migration order of operations

If you want the shortest workable rollout sequence:

1. export URLs
2. choose canonical host
3. create redirect map
4. test top URLs
5. eliminate chains
6. update internal links and sitemap
7. launch
8. monitor 404s and redirected traffic

This order keeps the work understandable across engineering, marketing, and SEO stakeholders.

Where UrlEdge helps

UrlEdge is a good fit when your migration needs:

• bulk redirect import
• wildcard path forwarding
• fast global propagation
• redirect QA tooling
• post-launch traffic visibility

It is especially useful when you do not want redirect logic scattered across app code, reverse proxies, CMS plugins, and DNS-provider forwarding features.

FAQ

Should every old URL redirect somewhere?

No. Some obsolete URLs should return a real error state. But the pages that still have business value or user expectations should map to a relevant destination.

Is redirecting everything to the homepage acceptable?

Usually no. It is one of the weakest migration strategies because it throws away path intent and frustrates both users and crawlers.

How long should I keep migration redirects?

Longer than most teams expect. Important redirects often need to stay in place well beyond launch month.

What should I test first if time is short?

Prioritize homepage, pricing, docs, top landing pages, campaign links, and the URLs with the strongest historical traffic.

Related UrlEdge guides

• Bulk URL management
• Permanent 301 redirects
• Redirect chains and loops
• Shopify to headless redirect migration

Authoritative references

• Google Search Central: site move with URL changes
• MDN: Redirections in HTTP