The website migration redirect checklist

Before launch: collect and map

• Export every URL that matters. Use your sitemap, Search Console’s Pages report, analytics and backlink data. Google’s site move guide lists the same sources.

• Include files, not only pages. PDFs, images and downloads linked from other sites need redirects too.

• Map each old URL to one new URL. Use a spreadsheet with two columns: old and new.

• Group repeating patterns. If /news/* becomes /blog/*, one wildcard rule beats hundreds of single ones.

• Decide what can return 404. Not every URL needs a redirect. See do you need to redirect every URL.

• Avoid sending everything to the homepage. Map pages to their closest match instead.

• Point old URLs at final URLs. No chains through intermediate addresses.

• Choose permanent redirects. Use 301 or 308 for a move that isn’t coming back.

Before launch: decide where redirects live

• Same domain, new platform: redirects can live in the new platform, or in a separate redirect layer.

• New domain: the old domain needs something to answer for it after the old hosting is gone. Keep the domain registered and connect it to a redirect service.

• Keep redirects in one place. Avoid splitting them between the old host, the new CMS and the registrar.

• Keep the old domain. Google recommends keeping it for at least a year after a move.

Before launch: prepare

• Save a sitemap of the new URLs. You’ll submit it right after launch.

• Update internal links on the new site, so they point to new URLs directly, not through redirects.

• Update canonical tags on new pages to point to themselves.

• Lower your DNS TTL a day or two before, if you’re changing DNS, so the switch spreads faster.

• Write the test list. Pick 20–50 old URLs that cover every pattern.

Launch day

• Import your redirect rules. With Redirect Supply you can upload them in one go via CSV import.

• Switch DNS or publish the new site.

• Test the list with our redirect tester. Check http://, https://, www and non-www.

• Check status codes. Each old URL should return a single 301 or 308, then a 200 on the new page.

• Look for loops and chains. Especially around HTTPS and www settings.

• Submit the new sitemap in Search Console.

• Use the Change of Address tool if the domain changed. See our guide to using Search Console after a domain change.

The first two weeks

• Watch for 404s. Search Console and your analytics will show old URLs you missed. Add rules for the ones with real traffic or links.

• Check redirect traffic. Analytics on the old domain tell you which URLs are still used.

• Expect some movement in rankings. Google says it can take a few weeks or more for new URLs to replace old ones on medium sites.

• Update the links you control. Email signatures, social profiles, ads, documentation and partner listings.

Months later

• Keep the redirects running. At least a year, longer if old URLs still get visits.

• Renew the old domain. An expired domain takes its redirects with it.

• Review the rules once in a while. Remove rules nobody hits, and fix any that now point to pages you’ve since moved.

Who should own each step

Migrations go wrong when everyone assumes someone else has the redirects. Before launch, agree on:

• Who builds the redirect map: usually SEO or content, with input from whoever knows the old site.

• Who imports and tests the rules: whoever controls the redirect tool.

• Who changes DNS: whoever has access to the domain’s DNS provider.

• Who watches for 404s after launch, and how often.

Write the names next to each line of the checklist. It takes five minutes and saves a lot of guessing on launch day.

One last tip

The redirect map is the most valuable document in a migration. Keep it after launch. The next time you move, it’s the starting point for your next map.

For a broader look at what happens after launch, read what happens to old URLs after a website migration.