Website Migration SEO Checklist

A migration is a specific kind of change: a new domain, a new CMS or platform, a new URL structure, or a protocol switch. It's a narrower and riskier problem than a general redesign, because the thing changing isn't just the look of the site — it's one of the identifiers search engines use to track the site's history. Our website redesign checklist covers the broader project of relaunching a site — new templates, new content, new structure. This guide is narrower on purpose: it's about the steps that matter specifically when a domain, platform, or URL pattern is changing underneath the site, whether or not the visual design changes at all.

You can do a full visual redesign without a migration (same domain, same platform, same URLs — just a new look). You can also do a migration with zero visual changes (moving from one host or CMS to another with an identical design). The SEO risk profile of each is different, and this checklist is for the migration side specifically: the parts that go wrong because search engines have to re-learn where a page lives, not because a template changed.

Before you touch anything: crawl and inventory the old site

The single biggest cause of a botched migration is working from an incomplete list of what actually needs to move. Don't rely on memory, a sitemap file that might be stale, or "the pages in the main nav." Build a real inventory from three sources and reconcile them against each other:

• A full crawl of the live site with a crawler tool, which finds every URL actually reachable by following links — including old pages that dropped out of navigation years ago but are still live and indexed.
• Search Console's coverage report, which shows every URL Google has indexed, including some that may no longer be linked from anywhere on the site.
• Your analytics data, filtered for organic landing pages over the past 12 to 24 months, to catch pages that get real traffic even if they look unimportant structurally.

Cross-reference these three lists. Any URL that shows up in Search Console or analytics but wasn't caught by the crawl is a page you didn't know was live and indexed — exactly the kind of page that gets missed and silently 404s after launch if it isn't found now.

Building the redirect map — the highest-stakes step

Every URL from your inventory needs a mapped 301 redirect to its closest equivalent on the new site. "Closest equivalent" matters — redirecting every old URL to the new homepage is a common shortcut that preserves almost none of the ranking value, because search engines evaluate redirects based on how closely the target page matches the content and intent of the original. A blog post about drain cleaning should redirect to its new URL or, at minimum, the closest matching page on the new site — not to the homepage as a catch-all.

1. Map every URL individually where possible. Bulk pattern-based redirects (e.g., /old-blog/* to /blog/*) work when the structure is truly parallel, but verify a sample of them resolve correctly rather than assuming the pattern holds for every case.
2. Avoid redirect chains. If an old URL already redirects somewhere, point the new redirect at the final destination directly, not through the old chain — each extra hop adds latency and dilutes signal slightly.
3. Test the map on staging before launch, checking that every mapped URL actually resolves to a live page and not a broken link on the new site.
4. Keep the map itself as a saved document or spreadsheet, not just implemented rules you can't easily audit later if something needs to be traced back.

Migration-specific technical steps

Domain change

A domain change is the highest-risk migration type because every backlink pointing to the old domain now points to a URL that, without a redirect, no longer exists from search engines' point of view. Beyond the redirect map, verify domain ownership for the new domain in Search Console before launch, and keep the old domain's Search Console property active after launch — Google shows a "change of address" signal there for supported domain moves, and you'll want to keep monitoring the old property for lingering indexed URLs.

Platform or CMS change

Moving from one CMS to another (WordPress to a headless setup, a page builder to a custom build, one e-commerce platform to another) risks losing structured data, meta tag control, and URL patterns that were previously handled automatically by the old platform. Confirm the new platform gives you the same level of control over title tags, meta descriptions, canonical tags, and schema markup before committing — some platforms are noticeably more restrictive than others.

URL structure change

Changing the URL pattern itself — adding or removing a subdirectory level, switching from query parameters to clean URLs, changing a trailing slash convention — is a migration even if the domain and platform don't change. Every URL is technically a new URL as far as search engines are concerned, which means the full redirect map treatment applies even though it might feel like a minor tweak.

Protocol change (http to https)

If the site isn't already on https, moving to it is itself a URL change for every page on the site, and needs the same redirect treatment — http versions 301'd to their https equivalents, sitewide, with no exceptions left resolving on the old protocol.

Launch day

• Confirm the redirect map is live and spot-check a sample of both high-traffic and low-traffic URLs.
• Submit an updated XML sitemap reflecting the new URLs through Search Console immediately.
• If it's a domain change, use Search Console's change-of-address tool where available.
• Update internal links across the site to point directly to new URLs rather than relying on redirects to catch internal navigation — redirects should be a safety net for external links and old bookmarks, not the primary path for your own site.
• Update the URL in your Google Business Profile, email signatures, social bios, and any paid ad destination URLs.

Post-launch: before/after crawl comparison and rank monitoring

This is the step migrations most often skip, and it's the one that catches problems before they become expensive. Run a fresh crawl of the new live site and compare it directly against your pre-migration inventory: every old URL should either resolve on the new site or redirect cleanly with a 200 status at the final destination — not a 404, not a redirect chain, not a soft 404 (a page that returns a 200 status but shows a "not found" message).

• Weeks 1-2: check Search Console's coverage report daily for a spike in 404 or 'submitted URL not found' errors, which almost always point to a gap in the redirect map.
• Weeks 1-4: track rankings for your most valuable existing keywords daily or every few days, watching for pages that drop sharply — that usually traces back to one specific missed or incorrect redirect.
• Weeks 4-12: watch organic traffic trends in aggregate against your pre-migration baseline, and confirm Search Console's indexed page count on the new domain or structure is converging toward your full inventory count, not stalling well below it.
• Keep the pre-migration crawl data archived for at least three months so you have something concrete to diff against if a problem surfaces later.