We use cookies to measure visits and improve RnkRocket. Accept analytics cookies or continue with essential only. Cookie policy

Not getting calls from Google? Find out why. See how it works →
Skip to main content
Guide35 minutes to complete

Site Migration SEO Checklist: Move Without Losing Rankings

A comprehensive pre- and post-migration SEO checklist to ensure you protect your organic rankings when moving domains, platforms, or redesigning your website.

By RnkRocket Team
May 9, 2026
25 min read
Site Migration SEO Checklist: Move Without Losing Rankings

Site migrations are among the highest-risk events in SEO. Done well, they are invisible — your rankings hold, traffic continues, and users notice nothing beyond a fresh design. Done poorly, they can cost you 40–80% of your organic traffic overnight, with recovery taking six months or more.

We have worked through dozens of site migrations — from straightforward HTTP-to-HTTPS moves to full domain changes and platform shifts from bespoke CMSs to WordPress, Shopify, or Webflow. The consistent lesson: the outcome is almost entirely determined by what you do before launch day, not what you do after.

This guide gives you the complete playbook. Use it as a living checklist you work through in sequence, not a document you skim once and file away.


Key Takeaways

  • Crawl your current site and snapshot rankings before you touch anything — this is your recovery baseline
  • Every URL that changes needs a permanent 301 redirect; missing redirects are the primary cause of traffic loss
  • Canonicals, sitemaps, and robots.txt must be reviewed and updated on the new site before it goes live
  • Post-migration monitoring for 90 days is mandatory — traffic drops take time to surface
  • Google recommends using the URL Inspection tool to verify individual pages after migration
  • Moz's site migration guide provides an excellent technical reference for redirect mapping and authority preservation
  • Google's URL change documentation covers the official recommendations for domain and URL structure changes
  • RnkRocket's crawl and rank-tracking tools give you the before/after data to quantify exactly what moved

When Do Site Migrations Happen?

Understanding why you are migrating shapes which checklist items matter most.

Rebranding (New Domain Name)

A full domain change — from `oldcompany.com` to `newcompany.co.uk`, for example — is the highest-risk migration type. Every URL changes by definition, meaning you need a comprehensive redirect map, need to re-verify in Google Search Console, and need to update every inbound link you control.

Platform Change

Moving from WordPress to Webflow, Squarespace to Shopify, or a bespoke CMS to anything else. URL structures often change, page templates change, and metadata handling varies wildly between platforms. The redirect map is critical here.

HTTP to HTTPS

The lowest-risk migration, but still requires careful redirect implementation. Google has treated HTTPS as a ranking signal since 2014 — see Google's own announcement. Most modern hosting platforms handle this automatically, but you must verify that every HTTP URL redirects correctly to its HTTPS equivalent.

Website Redesign (Same Platform, Same Domain)

Designers and developers often assume that keeping the same domain means SEO is unaffected. It is not. If the redesign changes URL structures, removes pages, changes heading hierarchies, or strips out content, rankings will be affected. Redesigns catch many businesses by surprise precisely because the domain stays the same.

URL Structure Changes

Moving from `/services/plumbing/` to `/plumbing-services/`, or restructuring a blog from `/blog/category/post` to `/blog/post`. Even without a domain change, URL restructuring requires a complete redirect map.

Migration Types at a Glance

Migration TypeRisk LevelComplexityTypical Recovery TimeKey Challenge
HTTP to HTTPSLowLow1–2 weeksEnsuring all HTTP URLs redirect correctly
URL Structure ChangeMediumMedium4–6 weeksComplete redirect map required
Website Redesign (Same Domain)MediumMedium–High4–8 weeksContent and heading structure changes
Platform ChangeHighHigh6–10 weeksURL structures, templates, and metadata all change
Full Domain Change (Rebrand)Very HighVery High8–16 weeksEvery URL changes; authority must transfer

Understanding where your migration sits on this scale helps you allocate the right amount of time, testing, and post-launch monitoring.


