Website Migration Checklist: How to Move Platforms Without Losing Rankings

A website migration checklist is not a packing list for files. It is the sequence that keeps rankings, analytics, and form submissions intact while the URL space changes.

Teams lose traffic on migrations for boring reasons: the redirect map was built from memory, staging was indexed, the new sitemap listed 301s, or the CMS generated a second set of URLs with trailing slashes. None of that is mysterious. It is skipped work.

Google's own notes on site moves are in Moving a site. This article is the operator version: what I actually check when a company leaves WordPress, Webflow, Wix, or a custom stack.

What counts as a migration

If the URL, host, protocol, CMS, or template system changes, treat it as a migration. A 'just a redesign' on the same Webflow project can still be a migration if slugs change. A domain change is always a migration. HTTPS-only cutovers are migrations. Ignoring the label does not protect the index.

Part 1: Freeze a baseline

You cannot prove a migration worked if you never measured the old site.

1. Crawl every indexable URL. Save status, canonical, title, H1, word count, inlinks.
2. Export Search Console queries and pages for the longest window you have.
3. Export Analytics landing pages, conversions, and the exact tracking IDs in use.
4. List backlinks to the top URLs if you have a backlink export. Those destinations are sacred.
5. Photograph the live robots.txt, sitemap index, and header/footer nav. You will need them when someone 'simplifies' navigation.

Part 2: Decide what must not change

Write a one-page rule set before design starts:

• Which slugs stay identical.
• Which sections can be merged, and into which surviving URL.
• Whether blog dates, authors, and canonicals stay in the CMS fields.
• Whether the site stays on the same domain.
• Who can edit robots.txt after go-live.

If a URL earned clicks last year, it needs a destination this year. 'We dropped that page' is not a strategy.

Part 3: Build the redirect map from data

Start from the crawl, not from the new sitemap. For every old 200 URL:

1. Keep the same path when the content still exists.
2. Map to the closest equivalent when two pages merge.
3. Map thin or outdated URLs to the parent hub, not the homepage, unless there is no parent.
4. Do not map everything to the homepage. Google treats that as a soft 404 pattern.
5. Use 301 for permanent moves. Do not leave launch-day 302s in place.

One hop only. Old URL to final URL. Test the map on staging with a sample of 50 high-value paths before launch day.

Part 4: Staging rules that prevent an indexing accident

• Password-protect staging, or noindex plus robots Disallow, preferably both.
• Do not point production canonicals at staging.
• Do not submit a staging sitemap to the production Search Console property.
• Keep production analytics IDs off staging or you will pollute conversion history.
• Confirm the new CMS is not emitting two hosts, www and apex, as indexable.

Part 5: Recreate the technical layer on the new stack

The new site needs the same jobs the old site did, even if the CMS is prettier.

• Canonical tags on every indexable template.
• XML sitemap of 200, canonical, indexable URLs only.
• robots.txt that allows those URLs and lists the sitemap.
• Schema you already had, re-implemented in the new components.
• hreflang if you had localized URLs, with working return tags.
• 404 template that is a real 404, not a 200 soft 404.

Part 6: Launch day sequence

1. Put the site in a short maintenance window if DNS is changing.
2. Enable the 301 map before you send traffic.
3. Verify HTTPS and the certificate on the live host.
4. Fetch the homepage, a service page, and a blog post as Googlebot.
5. Submit the new sitemap in Search Console.
6. Use URL Inspection on the top 10 money pages.
7. Confirm forms, booking, and checkout still post to the right place.

If you also changed domains, add both properties in Search Console and use the address change tool when it applies. DNS and Search Console are not the same job.

Part 7: The first 30 days

Crawl production the day after launch and again at day 7 and day 30. You are looking for leftover 404s, accidental noindex, missing titles, and pages that still resolve on the old host.

In Search Console, watch coverage and the top landing pages. A temporary dip can happen. A cliff on the same 20 URLs usually means the redirect or canonical is wrong.

Keep the old hosting and redirect layer live until the crawl stats show Google has processed the map. Turning off the old server on Friday night is how migrations get folklore.

Common failure modes I still see

• New CMS adds /home or /index to the root.
• Blog slugs change from /journal/ to /blog/ with no map.
• Case studies move to a new collection and lose their inbound links.
• The new robots.txt copies a Webflow or Next.js starter that Disallows /api and accidentally Disallows more.
• Tag manager is reinstalled twice and conversion counts double for a week, then someone 'fixes' history.

If the migration is part of a larger rebuild, run the technical SEO audit first. The audit tells you what to protect. The migration checklist tells you how to move it.

I help teams move platforms without treating SEO as a post-launch apology. If you already have a date on the calendar, the useful time to talk is before the new slugs are locked.