Site Migration SEO: Domain Changes, Platform Switches, and Redesigns Without Losing Rankings

No migration plan can guarantee that rankings and traffic stay where they were. Google’s site move guide says to “expect temporary fluctuation in site ranking during the move” while Google recrawls and reindexes, and notes that for medium-sized sites it can take “a few weeks or more” for Google to show new URLs instead of old ones, longer for large sites (Google’s guide to moving a site with URL changes). What a plan can do is remove the avoidable causes of loss: unmapped URLs, irrelevant redirects, leftover staging blocks, broken internal links and missing content. Domain changes, platform switches and redesigns share the core risks listed in the register below.

Three kinds of migration

A single project can combine two or three of these. Each additional change multiplies what can go wrong and makes it harder to tell which change caused a problem. Where the schedule allows, separate them.

The migration risk register

Before any work starts, list each risk with its owner and its check. A starter register:

The launch QA sequence

Before launch

1. Inventory every URL that matters. Combine the CMS export, sitemaps, analytics landing pages, Search Console top pages and URLs with external backlinks.
2. Benchmark. Export performance, indexed counts and top pages for comparison.
3. Map old URLs to new URLs. One to one where possible. Google’s guide warns: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site”.
4. Build the new site in staging with protection, preferably password protection, so it is not indexed early.
5. Test redirects in staging against the full mapping, and write down the rollback plan: which launch-day failures would trigger it and how the previous configuration is restored.
6. Update internal links, canonicals, hreflang and structured data to new URLs. Google’s guide lists changing internal links from old URLs to new URLs as a step in the move.

On launch day

1. Remove staging protection on production and confirm robots.txt and meta robots allow crawling. Google’s guide lists leftover noindex and robots.txt blocks among common mistakes.
2. Activate redirects (permanent, server-side, single-hop; see redirect chains and loops).
3. Publish new sitemaps listing the new URLs.
4. For a domain change, use the Change of Address tool in Search Console. Google states it is not needed for HTTP to HTTPS moves.
5. Spot-check redirects, status codes, canonicals and rendered content on every template.

After launch

1. Crawl the old URL list daily for the first week: every old URL should return a single permanent redirect to its mapped destination.
2. Monitor Search Console: Page indexing (new URLs rising, old URLs moving to “Page with redirect”), Crawl Stats (Google says it will temporarily crawl the new site more heavily than usual), Performance by old and new URLs.
3. Watch for 404 spikes in logs and reports and add missing mappings.
4. Keep redirects. Google’s guidance: “generally at least 1 year”, and from a user’s perspective, indefinitely.

Domain-specific notes

Domain changes. Verify both the old and new domains in Search Console before launch, and keep the old domain registered and its redirects running. Ask important external sites to update their links. Google’s guide notes that the move is complete only after Googlebot has visited every URL on the old and new sites at least once, and that there are no fixed crawl frequencies.

Platform switches. Platforms impose URL patterns (/products/, /collections/, .html suffixes). Decide early whether to keep old URLs with routing rules or accept new patterns with redirects. Check how the platform handles canonicals, pagination, faceted URLs, trailing slashes and robots meta defaults.

Redesigns. If URLs stay the same, the risks move to content and links: removed text, merged pages, navigation that drops sections, and JavaScript-dependent menus. Compare top pages old versus new for headings, main content, internal links and structured data.

Small sites vs large sites

Google’s guide recommends that small or medium sites move all URLs at once rather than section by section, which “helps our algorithms detect the site move and update our index faster”. Large sites can move one section at a time. Moving in sections makes problems easier to isolate but extends the period of mixed signals.

A combined domain and platform move

A hypothetical online store is moving from oldstore.example to newstore.example and from one ecommerce platform to another at the same time, with 25,000 URLs.

• Inventory: 25,000 URLs from the database; 1,900 with external backlinks; 600 driving most organic traffic.
• Mapping: product and category URLs mapped one to one; 3,000 discontinued products mapped to successors where they exist, otherwise left as 404.
• Decision: the owner postpones a planned navigation redesign until three months after the move, so any traffic change can be attributed.
• Launch: redirects active, Change of Address submitted, new sitemaps submitted.
• Week 1: a crawl of the old list finds 140 URLs returning 404 because of a mapping export error; mappings are added the same day.
• Weeks 2 to 8: watch impressions shift from old to new URLs in the Performance report, and expect temporary fluctuation.
• What to expect: how long the fluctuation lasts cannot be planned; Google says fluctuation is normal and does not commit to a timeline.

A migration succeeds when every old URL leads somewhere useful in one step, the new site carries everything that made the old one work, and the team can see within days, not months, when something does not.