Case Study: WordPress to Shopify Migration

A UK-based home furnishings retailer with a 400-page WordPress site migrated to Shopify as part of a rebrand. The site had been live for six years and had accumulated approximately 1,200 backlinks from interior design blogs, local press, and supplier directories.

Pre-migration preparation (5 weeks): The team crawled the existing site with Screaming Frog and exported all 400 URLs, title tags, and canonical tags. They took a full rankings snapshot covering 85 tracked keywords, identified 35 high-value pages responsible for 80% of organic traffic, and built a comprehensive redirect map in a shared spreadsheet. They also contacted the owners of their top 20 linking domains to request link updates post-migration.

Launch day: Redirects were tested in batches of 50 before go-live. The new sitemap was submitted to Google Search Console within 30 minutes of launch. The team used the URL Inspection tool to request indexing of the 35 high-value pages immediately.

Results: Organic traffic dipped 18% in week one as Google recrawled the site. By week four, traffic had recovered to 92% of pre-migration levels. By week six, traffic reached 95% and continued climbing as the new site's improved page speed (LCP improved from 4.2s to 1.8s) contributed to ranking gains. Two pages that had dropped from page 1 were recovered by fixing redirect chain issues identified during the 30-day monitoring phase.

Key lesson: The five weeks of preparation — particularly the comprehensive redirect map and the backlink inventory — made recovery predictable rather than chaotic. The team knew exactly which pages to monitor and could diagnose issues within hours rather than weeks.


Phase 1: Pre-Migration Audit (4+ Weeks Before Launch)

This is the phase most teams rush or skip. Do not. Everything you do here determines how quickly you can identify and fix problems after launch.

Step 1: Crawl Your Current Site

Use a crawler (Screaming Frog, Sitebulb, or your RnkRocket site audit) to crawl your entire existing site. Export:

  • All URLs currently returning a 200 status code
  • All title tags and meta descriptions
  • All H1 tags
  • All canonical tags
  • All internal links (both source and destination)
  • All images and their alt text
  • All hreflang tags (if you serve international audiences)

Save this data. It is your ground truth. Every URL on this list needs to be accounted for in your migration plan.

Step 2: Rankings Snapshot

Export your current keyword rankings using your rank tracking tool. For each keyword you care about, record:

  • Current position
  • URL currently ranking
  • Search volume
  • Estimated monthly traffic value

If you use RnkRocket, export this from your rank tracking dashboard. If you use Google Search Console, export the Performance report filtered to the last 28 days.

You need this data to know what you are protecting. If a page ranking at position 2 for a high-value keyword disappears post-migration, you need to spot it within days — not discover it three months later when a client asks why leads have dropped.

Use Google Search Console's Links report (free) or Ahrefs/Semrush to export all external links pointing to your site. Record:

  • Linking domain
  • Linking page URL
  • Target URL on your site (the page being linked to)
  • Anchor text

Prioritise links pointing to your most important pages. These are the links you will need to update manually if the target URL changes, or at minimum ensure redirect correctly.

Step 4: Identify Your Most Valuable Pages

From your crawl data, rankings snapshot, and Google Analytics, identify your top 20–50 most important pages by:

  • Organic traffic contribution
  • Keyword ranking value
  • Conversions generated
  • Backlinks received

These pages get special treatment during the migration. Every one of them needs a verified 1:1 redirect if the URL is changing, and each one needs to be manually checked post-launch.

Step 5: Identify Pages to Consolidate or Remove

A migration is a natural opportunity to rationalise your content. Low-quality pages, thin duplicates, and outdated content can be removed — but do so deliberately. Any page receiving traffic or backlinks should either be kept, improved, or redirected to a relevant replacement.

Pages you should keep even if outdated:

  • Any page with meaningful organic traffic
  • Any page with backlinks from authoritative external sites
  • Any page ranking on page 1 for any keyword

Phase 2: Redirect Planning (3 Weeks Before Launch)

