How to Migrate from Wix to WordPress Without Losing Your SEO
A step-by-step account of what a safe Wix to WordPress migration actually involves. URL inventory, redirect mapping, metadata transfer and post-launch verification.
Published May 12, 2026
4 min read
PortMySite
Most guides to this migration skip the part that actually decides whether it works. They tell you to export your blog, pick a theme, and copy your text across. Then, six weeks later, organic traffic is down 40% and nobody can explain why.
The explanation is almost always the same: the URLs changed and nothing told Google where they went.
Why rankings live at URLs, not at sites
Google does not rank "your website." It ranks individual pages, each identified by its URL. Every link pointing at that page, every month it has spent accumulating trust, every signal that makes it rank, all of it is attached to that specific address.
When yoursite.com/services-1 stops existing, that accumulated value does not transfer to your shiny new /services page automatically. Google finds a 404, eventually drops the old page from its index, and treats the new page as something it has never seen before. You start from zero on a page that used to rank.
This is the entire problem. Everything below is about avoiding it.
Step 1: Inventory every URL before you touch anything
You cannot preserve what you have not written down. Before any rebuilding starts, produce a complete list of every URL on your current site.
Three sources, used together:
- A crawl of the live site. Screaming Frog's free tier handles up to 500 URLs, which covers most Wix sites.
- Google Search Console. Export the Performance report by page. This tells you which URLs actually receive traffic, the ones that matter most.
- Your XML sitemap, usually at
/sitemap.xml. Wix generates one automatically.
Merge them. The crawl finds everything that exists, Search Console finds everything that earns, and the sitemap catches anything orphaned. Any URL that appears in the Search Console export is one you cannot afford to break.
Step 2: Record the metadata, not just the addresses
For each URL, capture the page title, meta description, H1, and any structured data. These are ranking-relevant and easy to lose when a page is rebuilt by hand from a screenshot.
A page that keeps its URL but loses a carefully written title tag can still slide in the rankings. The title is one of the strongest on-page signals you control.
Step 3: Rebuild on staging, never in place
Build the WordPress site on a staging URL while the Wix site stays live and serving customers. There is no reason to accept downtime and no reason to rush the review.
Wix has no full-site export, so this stage is a rebuild, not an import rather than an import. Pages, layouts and design have to be recreated. Blog posts can be exported and imported, which saves real time if you have a large archive.
Match the old structure where it makes sense. Every structural change you make is another redirect you have to get right, and every redirect is a small opportunity for something to break.
Step 4: Map old URLs to new ones
This is the deliverable that matters. A two-column mapping, old URL to new URL, covering every address from your Step 1 inventory.
Some are identical. Some change because the new structure is cleaner. Wix's /post/my-article becoming /blog/my-article, for example. What matters is that every old URL has a destination.
Three rules that prevent most damage:
- Redirect to the closest equivalent page, not the homepage. Bulk-redirecting everything to
/is treated by Google as a soft 404 and throws away the value you were trying to keep. - Avoid chains. If A redirects to B and B redirects to C, fix A so it points directly at C.
- Use 301, not 302. A 301 is permanent and passes ranking signals. A 302 tells Google the move is temporary and to keep the old URL indexed.
Step 5: Launch, then verify
After the DNS cutover, re-crawl the old URL list and confirm each one returns a 301 landing on a live 200 page. This is where mistakes surface, a mistyped path, a redirect loop, a page nobody remembered.
Then:
- Submit the new XML sitemap in Search Console.
- Use the URL Inspection tool on your five most important pages and request indexing.
- Keep the old sitemap accessible for a few weeks so Google re-crawls the old URLs and discovers the redirects.
Step 6: Watch for six weeks, not six days
Expect fluctuation. Google has to re-crawl every URL, follow every redirect, and reassign the signals. Rankings often wobble for two to four weeks even when the migration was executed perfectly.
Watch the Page Indexing report in Search Console. A rising count of "Not found (404)" errors means something in your map is wrong, and it is fixable, but only if you are looking.
What you should not see is a sustained decline past six weeks. That indicates a structural problem, not a settling period.
The honest caveats
Some things cannot be carried across, and any agency claiming otherwise is guessing:
- Wix comments have no export path.
- Wix Chat history stays with Wix.
- Third-party app data depends entirely on whether that app offers an export.
Find these out before you commit, not on launch day.
The short version
Migrations do not damage SEO. Unmapped URL changes damage SEO. Inventory everything, map every address to a real destination, use permanent redirects, and verify after launch. Do that and the move is uneventful, which is exactly what you want it to be.
Doing this yourself?
Or hand it to people who do it weekly.
Fixed price, 7-day delivery, full 301 redirect map, no downtime. Send the URL and get a real quote back within one business day.