Site Migration SEO: How to Change Domain Without Losing Rankings (2026)

Site migrations are the highest-stakes technical SEO project in the industry. Done right, they are invisible to Google. Done wrong, they can erase years of accumulated ranking authority in days. Every team we have seen take a migration lightly, treating it as “just a domain change” or “just a platform switch,” has paid the price in traffic drops that take quarters to recover, sometimes fully, sometimes not.

This guide is the field manual our team at Kerkar Media follows on every migration engagement. It covers pre-migration planning, redirect map strategy, launch-day protocols, post-launch monitoring, and recovery from migrations that went wrong. It builds on our companion guides on 301 vs 302 redirects, canonical tags, and HTTP errors.

1. What Is a Site Migration?

A site migration is any change to a website that affects a meaningful number of URLs, the domain itself, the platform serving the content, or the underlying structure of how pages are organised. From an SEO perspective, migrations matter because they change the addresses of pages that have accumulated ranking signals over time.

The core SEO risk in a migration is this: your backlinks and ranking signals are attached to the old URLs. If Google cannot find a clear, authoritative path from old URL to new URL, those signals are orphaned. The new URLs start from zero authority, and your rankings collapse.

2. Types of Site Migrations and Their SEO Risk

3. The Pre-Migration Checklist

The pre-migration phase is where migrations are won or lost. Most migration disasters stem from rushing the preparation. This checklist is the minimum viable pre-migration protocol.

At least 4 weeks before launch

• Crawl the current site fully with Screaming Frog. Export every live URL.
• Pull organic traffic data from Google Analytics for all live URLs (last 12 months).
• Pull backlink data from Ahrefs for all live URLs. Identify top 50 by referring domains.
• Pull GSC query and impression data for all live URLs.
• Document current rankings for your 20 to 50 most important keywords.
• Set up Google Analytics and Search Console on the new domain. Do not wait until launch day.
• Build the complete redirect map (see Section 4).
• Agree on the post-migration monitoring protocol and assign responsibility.

At least 2 weeks before launch

• Test the new site in staging: crawl it, validate schema, check Core Web Vitals, test internal links.
• Confirm redirect map is complete and loaded into the staging environment.
• Test a sample of 50 to 100 redirects end-to-end: old URL should resolve to the correct new URL in one hop.
• Check that no redirect chains exist (old-to-new should be direct).
• Confirm the new domain’s robots.txt allows crawling of all important sections.
• Confirm the new site’s sitemap is ready and points to new canonical URLs.
• Brief the development team on the launch-day protocol.

4. Building the Redirect Map

The redirect map is the single most important deliverable in a migration. It is a spreadsheet with three columns at minimum: old URL, new URL, and redirect type. Every URL that will change needs a row.

How to build it

1. Start with the Screaming Frog export of all live URLs on the current site.
2. Add a column for the corresponding new URL. For structural changes, this may be a formula. For domain changes, it may be a simple domain swap.
3. Validate that every new URL actually exists and returns 200 on the staging site.
4. Add a column for redirect type (301 for all permanent moves).
5. Cross-reference against the Ahrefs backlink export. Every URL in the top 100 by referring domains must have a correctly mapped row.
6. Add a priority column. High-priority rows are crawled first in QA testing.

The redirect map trap to avoid

The most common trap is mapping old URLs to the homepage when no exact equivalent exists on the new site. This feels like a quick fix but destroys the link equity attached to those URLs. Instead, map to the most topically relevant available page on the new site. If no close equivalent exists, decide: is the content worth recreating, or should the URL return a 410?

5. Launch Day Protocol

Launch day is the highest-risk window. Everything should be pre-agreed; no decision-making in real time.

The launch-day sequence

1. Take a final crawl snapshot of the old site as a baseline.
2. Deploy the new site to production.
3. Activate all 301 redirects from old URLs to new URLs.
4. Verify 20 to 30 sample redirects are working correctly (end-to-end, one hop).
5. Submit the new sitemap to Google Search Console on the new domain property.
6. Submit a GSC Change of Address request (for domain migrations).
7. Use GSC URL Inspection to request indexing of the homepage and 5 to 10 priority pages on the new domain.
8. Set up hourly monitoring alerts on the new domain for 5xx errors.
9. Check that the old domain’s GSC property shows the redirects working (Googlebot activity should appear within hours).

What to keep running for the first 72 hours

• Real-time traffic monitoring in GA4 (compare to the same day/week prior).
• Crawl error monitoring in GSC (check every 2 to 4 hours).
• Direct spot-checks of priority URLs in a browser and via curl.
• Ahrefs rank tracker set to daily updates for your top 50 keywords.

6. Post-Migration Monitoring

The work after launch is just as important as the work before. Migrations surface unexpected issues in the first 2 to 4 weeks that only real Googlebot activity reveals.

Week 1 to 2 monitoring checklist (daily)

