SEO Migration Checklist: Keep Your Rankings When You Move

An SEO migration checklist is the list of tasks that protect your search visibility when you change domains, platforms, hosts or URL structures. The core of it is simple: record what you have, map every old URL to its new home with a permanent redirect, make sure the new site is crawlable and complete, and watch closely after launch. The detail is where migrations succeed or fail, so this checklist goes step by step.

Use it as a working document. Copy the items into your project tracker, assign an owner to each, and do not launch until the pre-launch items are ticked.

Before you start: scope your SEO migration checklist

The right SEO migration checklist depends on what is changing. Write down which of these apply:

• Domain change (new domain, or merging sites).
• Platform change (for example a website builder to WordPress).
• URL change (new slugs, folders or structure on the same domain).
• Hosting change only (same domain, same URLs, new server).
• Design or template change that may alter content, headings or internal links.

A hosting-only move needs fewer search tasks than a domain plus platform change. If you are unsure which type you are dealing with, our overview of what website migration is explains each one. Where possible, avoid changing everything at once; separating the moves makes problems easier to trace.

Phase 1: Benchmark the current site

You cannot judge a migration without a “before” picture. Capture these and store them somewhere that will survive the move:

1. Export Google Search Console performance data (queries and pages) for a meaningful recent period.
2. Export landing page data from your analytics tool: sessions, conversions and revenue by page.
3. Record rankings for your priority keywords if you track them.
4. Take note of Core Web Vitals and page speed for key templates.
5. Export your backlink profile from a tool such as Ahrefs, and note the pages with the most referring domains.
6. Save a copy of the current robots.txt, XML sitemaps and redirect rules.

The output of this phase is a short list of your most valuable pages: the ones that bring traffic, leads, sales or links. These get the most attention in every later step.

Phase 2: Build a complete URL inventory

Your redirect map is only as good as your list of old URLs. Do not rely on a single source. Combine:

• A full crawl of the live site with a crawler such as Screaming Frog.
• All URLs in your XML sitemaps.
• Pages with impressions or clicks in Search Console.
• Landing pages from analytics.
• Pages with backlinks from your link tool.
• Image and PDF URLs that get traffic or links.

Remove duplicates and normalise the list (protocol, trailing slashes). You will usually find pages that the crawler missed but that still get search traffic, which is exactly why you merge sources.

Phase 3: Map redirects one by one

For every old URL that changes, decide where it goes. The rules:

• Use permanent server-side redirects (301 or 308) from each old URL to its new equivalent.
• Redirect like for like. An old service page goes to the new service page, not the home page. Google’s site move guidance specifically warns against redirecting lots of old URLs to one irrelevant destination.
• Go straight to the final URL. No chains of redirect after redirect.
• Decide what is not moving. Pages with no equivalent and no value can return 404 or 410. Pages with links or traffic should go to the closest relevant page.
• Update old redirects too. If the old site already redirected A to B, and B is now moving to C, change A to point directly to C.

Keep the map in a spreadsheet with columns for old URL, new URL, status code, priority and a “tested” checkbox.

Phase 4: Prepare the new site on staging

Build and check the new site before anyone outside the project sees it.

• Block staging from search engines with password protection, and use noindex as a second layer.
• Carry over title tags, meta descriptions and H1s for every page, especially your valuable pages.
• Check that body content moved completely. Platform exports often drop certain blocks or page types.
• Update internal links to point straight at new URLs, rather than relying on redirects.
• Set self-referencing canonical tags on the new URLs.
• Update hreflang tags if you run multiple languages or regions.
• Carry over structured data (Organization, Article, Product, Breadcrumb and so on).
• Generate new XML sitemaps containing only the new, indexable URLs.
• Install analytics, tag manager, ad conversion tags and consent tooling.
• Test forms, checkout, search, logins and any integrations.
• Crawl the staging site and fix broken links, missing titles and duplicate content.
• Compare page speed with your benchmark from Phase 1.