Building the URL Mapping Spreadsheet

Create a spreadsheet with these columns:

Old URLStatusNew URLRedirect TypeNotes
/services/plumbing/301/plumbing-services/PermanentH1 verified
/blog/tips-for-winter301/blog/winter-plumbing-tips/PermanentContent merged
/about-us/team301/about/PermanentPage consolidated
/old-promo-page410GoneNo traffic, no links

For every URL on your crawl list:

  • If the URL is staying the same: no action needed
  • If the URL is changing: map it to the new URL with a 301
  • If the page is being removed with no equivalent: consider a 410 (or 301 to the closest relevant page)
  • If the page is being consolidated: 301 to the page it is merged into

Redirect Chain Rules

Never create redirect chains. A redirect chain is when URL A redirects to URL B, which redirects to URL C. Each hop dilutes link equity by approximately 15% and slows page load time.

Before going live, test your redirect map for chains:

  1. Export your redirect list
  2. For each destination URL, check it is not itself a redirect
  3. Flatten any chains so A redirects directly to C

The Homepage Rule

The homepage is almost always the most linked-to page on any site. If your domain is changing, `http://oldsite.com/\` must 301 to `https://newsite.com/\` with a single-hop redirect.

Preserving Parameterised URLs

If your current site uses URL parameters for filtering (`/products/?colour=red`), check whether your new platform handles these differently. Parameters are often stripped or changed during platform migrations, which can break pages that are linked to externally.


Phase 3: Technical Setup (1–2 Weeks Before Launch)

Canonical Tags

Review how your new platform implements canonical tags. Every page should have a self-referencing canonical unless it is intentionally consolidated with another page. Check:

  • The homepage (`/`) has a canonical pointing to the canonical version of the homepage
  • Category and tag pages (on blogs and e-commerce sites) have correct canonicals
  • Paginated pages (`/blog/page/2/`) are handled correctly
  • The platform does not automatically generate duplicate canonicals

XML Sitemap

Create a new XML sitemap that includes only the URLs that should be indexed on the new site. Exclude:

  • Redirect URLs
  • Noindex pages
  • Paginated pages beyond page 1 (usually)
  • Filtered/parameterised pages you do not want indexed

Submit the new sitemap to Google Search Console on launch day.

Robots.txt Review

Your new site's robots.txt must not block Googlebot from crawling your content. A common mistake during platform migrations is launching with a `Disallow: /` directive left over from the development phase.

Check: ``` User-agent: * Disallow: ```

That is a production-ready robots.txt for a site with no restricted areas. Compare it to your staging robots.txt, which should have:

``` User-agent: * Disallow: / ```

Ensure these are not confused at launch.

Staging Environment Checks

Before flipping the switch, run through the new site on staging:

  • Crawl the staging site and compare URL count to your old site crawl
  • Verify all pages from your top-50 list are present and rendering correctly
  • Test 20–30 redirects from your mapping spreadsheet manually
  • Check title tags and meta descriptions match what you expect
  • Verify structured data (schema markup) is implemented correctly
  • Test site speed with PageSpeed Insights on at least five key pages
  • Test mobile usability on real devices, not just browser emulation

Search Console Property Setup

If your domain is changing, create a new GSC property for the new domain before launch. You will need this to submit sitemaps and monitor crawl errors immediately after go-live.

If your domain is staying the same, ensure your existing GSC property is verified with a method that will survive the platform change (DNS verification is safest).


Launch Day Checklist

Work through these in order on the day the new site goes live:

Within the first hour:

  • Confirm robots.txt is not blocking crawlers
  • Confirm the new sitemap is accessible at `/sitemap.xml`
  • Submit the new sitemap in Google Search Console
  • Test 10–20 critical redirects manually using a browser and a redirect checker tool
  • Confirm the homepage is resolving to the correct URL (no redirect loops)
  • Check the site is accessible over HTTPS with a valid SSL certificate
  • Confirm canonical tags are present on the homepage and key landing pages