• GSC Index Coverage report: are new URLs being indexed? Are any returning unexpected errors?
• GSC Page Experience: are Core Web Vitals holding on the new site?
• GSC Crawl Stats: is Googlebot crawling the new domain at increasing rate?
• GA4 organic traffic: compare day-over-day and versus same period last year.
• Ahrefs Site Audit: run daily crawl of the new site for new errors.
• Redirect validation: spot-check 10 redirects daily for the first week.

Week 3 to 12 monitoring (weekly)

• Keyword rankings for priority set.
• Backlink transfer: are Ahrefs’ referring domains starting to point to the new URLs? (Outreach to top backlink sources may accelerate this.)
• Index count on old domain: should be declining as Google de-indexes old URLs.
• Index count on new domain: should be growing week-over-week.
• Conversion rate on organic traffic to confirm signal quality is maintained.

7. CMS-Specific Migration Notes

WordPress migrations

WordPress-to-WordPress migrations (hosting change, domain change, or multisite consolidation) are the most common we handle. Key risks: permalink structure changes if WordPress settings differ, plugin conflicts creating new errors, and schema that was in the old theme disappearing in the new one. See our WordPress development service for configuration support.

Shopify migrations

Shopify has URL structure conventions that change when migrating from another platform. /products/ and /collections/ paths are fixed. The biggest risk is ecommerce URLs that do not map cleanly. All old URL patterns must redirect to the appropriate Shopify URL format.

Custom to CMS migrations

Moving from a custom-built site to WordPress, Drupal, or another CMS often involves restructuring the entire URL taxonomy. These are high-risk: the redirect map is large, URL patterns change completely, and schema often needs full re-implementation. Budget significant pre-migration time.

JavaScript SPA migrations

Migrating to a React or Vue SPA introduces JavaScript rendering concerns on top of standard migration risks. Googlebot needs to fully render JS to index content. Server-side rendering (SSR) or static generation is strongly recommended for SEO-critical content.

8. Most Common Migration Mistakes and Fixes

• 302 redirects used instead of 301. The most damaging single mistake. Fix: immediately change all migration redirects to 301.
• Incomplete redirect map. Dozens of high-value URLs left without redirects. Fix: audit with Screaming Frog on the old domain, cross-reference with new site, add missing redirects.
• Redirects pointing to the homepage. Destroys URL-level link equity. Fix: rebuild map with topically relevant destination URLs.
• Redirect chains (three or more hops). Old site redirects to intermediate URL, then to new URL. Fix: flatten to direct source-to-destination redirects.
• Internal links still pointing to old domain. Fix: sitewide find-and-replace on all internal link URLs.
• Schema not re-implemented on new site. Fix: re-deploy Organization, Article, FAQPage, and BreadcrumbList schema on the new CMS.
• New site not verified in GSC before launch. Fix: verify immediately and submit Change of Address request for domain migrations.
• Old domain robots.txt disallowing crawl before redirects are confirmed working. Never block the old domain before confirming 301s are in place and working.

9. How to Recover From a Bad Migration

If you are reading this section because a migration already went wrong, here is the triage sequence.

1. Audit current redirect status. Crawl both old and new domains. Map every redirect that is missing, wrong-type, or chains.
2. Fix redirects first. All 302s become 301s. All missing redirects get added. All chains are flattened. This is the single highest-leverage recovery action.
3. Submit correct sitemap on new domain in GSC. Request indexing of priority pages via URL Inspection.
4. Submit GSC Change of Address if it was not done at launch.
5. Outreach to top 10 to 20 backlink sources. Ask them to update links to the new URLs directly. This bypasses the redirect and transfers equity more cleanly.
6. Re-implement missing schema. Organisation, Article, FAQPage on priority pages.
7. Be patient. Even after perfect fixes, Google needs 4 to 12 weeks to fully recrawl, re-evaluate, and restore rankings. Monitor weekly. If rankings are moving in the right direction, the fixes are working.

10. Who Needs Site Migration Support?

Key Takeaways

• A site migration is any change that moves URLs: domain changes, CMS moves, HTTPS upgrades, URL restructures. All carry SEO risk if mishandled.
• The redirect map is the single most important pre-migration deliverable. Build it before anything else.
• Use 301 redirects exclusively for permanent moves. A single 302 used by mistake can delay ranking recovery by 6 to 18 months.
• Well-executed migrations recover 80 to 90 percent of rankings in 4 to 8 weeks. Poor ones can take 6 to 18 months or never fully recover.
• Keep the old domain live with redirects for at least 12 months after migration. Shutting it down terminates equity transfer.
• Never combine a domain migration with a content overhaul or full redesign. Migrate first; redesign after rankings stabilise.

11. Related Reading

For external reference, Google’s site move with URL changes documentation is the authoritative guide. Google’s Search Console Change of Address tool is mandatory for domain migrations. Ahrefs’ site migration guide is the most detailed third-party reference available. Screaming Frog is the crawl tool of choice for both pre-migration inventory and post-launch verification. For Google’s change of address feature specifics, see their Change of Address support documentation.

12. Frequently Asked Questions