Phase 5: Launch day checklist

Pick a launch window when traffic is lower and the team is available for a few days afterward. Then work through:

1. Take a final backup of the old site and its database.
2. Put the new site live and the redirect rules in place.
3. Remove the staging password and every noindex tag. Check robots.txt does not block the site.
4. Test your redirect map: run the old URL list through a crawler in list mode and confirm each one returns a single redirect to the right destination with a 200 at the end.
5. Spot-check high-value pages by hand in a private browser window.
6. Confirm HTTP to HTTPS and www to non-www (or the reverse) redirect in a single hop.
7. Submit the new sitemaps in Search Console.
8. For a domain change, verify the new domain in Search Console and use the Change of Address tool from the old property. Google notes this tool is only for moves between domains or subdomains.
9. Check analytics is recording visits and conversions in real time.
10. Confirm email still works if DNS changed.

Keep the old sitemaps available briefly after launch if it helps search engines discover the redirects, then remove them once the new ones are in use. The details are in Google’s guide to site moves with URL changes.

Phase 6: Monitor and fix after launch

The first few weeks after launch are when you catch the problems your checks missed.

Daily for the first week or so

• Check Search Console for crawl errors, and the Pages report for new 404s, soft 404s and redirect errors.
• Watch server logs or your host’s error logs for spikes in 404 and 5xx responses.
• Check that conversions are still coming through.

Weekly for the following weeks

• Compare clicks and impressions for your valuable pages against the benchmark.
• Use URL Inspection on key pages to confirm Google has picked up the new canonical URL.
• Re-crawl the old URL list to make sure redirects still work after any later deploys.
• Ask sites with your most important backlinks to update their links to the new URLs.

Expect some movement. Google says ranking fluctuation during a move is normal and that rankings settle over time, with larger sites taking longer. What you are watching for is anything that does not recover, which usually points to a specific missing redirect, lost content or a technical block.

Common migration mistakes to avoid

• Launching with noindex still on. The most common and the most damaging. Check it first.
• Removing redirects too early. Google recommends keeping them for at least a year; keeping them indefinitely is reasonable.
• Letting the old domain expire. If the old domain lapses, every redirect stops working. Renew it.
• Ignoring parameter URLs. On our own site, many “Page with redirect” reports in Search Console came from ?filter- parameter URLs. We now block those in robots.txt. Check how your new platform handles parameters before launch.
• Changing content and URLs at the same time without recording what changed, which makes it hard to tell why a page dropped.
• Skipping the inventory and only redirecting pages that appear in the navigation.

For platform moves, the content checks matter even more; our guide to moving from Squarespace to WordPress covers the content that commonly gets left behind in that export.

When to bring in help

If your site earns a meaningful share of its leads or sales from search, has many pages, or is changing domain and platform together, it is worth having someone who has run migrations before own the plan. Our website migration specialists handle the inventory, redirect mapping, launch and monitoring, and you can reach us at support@growthscribe.com.

FAQ

What should an SEO migration checklist include?

At minimum: a benchmark of current traffic and rankings, a complete URL inventory, a one-to-one redirect map, staging checks for content, metadata and tracking, launch-day tests of redirects and robots settings, new sitemaps, and several weeks of monitoring in Search Console and analytics.

How long should I keep redirects after a migration?

Google recommends keeping redirects for as long as possible, generally at least a year, so signals can transfer to the new URLs. Many sites keep them indefinitely, which also helps visitors using old links and bookmarks.

Do I need the Change of Address tool for every migration?

No. Google’s Change of Address tool is only for moving from one domain or subdomain to another. For a hosting move or URL changes on the same domain, you rely on redirects, updated internal links and new sitemaps instead.

Will my rankings drop after a site migration?

Some temporary fluctuation is normal while search engines process the move, and Google says rankings settle over time. A lasting drop usually points to a fixable problem, such as missing redirects, lost content or a noindex tag left on, so investigate any page that does not recover.