Within the first 24 hours:

  • Use GSC's URL Inspection tool to request indexing of your 10 most important pages
  • Monitor server logs or a real-time analytics tool for 404 errors
  • Check that internal links on the new site resolve to correct URLs (no broken links)
  • Verify structured data is rendering correctly using Google's Rich Results Test

Within the first 48 hours:

  • Run a full crawl of the live new site and compare URL count to your pre-migration crawl
  • Check GSC's Coverage report for any new crawl errors
  • Verify key pages are appearing in Google Search for branded queries

Phase 4: Post-Migration Monitoring (30/60/90 Days)

30-Day Monitoring

In the first 30 days, check the following weekly:

  • GSC Performance report: Compare total clicks and impressions to the same period last year. A 10–20% temporary dip is normal during recrawling. More than 30% warrants investigation.
  • GSC Coverage report: Watch for spikes in "Excluded" or "Error" URLs
  • Rank tracking: Monitor your top-50 keywords. Pages that drop more than 5 positions need immediate investigation.
  • 404 errors: Check server logs or a tool like Screaming Frog to identify any unredirected URLs generating 404s

For pages that have lost significant rankings, ask:

  1. Is the old URL properly redirecting?
  2. Is the new URL indexed? (Check with URL Inspection)
  3. Has the content or heading structure changed?
  4. Has the page load speed changed significantly?

60-Day Review

By 60 days, rankings should be stabilising. Run a full crawl of the new site and compare to your pre-migration crawl:

  • Are all your important pages indexed?
  • Are any new crawl errors appearing?
  • Are backlinks from your inventory resolving correctly to the intended pages?

Contact the owners of any high-authority sites linking to an old URL that is generating a 404. Ask them to update the link to the new URL. A 301 passes most link equity, but a direct link is always preferable.

90-Day Sign-Off

At 90 days, compare your current rankings and traffic to pre-migration baselines. Document what has recovered, what is still down, and what has improved. This report is your migration sign-off.

If traffic is still materially down at 90 days, you likely have one of the issues described in the next section.


Common Migration Disasters (and How to Diagnose Them)

The Mass 404 Problem

Symptom: GSC shows hundreds of new 404 errors within the first week. Cause: Redirect map was incomplete or not implemented correctly. Fix: Use your pre-migration URL list to identify which old URLs are generating 404s. Implement missing redirects immediately. Every day a 404 persists costs you link equity.

The Duplicate Content Explosion

Symptom: GSC Coverage report shows large numbers of "Excluded — Duplicate without user-selected canonical" pages. Cause: The new platform generates multiple URL variants of the same page (with and without trailing slash, with session parameters, etc.) Fix: Ensure canonical tags are self-referencing and consistent. Add parameter handling rules in GSC.

The Robots.txt Lockout

Symptom: Rankings collapse within days of launch. GSC Coverage shows pages dropping to "Excluded — Blocked by robots.txt". Cause: Staging robots.txt (`Disallow: /`) was deployed to production. Fix: Correct robots.txt immediately and submit sitemap. Recovery typically takes 2–4 weeks as Google recrawls.

The Slow New Site

Symptom: Rankings hold initially but drift down over 2–3 months. Cause: New platform or new design is significantly slower than the old site. Core Web Vitals have worsened. Fix: Run PageSpeed Insights on your key pages. Identify the bottlenecks (usually render-blocking JavaScript, large images, or lack of CDN). Prioritise fixes on your top-traffic pages first.

The Content Reduction Problem

Symptom: Pages that previously ranked well have dropped. Cause: The redesign removed or simplified content that Google valued. Heading structures changed, content was condensed, or pages were merged without redirects. Fix: Compare the before and after versions of each underperforming page using the Wayback Machine. Identify what content was present before and consider reinstating it.


Recovery If Things Go Wrong

If you have already launched and traffic has dropped, take a methodical approach:

