WordPress to Wix migration without losing SEO, the playbook

The fear with any platform migration is the same: lose rankings, lose traffic, lose leads. It is not paranoia. Most botched migrations are not failures of the new platform. They are failures of planning. Below is the playbook I follow on every WordPress to Wix migration.

Why teams move from WordPress to Wix

The clients who reach out for this work usually share three frustrations:

1. WordPress costs more than expected once you add up hosting, security, plugins, and developer hours
2. The site keeps breaking after plugin updates
3. Page speed is poor, and Core Web Vitals are red

Wix solves the first two by being a managed platform. The third is solvable on either platform, but Wix Studio defaults are often greener out of the box.

The wrong reason to move is "WordPress is hard." Migration is a real cost. Move only if the long term TCO works in your favor.

The pre migration audit

Before touching anything, I spend a few hours on diagnostics:

• Crawl the WordPress site with a real crawler (Screaming Frog or Sitebulb)
• Pull every URL, every status code, every title, every meta, every canonical
• Pull GA4 and Search Console data for the last twelve months
• Identify the top fifty pages by traffic and the top twenty by conversion
• Map every redirect already in place inside .htaccess or a redirect plugin
• Note all schema markup currently rendered

This audit is the source of truth for the rest of the work. Every change is judged against what existed before.

URL strategy, the most important decision

If at all possible, keep the URL structure identical. Same slugs, same paths, same hierarchy. When URLs match, you skip an entire class of redirect headaches.

When URLs cannot match (because the WordPress structure was poor and we are improving it), every old URL gets a 301 redirect to its new counterpart. No 302, no meta refresh, no JavaScript redirects. Real server side 301s, set inside the Wix domain settings.

I keep a redirect map in a spreadsheet. Old URL, new URL, status, comment. Nothing ships until that map is complete and tested.

Content migration, the boring but critical part

Content is migrated manually for any page that matters. Yes, manually. Bulk import scripts strip nuance, break image alt text, and miss embedded structured data.

For each page I copy across:

• Title and meta description (kept identical unless they were genuinely bad)
• Headings hierarchy (H1, H2, H3)
• Body text with internal links updated to new URLs
• Image alt text and captions
• Schema markup (rebuilt in Wix using built in or Velo injected JSON-LD)
• Canonical tags

Rich content like FAQ blocks, comparison tables, and Q and A sections get rebuilt natively in Wix Studio so they remain crawlable.

Schema and structured data

WordPress sites often run schema through plugins like Yoast or RankMath. On Wix, schema is handled either through the built in tools or by injecting JSON-LD via Velo. I always rebuild the most valuable types first:

• Organization
• WebSite (with SearchAction)
• Article (for every blog post)
• Product (for every store item if applicable)
• FAQPage (for FAQ sections)
• BreadcrumbList

Skipping schema is how rich results disappear after migration.

Sitemap, robots, and Search Console

On launch day, I:

1. Verify the new sitemap.xml is generated by Wix and includes every page
2. Confirm robots.txt does not block anything important
3. Submit the new sitemap to Google Search Console and Bing Webmaster
4. Use the URL Inspection tool to request indexing on the top fifty pages
5. Confirm canonical tags resolve to the correct URLs

Post launch monitoring

The work is not done at launch. For thirty days I watch:

• Crawl errors in Search Console
• Coverage report for any unexpected exclusions
• Average position for the top one hundred queries
• Click through rate for the top twenty pages
• Core Web Vitals report (CLS, LCP, INP)

Small dips in week one and two are normal. Sustained drops are not. If something is off, I dig in immediately rather than waiting for traffic to slide.

What good looks like

A clean migration, on average, sees:

• Traffic dip of less than ten percent in the first two weeks
• Full recovery within four to six weeks
• Improvement in Core Web Vitals scores from day one
• Improvement in mobile traffic share over the first quarter

A messy migration loses thirty percent or more of organic traffic and never fully recovers. The difference is planning, not platform.

The mistakes I see most often

1. No redirect map. Just "we changed all the URLs and hoped"
2. No schema rebuild. The plugin generated structured data is gone
3. No alt text. Bulk import lost it
4. No Search Console handover. The previous owner still has access
5. No monitoring window. Issues go unnoticed for months

Every one of these is preventable. None of them are technical, all of them are process.

If you are about to migrate

Send me the current site URL and a brief description of the goal. I will run a free fifteen minute audit and tell you what the migration would actually involve, with a written scope and timeline. Most projects ship in two to four weeks.