Will moving from Wix to WordPress hurt my SEO?
It can dip for a while, and it drops hard only when URLs break. Google ranks addresses, not words. When you migrate Wix to WordPress, blog posts and store products change shape, and each old address that earned clicks points at nothing unless someone maps it to the page that replaced it. The words can be identical and the page still drops out.
I'll be plain about the split. I don't build or design the WordPress site; that's a developer's job. What I do is the search side: the URL list, the redirect map, the launch checks and the weeks of Search Console watching after.
Google's guidance for a move with URL changes is short: list the old URLs, decide where each one redirects, use server-side permanent redirects, and keep them generally at least a year. It also says to expect temporary fluctuation in rankings while the move settles.
Skipping the map isn't a small mistake. On one WooCommerce store, a redesign that changed URLs without redirects took daily clicks from 162 to 49 in three days. That wasn't a Wix move, but it's the same mechanism a platform move triggers on every changed URL at once.
Is WordPress better than Wix for SEO?
Not on its own. Both let you set page titles, descriptions and URL slugs, and Wix's help center documents custom URL prefixes in its SEO settings. What WordPress gives you is control: server-side redirects, any permalink structure you like, the theme files and the markup they print. That control is worth moving for only if someone's going to use it.
So I ask what the move is for before it starts. If the Wix site ranks and the reason to leave is a feature the business needs, the move's fine, and the SEO work done on Wix isn't thrown away. Google says keeping redirects for at least a year allows it to transfer all signals to the new URLs, including links on other sites. If the only reason is better rankings, I'd rather fix what's holding the Wix pages back first.
Which Wix URLs won't WordPress recreate on its own?
Wix builds a few URL types with a fixed prefix. Its help center lists blog posts at /post/ followed by the post's slug, and Wix Stores products at /product-page/ followed by the product's slug. Both prefixes can be renamed in Wix's SEO settings, so I read the real ones off the live site rather than assuming the defaults.
| Wix URL | WordPress by default | What I do |
|---|---|---|
| /post/{slug} | /{slug}/ with the Post name permalink setting | Keep /post/ with a custom permalink structure, or 301 each post |
| /product-page/{slug} | /product/{slug}/ in WooCommerce | Set a custom product base that matches, or 301 each product |
| Blog category and tag pages | /category/{slug}/ and /tag/{slug}/ | Take their real URLs from the Wix sitemap and map them one by one |
| Plain pages like /about | /about/ with a trailing slash | Check the old form answers with one 301, not a chain |
Depending on the server, a fresh WordPress install comes up on Day and name, which puts the date in every post's address, or falls back to Plain permalinks, the ?p=123 kind, when rewrites don't work. That's what WordPress's own install function does. Either way, the permalink setting is the first thing I check on the new build, before a single redirect gets written.
Keeping the old pattern is the cheapest redirect there is, because there isn't one. WordPress accepts a custom structure built from its structure tags, so /post/%postname%/ gives every post the address it had on Wix. WooCommerce has a custom product base for the same reason. Category and tag archives are different: WordPress lets you rename the category and tag bases but won't let you remove them, so those URLs usually need a 301 each.
Rather have me do this? One person, whole job.
Book a call on UpworkHow do Squarespace and Shopify URLs differ from Wix's?
Squarespace hangs each blog post under its blog page's slug, and the post format can include the date. On version 7.1 sites, product URLs always carry /p/ before the product slug. Shopify fixes its store paths: products under /products and collections under /collections, and its help center says those paths can't be redirected inside Shopify.
Move either catalogue into WooCommerce and products land on /product/ and categories on /product-category/ unless the bases change, so the store map is usually the biggest part of the job, and where WooCommerce SEO work picks up once the store is live. The rule doesn't change: read the old site's real URLs, decide the WordPress pattern before anything's imported, and redirect whatever doesn't survive.
How I build the redirect map, step by step
This is the order I work in. Each step feeds the next one, and the map isn't finished until the last step passes.
- Step 01
Pull every URL Google has shown
In Search Console I export the Performance report by page. Exports stop at 1,000 rows, so on a bigger site I split the export by date range or use the API. These URLs earn clicks, so they come first.
- Step 02
Add the old sitemap and a crawl
Wix keeps a sitemap index at /sitemap.xml with a child sitemap for each page type, so posts, products and pages each arrive as their own list. A crawl of the live Wix site catches what the sitemap misses, like pages only a menu links to.
- Step 03
Add the URLs other sites link to
A backlink export shows old addresses with outside links, including a few that already 404. Those links still send people, so they get a destination too.
- Step 04
Group the list by pattern
Posts, products, categories, tags and plain pages each get one rule. A rule per pattern covers most of the list, and only the leftovers need a decision each.
- Step 05
Give every URL one destination
The same page gets its new address. A merged page goes to the page that absorbed it. A page gone for good, with nothing close, returns a 404 or a 410, never a redirect to the homepage, which only moves the dead end somewhere harder to spot.
- Step 06
Write them as server-side 301s
Google recommends server-side permanent redirects for a move. On WordPress that's the server config or a redirect plugin, and I check that both send a real 301 status, not a JavaScript hop or a meta refresh.
- Step 07
Test the map on staging
I run the whole list against staging and flag anything that doesn't land in one hop on a page returning 200: chains, loops, 404s and redirects to the homepage.
Don't import first and map later. WordPress.com's Wix guide says blog posts can't be exported from Wix, and its RSS route imports only the 20 most recent. Older posts get rebuilt by hand, with new slugs unless someone types the old ones in, so I settle the URL pattern and the slug list before any import or rebuild starts.
What do I check on launch day, before and after the DNS change?
Launch day has two halves. The first three checks run on staging before the domain moves. The rest run on the live domain within the first hour.
- i.
Search engines aren't discouraged
WordPress has a setting called Discourage search engines from indexing this site, and it's often ticked on staging. If it goes live ticked, every page asks Google to leave it out.
- ii.
Robots.txt and canonicals name the real site
A staging Disallow or a canonical naming the staging address is what a visual check never catches, so I read both in the page source.
- iii.
Titles and descriptions came across
Wix keeps titles and descriptions in its own SEO settings, and an import doesn't always bring them. I check the new pages carry them, or better ones, before the domain moves.
- iv.
Every old URL answers with one 301
After the DNS change I run the full list again against the live domain. Anything that 404s, chains or lands on the homepage gets fixed that day.
- v.
Internal links and the sitemap use the new URLs
Google's guidance is to change internal links to the new URLs and submit the new sitemap in Search Console, rather than leaning on the redirects for every click.
- vi.
Search Console still verifies
If the property was verified with a meta tag in the Wix head, that tag doesn't come across, and Google says removing the token loses verification. A Domain property verified by DNS covers every subdomain and protocol, so I set one up before the switch if the site doesn't have it.
The Change of Address tool is only for a move to a new domain or subdomain. A Wix site that moves to WordPress on the same domain doesn't use it at all.
What should Wix to WordPress SEO look like in the first 28 days?
Google says that for a medium-sized site it can take a few weeks or more before the new URLs replace the old ones in results, and that some ranking fluctuation is expected. So I don't read much into the first few days, and I won't promise a date when things settle. I watch for the signals that mean something's actually wrong.
In the Pages report, old URLs showing as Page with redirect is the healthy sign: Google's found the 301s. Old URLs showing as Not found (404) aren't, because each one is a redirect that's missing from the map, and I add it the day it shows up. If new URLs sit unindexed for weeks, that status has its own diagnosis.
In the Performance report I compare clicks by page with the 28 days before launch. The pattern I'm looking for is clicks leaving each old URL and arriving on its new one. A page whose old address loses clicks while its new address gains none is the one I open first, and it's usually a redirect to the wrong place or a page that lost its title.
If you're moving a Wix site and you'd rather one person owned the whole search side, the URL list, the map, launch day and the weeks after, that's the migration work I do. The build stays with your developer.
Book a call on Upwork