Week 1: Run a full crawl of the new site. Compare URL count to pre-migration. Identify all 404 errors. Implement missing redirects.

Week 2: Check GSC Coverage for all excluded and error URLs. Request indexing of your top-50 pages via URL Inspection. Verify canonical tags on all affected pages.

Week 3: Compare current rankings to your pre-migration snapshot page by page. For each page that has dropped, investigate redirect chain, content changes, and speed changes separately.

Week 4 onward: Implement content fixes for pages where content was reduced. Begin manual outreach to update backlinks pointing to 404 URLs.

Recovery from a poorly executed migration typically takes 3–6 months even after all technical issues are resolved, because Google needs time to re-evaluate the site in its new form.


Using RnkRocket for Migration Monitoring

RnkRocket's rank tracking and site crawl tools are particularly useful for migrations because they give you the baseline data you need before launch, and the ongoing monitoring data you need after.

Before migration: use RnkRocket to take a full rankings snapshot and note exactly which URLs are ranking for which keywords. After migration: set up rank tracking for the same keyword set and watch position changes weekly. The technical SEO audit guide covers how to interpret crawl data if you are new to site audits.

For context on why technical decisions matter to rankings, see our what is SEO overview, which covers how Google's crawling and indexing process works.


Frequently Asked Questions

How long does it take to recover from a site migration?

A well-executed migration with proper redirects typically shows stabilised rankings within 4–8 weeks. A poorly executed migration can take 6+ months to recover from, and some traffic loss may be permanent if backlinks are lost.

Google has stated that 301 redirects pass the same link equity as a direct link. However, redirect chains (A → B → C) dilute equity at each hop. Always implement single-hop redirects.

Should I migrate my site and redesign it at the same time?

Ideally, no. Running a domain migration and a full redesign simultaneously doubles the variables when diagnosing problems. If possible, separate the migrations by at least 3 months so you can isolate causes of any ranking changes.

How do I know if my migration caused a ranking drop or if it was a Google algorithm update?

Check Semrush Sensor or Mozcast for the dates of your ranking drops. If they coincide with an algorithm update and affect your entire site, the update may be the cause. If specific pages drop immediately after migration, the migration is more likely responsible.

What should I do if a page cannot be redirected to a direct equivalent?

Redirect to the closest relevant page. If there is no relevant page, redirect to the parent category or the homepage as a last resort. A redirect to an irrelevant page is worse than no redirect in some cases, so use judgment.

Do I need to notify Google when I migrate my site?

There is no formal notification process for most migrations. For domain name changes specifically, Google Search Console has a "Change of Address" tool that can help Google process the move more quickly. Submit this after you have set up all redirects.



Start Tracking Before You Migrate

A migration without a rankings baseline is flying blind. Set up rank tracking for your key terms now so you have real before/after data to work with. See RnkRocket's pricing to get started.

Related Guides

The Complete Technical SEO Audit Checklist
Technical Guides

The Complete Technical SEO Audit Checklist

A step-by-step technical SEO audit checklist covering crawlability, indexation, Core Web Vitals, structured data, and on-page fundamentals — with actionable fixes for each issue.

Technical SEO
Site Audit
Core Web Vitals
+1 more
Sam Butcher
February 17, 202616 min read
The Schema Markup Handbook for Small Businesses
Technical Guides

The Schema Markup Handbook for Small Businesses

A practical, jargon-free guide to implementing structured data for small businesses — covering JSON-LD, essential schema types, step-by-step implementation, and testing your markup.

Schema Markup
Structured Data
Technical SEO
+1 more
RnkRocket Team
April 18, 202626 min read
Accessibility and SEO Compliance: A Practical Guide
Technical Guides

Accessibility and SEO Compliance: A Practical Guide

Web accessibility and SEO share more common ground than most businesses realise. This practical guide shows how meeting WCAG standards also improves your search rankings.

Accessibility
Technical SEO
On-Page SEO
Sam Butcher
April 4, 202620 min read