I’ve migrated dozens of websites off Wix and WordPress. Some went perfectly. Others were rescue jobs where someone had already tried and broken things.
The difference between those two outcomes is almost always the same thing: preparation. A migration that’s planned over two weeks and executed methodically barely causes a ripple in your search rankings. A migration done over a weekend because you got frustrated with Wix can wipe out years of SEO progress.
This is the checklist I use for every migration. Print it, follow it in order, and your rankings will survive the move.
Phase 1: Pre-Migration Audit (Week 1-2)
Before you touch anything, you need a complete picture of what you’re working with. Think of this like surveying a building before renovation. You need to know what’s load-bearing before you start knocking out walls.
Crawl your existing site
Use Screaming Frog (free for sites under 500 URLs) to crawl your entire website. This gives you a complete list of every page, every image, every internal link.
Export the results as a spreadsheet. This becomes your master reference.
Document your current rankings
Open Google Search Console and export your performance data for the last 3 months. You want to know which search terms bring traffic and which pages rank for them.
If you don’t have Search Console set up, check Google Analytics instead. Your top 20 pages by organic traffic are the ones you absolutely cannot break during migration.
Export everything
Download all your content before you start building:
- Page text (copy it into documents, one per page)
- All images at their original size
- PDFs, downloadable files, anything hosted on your site
- Blog posts with their publish dates
- Form configurations (what fields, where do submissions go)
- Any third-party integrations (booking systems, CRMs, email tools)
List your integrations
Write down every external service connected to your website. Google Analytics. Email marketing. Booking systems. Payment processors. Live chat. Review widgets. You need to reconnect all of these on the new site.
Phase 2: URL Mapping
This is the most important step in the entire migration. Get this wrong and everything else falls apart.
Create a spreadsheet with two columns: Old URL and New URL. Every single page on your current site needs a row in this spreadsheet.
Why URL structure matters
When Google ranks your pages, it associates those rankings with specific URLs. If your page at /services/physiotherapy suddenly becomes /physio-services, Google treats that as a completely different page. Your ranking history for the old URL disappears.
Where possible, keep your URLs identical. Same path, same structure, same slugs. If your old URL is /about-us, make the new one /about-us too.
When you should change URLs
Sometimes your current URL structure is terrible. Wix URLs are a common example. They often look like this:
/post/why-regular-massage-helps-recovery-a1b2c3d4
That random string at the end is a Wix artifact. You absolutely should clean that up during migration. Just make sure the old URL redirects to the new clean one.
WordPress sites with category prefixes are another case. If your blog posts live at /blog/category/uncategorized/post-title, you might want to simplify to /insights/post-title. Again, fine to change, but you must redirect the old URL.
The mapping spreadsheet
Your spreadsheet should look like this:
| Old URL | New URL | Status | Notes |
|---|---|---|---|
| /about | /about | Same | Keep identical |
| /post/blog-title-a1b2c3 | /insights/blog-title | Changed | Clean up Wix slug |
| /services | /services | Same | Keep identical |
| /old-landing-page | (none) | Redirect to /services | Page retired |
Go through every row in your crawl export and map it. Yes, every single one. Miss a page and you create a 404 error that Google will find.
Phase 3: Redirect Setup (301s)
A 301 redirect tells Google: “This page has permanently moved to a new address. Transfer all ranking value to the new URL.”
Every old URL that changes needs a 301 redirect. No exceptions.
Common redirect mistakes
Using 302 instead of 301. A 302 is a temporary redirect. Google keeps the old URL in its index and doesn’t transfer ranking value. Always use 301 for migrations.
Creating redirect chains. Page A redirects to Page B, which redirects to Page C. Each hop loses some ranking value and slows down the user. Every redirect should go directly from old URL to final URL.
Redirect loops. Page A redirects to Page B, Page B redirects to Page A. The browser spins forever. Always test your redirects before going live.
Forgetting trailing slashes. /about and /about/ are technically different URLs. Make sure your redirects handle both.
Platform-specific redirect setup
Leaving Wix: Wix does not let you set up redirects after you leave the platform. Your redirects need to be configured on your new hosting, not on Wix. Most modern hosting platforms and static site generators support redirect configuration files.
Leaving WordPress: Export your redirect rules before you shut down the old site. If you used a redirect plugin (like Redirection), export the rules as a CSV. If your redirects were in .htaccess, save that file. You’ll recreate these on the new platform.
Testing redirects before launch
Set up your new site on a staging URL. Configure all your redirects. Then test every single one. I use a spreadsheet formula that checks each old URL and confirms it lands on the correct new URL.
For sites with hundreds of redirects, automated testing saves hours. But for a typical 20-50 page site, manual testing takes about 30 minutes and catches problems that scripts miss.
Phase 4: Content Transfer
This is where most people make mistakes. They copy-paste from the old site and call it done. That misses the point.
Migration is your best opportunity to improve your content. You’re touching every page anyway. Take the extra time to make each one better.
Page-by-page review
For each page, ask:
- Is this content still accurate?
- Does this page still need to exist?
- Is the content thin or outdated?
- Can I combine two weak pages into one strong page?
Removing a page is fine, as long as you redirect its URL to the most relevant remaining page. Combining pages is even better. Google prefers one thorough page over three thin ones.
Images
Download every image from your old site at its original quality. Do not link to images on your old host. Once you shut down the old site, those image links break.
Re-optimise images during transfer. Convert PNGs to WebP where possible. Compress photographs. Add descriptive alt text to every image. This is a quick win for page speed and accessibility on the new site.
Forms
Rebuild every form on the new platform and test them thoroughly. Check that submissions arrive where they should. If your old forms connected to a CRM or email marketing tool, reconnect those integrations and test them too.
A broken contact form is invisible to you but very visible to potential customers. I’ve seen businesses run for weeks with a broken form, wondering why enquiries dried up.
Blog posts
Transfer all blog posts and keep their original publish dates. Search engines use publish dates as a ranking signal for time-sensitive content. Changing a post’s date from 2024 to 2026 doesn’t make it look fresher to Google. It makes it look like you’re trying to game the system.
Phase 5: Technical Setup on the New Platform
Before you go live, verify every technical detail. These are the things that are easy to miss and painful to fix after launch.
The technical checklist
- SSL certificate active and working (every page loads over HTTPS)
- XML sitemap generated and accessible at
/sitemap.xml - robots.txt allows search engine crawling (check for leftover “Disallow: /” from staging)
- Google Analytics tracking code installed and receiving data
- Google Search Console verified for the domain
- Canonical tags pointing to the correct URLs
- Meta titles and descriptions transferred from old site (or improved)
- Structured data / schema markup implemented for business info
- Mobile responsiveness tested on actual phones, not just browser resize
- Page speed tested with Google PageSpeed Insights (aim for 90+ on mobile)
The staging environment gotcha
If you built your new site on a staging URL, make sure you’ve removed or updated any references to the staging domain. I’ve seen sites go live with canonical tags still pointing to staging.example.com, which tells Google to ignore the real site entirely.
Search your new site’s code for the staging domain. Every instance should be replaced with your production domain.
Phase 6: Launch Day
Launch day should be methodical, not frantic. If you’ve done the preparation right, this is the simplest phase.
Launch day checklist
- Switch DNS to point to new hosting (propagation takes 24-48 hours)
- Verify SSL certificate is active on the live domain
- Test every 301 redirect against your mapping spreadsheet
- Test every form submission
- Test every page on mobile
- Check that Google Analytics is recording visits
- Submit new XML sitemap in Google Search Console
- Click “Request Indexing” on your homepage in Search Console
- Check for immediate crawl errors in Search Console
- Test all third-party integrations (booking, CRM, email)
DNS propagation
When you update your DNS records, the change doesn’t happen instantly. Different internet service providers update at different speeds. For the first 24-48 hours, some visitors will see the old site and others will see the new one.
This is normal. Don’t panic. Keep the old site running during this window so nobody sees a broken page.
Phase 7: Post-Migration Monitoring (Week 1-8)
The migration isn’t done when the new site goes live. The next 8 weeks are critical for catching problems and confirming your rankings have survived.
Week 1-2: Daily monitoring
Check Google Search Console every day. Look for:
- Crawl errors (404s from URLs you missed in redirect mapping)
- Coverage issues (pages not being indexed)
- Manual actions (unlikely but worth checking)
Fix any 404 errors immediately. Every broken URL is a page that’s losing its ranking value.
Week 2-4: Ranking watch
Compare your rankings for the top 20 keywords against your pre-migration baseline. A small dip in weeks 1-2 is completely normal. Google is re-crawling your site and processing the redirects.
If rankings haven’t recovered by week 3, investigate. Common causes:
- Missing redirects (check your mapping spreadsheet again)
- Canonical tag issues (are they pointing to the right URLs?)
- Content changes that weakened a page
- robots.txt accidentally blocking pages
Week 4-8: Stabilisation
By week 4, rankings should be stabilising. If you’re still seeing significant drops, something went wrong in the migration. The most common culprit is missing redirects for pages that had external backlinks.
Use Google Search Console’s Links report to identify your most-linked pages. Verify that every one of them redirects correctly.
Wix-Specific Gotchas
Wix migrations have unique challenges that catch people out.
JavaScript rendering. Wix builds pages with JavaScript, which means the content Google has indexed might not match what you see in the browser. Before migrating, check what Google actually sees by using the URL Inspection tool in Search Console. You might discover that some of your pages were never properly indexed.
Random URL strings. Wix appends random characters to blog post URLs. Every single one needs a redirect to its clean equivalent on the new site. This is tedious but non-negotiable.
No outgoing redirects. When you leave Wix, you cannot set up redirects on the Wix platform. All redirect rules must be configured on your new hosting environment.
Limited export options. Wix lets you export contacts as CSV, but there’s no design or content export tool. You’ll copy content manually, page by page. Factor this into your timeline.
Domain transfer. If your domain is registered through Wix, transferring it to another registrar takes 5-7 days. Start this process early so it doesn’t hold up your launch.
WordPress-Specific Gotchas
WordPress migrations are generally smoother, but there are still traps.
Plugin dependencies. If your site relies on plugins for contact forms, galleries, sliders, or SEO, those features won’t transfer to a non-WordPress platform. You need to rebuild them. Make a list of every active plugin and what it does.
Theme customisations. Some of your content might live inside the theme rather than in the WordPress content database. Custom page templates, header/footer content, and widget areas are all theme-dependent. Export your theme files so you can reference the content during rebuilding.
The uploads folder. All your media lives in wp-content/uploads/, organised by year and month. Download this entire folder. These are your original images, PDFs, and other files.
Database exports. WordPress can export its database as SQL, but this is only useful if you’re moving to another WordPress installation. For migrations to other platforms, you’ll work from the XML content export or copy content manually.
Permalink structure. Check your permalink settings before migrating. WordPress defaults to /?p=123 for URLs, but most sites change this to /post-name/. Whatever structure your live site uses is the one you need to redirect from.
When to Call a Professional
Not every migration needs professional help. A 10-page brochure site with no blog and minimal search traffic? You can probably handle that yourself with this checklist.
But certain situations call for experienced hands:
- 100+ pages. The URL mapping and redirect setup alone becomes a significant project.
- Strong existing rankings. If you’re on page one for valuable search terms, you can’t afford mistakes. A botched migration could cost you months of recovery.
- eCommerce. Product catalogues, payment integrations, and order systems add layers of complexity.
- Complex integrations. CRMs, booking systems, membership areas, and API connections all need careful handling.
If your situation matches any of these, consider a done-for-you migration. The cost of professional help is almost always less than the revenue lost from a failed DIY migration.
For more on what happens when you’re stuck with a website you can’t manage, see my guide on what to do when your developer disappears. And if you’re building fresh rather than migrating, take a look at my web development service for how I approach new builds.
