Wix to WordPress: Migrate Without Losing Rankings
There is no export button in Wix. That single fact shapes everything about moving to WordPress, and it is the thing most migration guides skirt around before selling you a plugin. Your blog posts can come across automatically. Your pages, your layouts, your forms and your shop cannot. They have to be rebuilt. Once you accept that, the job becomes straightforward and predictable, and the part that actually decides whether it goes well is not the rebuilding at all. It is the URL map.
This is the whole process, in the order that keeps your search traffic intact.
Why Wix migrations are different
Most platform migrations begin with an export file. WordPress gives you one. Squarespace gives you one. Ghost, Drupal, Joomla, Blogger. All of them will hand you a structured file containing your content, and the receiving platform reads it.
Wix does not. Wix is a closed system: your content lives in their database, rendered by their editor, and there is no facility to take it out in a portable format. What you can get is an RSS feed of your blog, which contains your posts, and that is genuinely useful. Everything else (the About page, the services pages, the contact form, the gallery, the shop) exists only as rendered HTML on their servers.
So a Wix migration is not really a migration. It is a rebuild, with the blog imported and the URLs preserved. Anybody promising you a one-click transfer is either only moving the blog, or scraping the rendered HTML into a shape you will spend longer fixing than rebuilding.
What can and cannot come across
| What | How |
|---|---|
| Blog posts | Automatically, via the RSS feed. Text, titles and dates come across cleanly. |
| Post images | Usually, if the importer is told to fetch them. Always check, and always verify the count. |
| Pages | By hand. Copy the text, rebuild the layout in your new theme. |
| Your design | Not at all. Wix layouts are not HTML you can lift. Pick a theme, or have one built. |
| Forms and bookings | Rebuilt with a WordPress plugin. Past submissions export separately from Wix, if at all. |
| Shop products | Wix can export products to CSV, which WooCommerce can read. Orders and customers cannot come. |
| SEO settings | By hand. Titles and descriptions are worth copying rather than rewriting; see below. |
| Your domain | Transfers, or points. Two different things, and the choice matters. |
Read that table as a scope estimate rather than a warning. A ten-page brochure site with sixty blog posts is a weekend. A hundred-page site with a shop is a project.
Before you touch anything: take an inventory
This is the step that separates a migration that keeps its rankings from one that quietly loses a third of them, and it takes about an hour.
You need a list of every URL on your current site. Not the pages you remember. Every URL Google knows about. There are three places to get them, and you want all three because each one knows things the others do not.
- Your sitemap. Wix generates one at
/sitemap.xml. Open it and work through the sub-sitemaps it links to. This gives you what Wix thinks your site is. - Google Search Console. Pages → Indexed. This gives you what Google thinks your site is, which is the list that actually matters. Export it.
- A crawler. Screaming Frog's free tier crawls 500 URLs, which covers most small sites. This finds pages linked from somewhere but missing from the sitemap.
Put the union of those three in a spreadsheet. Add a column for the new URL. That spreadsheet is your migration plan, your redirect map and your launch checklist, and everything downstream depends on it being complete.
While you are in Search Console
Sort your pages by clicks over the last twelve months and mark the top twenty. These are the pages where a broken redirect costs real money, and they are the ones to test first on launch day. Most sites find that a handful of pages carry most of the traffic; knowing which ones changes how you spend your attention.
Export your current titles and meta descriptions too. They were written for pages that rank, and rewriting them during a migration adds a variable you do not need. Move first, optimise later.
Understanding Wix URLs
Wix has its own URL conventions, and knowing them tells you what your redirect map has to handle.
| Wix | Typical WordPress equivalent |
|---|---|
| Blog posts | /post/my-article becomes /my-article/ or /blog/my-article/ |
| Pages | /about becomes /about/. Note the trailing slash |
| Shop items | /product-page/item-name becomes /product/item-name/ |
| Old Wix sites | May carry a #! fragment, which cannot be redirected server-side at all |
Two of those deserve attention.
The /post/ prefix means every blog URL is changing. There is no way to keep it, and it is the single largest group of redirects you will write. If you have two hundred posts, that is two hundred redirects, which is why the map has to be a spreadsheet rather than a memory exercise.
Hash-bang URLs come from Wix sites built before roughly 2017, and they look like example.com/#!about/c1nfg. A server never sees the part after the #, so a normal redirect cannot act on it. If your Search Console export is full of these, you will need a small piece of JavaScript on the new site to read the fragment and forward the visitor. It is worth doing: those URLs may still be linked from other sites.
Step one: build the new site somewhere else
Do not point your domain at anything until the new site is finished. Build it on a staging domain or a subdomain, get it right, and switch at the end. A migration that goes live half-finished is how a site ends up with two months of thin, half-populated pages in the index.
You need three decisions before you start building.
Hosting. WordPress is not a service you sign up to; it is software that has to run somewhere. That is the biggest practical difference from Wix and the one that surprises people. Our guide to choosing a host goes through it, and the short version is that the cheapest shared plans are cheap for reasons you will feel later.
A theme. You cannot bring your Wix design, so this is a fresh choice rather than a matching exercise. Trying to replicate a Wix layout pixel for pixel in WordPress is a common and expensive mistake. You end up with a page builder fighting a theme, and a site that is slow for the rest of its life. Pick a well-built theme that is close enough, or have something built properly.
Permalinks. Set these before you import anything. Settings → Permalinks → Post name is right for almost everyone. Changing this after you have imported and redirected means writing every redirect twice.
Step two: bring the blog across
This is the part that is actually automatic.
Wix publishes your blog as an RSS feed, normally at /blog-feed.xml. Open that URL on your Wix site and confirm you get XML rather than a 404. The exact path has varied across Wix versions, and their support site is the place to check if it is not there. Save the file.
Then, in WordPress, install the RSS Importer and run it from Tools → Import. WordPress's own documentation on importing content covers the general mechanics.
Three things to check the moment it finishes, because all three fail quietly:
- The post count. RSS feeds are often capped. Some Wix feeds return only the most recent twenty or fifty posts. If your import brought in fifty posts and you had two hundred, the feed truncated and the rest need doing another way.
- The images. RSS carries image URLs, not images. Unless they were fetched into your media library, every picture on every post is still being served from Wix, and will break the day you close the account. Check the media library count, not the look of one post.
- The publication dates. If they all came in as today, your archive ordering is gone and you will need to fix them before anyone notices.
If the feed is truncated and you have more posts than it returns, the options are to copy the remainder by hand, or to have the content extracted from the rendered pages. Below about thirty posts, by hand is usually faster than getting a scrape clean.
Step three: rebuild the pages
There is no shortcut here, so the useful advice is about order rather than technique.
Work down your inventory spreadsheet by traffic, highest first. The pages that earn get rebuilt while you are fresh and careful; the ones nobody visits get done last, when you are tired, and it matters less.
For each page, copy the text rather than the layout. Open the Wix page, take the words, and put them into your new theme's own structure. Resist rebuilding the visual arrangement. You are choosing a new design, and half-copying an old one produces something that looks like neither.
Keep the heading structure. If a page has an H1 and four H2s on Wix, give it an H1 and four H2s on WordPress, with the same words. That structure is part of why it ranks, and it costs nothing to preserve.
Images
Download the originals from Wix rather than saving what is displayed. Wix serves resized, re-compressed versions through its media service, and saving those bakes in a generation of quality loss. Wix's media manager holds the file you uploaded; take that.
Then, before uploading to WordPress, rename them. Wix filenames are typically a hash, a1b2c3_9f8e7d.jpg, which tells a search engine nothing. oak-dining-table-detail.jpg does. A migration is the one moment when renaming every image costs nothing extra, because you are handling them all anyway.
Forms, bookings and Wix apps
Everything from the Wix App Market has to be replaced rather than moved, and this is where a migration quietly grows. Make a list before you start, because each one is a decision.
Contact forms are the easy case: rebuild in a WordPress form plugin, which takes minutes. The part people forget is the submissions. Past enquiries sitting in your Wix inbox do not come with you. Export them, or at minimum work out whether you need them, before the account closes.
Bookings and appointments are the hard case. If customers hold future appointments in Wix Bookings, those records have to be recreated by hand or carried in a spreadsheet, and there is a window during which two systems could both take a booking for the same slot. Freeze new bookings on Wix for the changeover, or run the old system until the last existing appointment has passed.
Email marketing lists export as CSV from Wix and import into whatever you move to. Do this early: a list is the one asset that is genuinely painful to lose, and it is the easiest to forget because it is not part of the website.
If you have a shop
Wix eCommerce exports products to CSV, and WooCommerce imports CSV, so the catalogue itself moves reasonably well. Expect to fix the column mapping by hand (the two systems disagree about how variants, options and stock are named) and expect images to need re-uploading, since the export references Wix-hosted URLs.
What does not move is everything around the catalogue: orders, customer accounts, saved payment methods and reviews. Order history matters for accounting rather than for the shop, so the usual approach is to export it to CSV and keep it as a record rather than trying to import it. Customers will need to create new accounts, which is worth an email telling them why before they discover it at checkout.
Product URLs change shape too, Wix uses /product-page/name where WooCommerce uses /product/name/, so the shop needs its own block in the redirect map. One RedirectMatch handles it if the slugs survive.
Step four: the URL map
This is the step the whole migration turns on, and it is the one most often rushed.
Every URL in your inventory needs a decision, and there are only three:
| Decision | When |
|---|---|
| Keep the URL | The page exists on both sites at the same path. Nothing to do. |
| Redirect it | The page exists but the path changes. A 301 to the new URL. |
| Redirect to a parent | The page is gone. Send it to the closest relevant page, not the home page. |
That third row is where judgement comes in. Google's guidance on redirects is clear that a redirect to an irrelevant page is treated as a soft 404. The signals do not carry. Sending forty retired product pages to your home page does not consolidate their value; it throws it away and makes your home page look odd. Send each to the category it belonged to, and if there is genuinely no equivalent, let it 404 honestly.
Never leave a URL out of the map. A URL you forget becomes a 404 on launch day, and if it was earning traffic you will not find out for weeks.
Step five: write the redirects
On WordPress, redirects can live in a plugin or in the server configuration. For a migration of any size, the server is better: it is faster, it works before WordPress loads, and it survives a plugin being deactivated by someone who does not know what it does.
On Apache, these go in .htaccess above the WordPress block:
Redirect 301 /post/spring-planting-guide /blog/spring-planting-guide/
Redirect 301 /product-page/oak-table /product/oak-table/For a whole prefix, one rule handles the lot:
RedirectMatch 301 ^/post/(.*)$ /blog/$1/That single line moves every Wix blog URL to its WordPress equivalent, provided your slugs stayed the same, which is a very good reason to keep them.
On nginx the equivalent is a rewrite in the server block, which usually means asking your host. If you would rather not touch server config at all, a redirect plugin is a legitimate second choice; it just adds a database lookup to every 404.
The hash-bang problem
If you have old #! URLs, no server rule can help, because the fragment never reaches the server. The fix is a small script in your new site's head that reads the fragment and forwards:
if (location.hash.indexOf('#!') === 0) {
location.replace('/' + location.hash.slice(2).split('/')[0] + '/');
}It is a blunt instrument and it only helps visitors rather than passing much link value, but it beats showing a home page to somebody who followed a link to your services page.
Step six: the domain
Two options, and people conflate them constantly.
Transferring moves the registration itself to a new registrar. You control it, you renew it, and Wix has nothing more to do with it. This is what you want in almost every case.
Pointing leaves the domain registered with Wix and changes where it resolves. It works, and it means your domain renews with a company whose product you have just left, which becomes somebody's problem in about eleven months.
Two practical notes. A domain cannot be transferred within sixty days of registration or a previous transfer, so if you registered it recently, check before you plan around it. And if the domain came free with a Wix plan, confirm you actually own it rather than holding it as part of the subscription. That catches people out and is much easier to sort before you cancel than after.
Unlock the domain, get the authorisation code, start the transfer at the new registrar, and expect it to take up to a week. Do this after the new site is built and before you cancel Wix.
Step seven: launch
The order matters, and this order is deliberate.
- Final content check on staging. Every page from the inventory exists and reads correctly.
- Confirm the redirect file is in place and the rules are syntactically valid.
- Check the staging site is not indexable, and that the live one will be. Settings → Reading → "Discourage search engines" must be off when you go live. Shipping with it on is the single most common WordPress launch error, and it removes you from Google entirely.
- Point the DNS at the new host.
- Wait for propagation. Usually minutes, occasionally hours.
- Test the top twenty URLs from your inventory. The ones you marked by traffic. Not by clicking around: paste each old URL and confirm it lands on the right new page with a 301.
- Submit the new sitemap in Search Console.
- Keep Wix running for a month. It costs one more month and it is your rollback.
Point three is worth repeating because it is so easily missed. A staging site should be noindexed; a live site must not be. The switch is one checkbox and it is not automatic.
Search Console
Because your domain is not changing, you do not need the Change of Address tool. That is for moving to a different domain, and Google's documentation on site moves with URL changes covers the distinction. What you should do is submit the new sitemap, and then leave the old one in place for a few weeks so Google recrawls the old URLs and discovers the redirects.
What to expect afterwards
Rankings wobble after a migration. That is normal, and knowing it is normal stops you making things worse.
Expect two to six weeks of movement while Google recrawls and follows the redirects. Positions dip, recover, and often end up slightly better, because you have moved from a closed platform to one where the technical fundamentals are yours to control. What is not normal is traffic dropping and staying down after six weeks. That means redirects are missing or wrong, and the fix is to go back to the inventory.
Watch three things weekly for the first two months:
- Search Console → Pages, for a rise in "Not found (404)". Every one of those is a URL missing from your map.
- Total clicks against the same period last year, not against last week.
- Core Web Vitals, which are new to you: on Wix, performance was Wix's problem. On WordPress it is yours. Google's overview of Web Vitals explains what is measured, and our piece on why WordPress sites get slow covers the usual causes.
What usually goes wrong
In rough order of how often we see it:
Images still served from Wix. The site looks perfect for weeks, then the Wix account lapses and every picture on the blog disappears at once. Check the media library, not the pages.
The blog import truncated. Fifty posts arrived, two hundred existed, and nobody counted.
Redirects written for the wrong permalink structure. Somebody changed the permalink setting after writing the map.
"Discourage search engines" left ticked. Traffic goes to almost nothing within a fortnight and the cause is one checkbox.
Wix cancelled too early. The rollback is gone, and so is any content nobody noticed was missing.
Everything redirected to the home page. Fast to write, and it discards the value of every page you did it to.
How long it takes
| Site | Build | Elapsed |
|---|---|---|
| 5–10 pages, no blog | 1–2 days | 1 week |
| 10–20 pages, small blog | 3–5 days | 2 weeks |
| 20+ pages, large blog | 1–2 weeks | 3–4 weeks |
| Shop | 2–4 weeks | 6 weeks |
Elapsed time is longer than build time because of the domain transfer and because launching on a Friday is a bad idea. Build time assumes the content already exists and is being moved rather than rewritten.
If you would rather not do this yourself, it is what our website migration service exists for. Inventory, rebuild, redirect map and launch, with the old site kept live until the new one is proven. Afterwards, a care plan covers the updates and backups that are now your responsibility rather than Wix's, and our guide to backups explains what changes on that front.
Can you export a Wix site to WordPress automatically?
Only the blog. Wix has no export function for a whole site. Your content lives in their database and there is no portable file to take out. Blog posts can be imported into WordPress through the RSS feed, but pages, layouts, forms and shop settings have to be rebuilt. Any tool promising a complete one-click transfer is either moving the blog only, or scraping rendered HTML into a mess you will spend longer fixing than rebuilding.
Will I lose my Google rankings moving from Wix to WordPress?
Not if the redirects are right. Expect two to six weeks of movement while Google recrawls, then a return to roughly where you were, often slightly better. Rankings that drop and stay down past six weeks mean URLs are missing from the redirect map. The protection is a complete inventory taken before you start, from your sitemap, Search Console and a crawler together, not from memory.
What happens to my Wix domain?
You can transfer it to another registrar or leave it with Wix and point it at the new host. Transferring is almost always better. You control renewal rather than depending on a company whose product you have left. A domain cannot be transferred within sixty days of registration or a previous transfer, and if it came free with a Wix plan, check you genuinely own it before cancelling. Sort the domain after the new site is built and before you cancel anything.
Do my Wix blog images come across?
The RSS import carries image URLs, not the images themselves, so unless the importer fetched them your posts are still loading pictures from Wix. They will all break the day the account closes. Check the media library count rather than looking at one post. Download originals from the Wix media manager rather than saving what the page displays, since displayed images are resized and recompressed, and rename them on the way in. Wix filenames are hashes that tell a search engine nothing.
How long does a Wix to WordPress migration take?
A five to ten page brochure site is one to two days of building and about a week elapsed. Twenty pages with a blog is three to five days and a fortnight. A shop is a month or more. Elapsed time exceeds build time because a domain transfer can take a week and because you should not launch on a Friday. Those figures assume the content already exists and is being moved rather than rewritten.
Should I keep my old Wix URLs?
Keep the slugs wherever you can, because it makes the redirect map far simpler. The /post/ prefix Wix puts on blog URLs cannot be kept, but if the rest of the slug is unchanged, one RedirectMatch rule moves every post at once instead of one rule per article. Changing slugs during a migration adds risk for no benefit; if some need improving, do it a few months later as a separate, deliberate job.
When can I cancel my Wix account?
A month after launch, not before. While it is running it is your rollback, and it is also where any content you have not noticed is missing still lives. One extra month is inexpensive insurance. Before you cancel, confirm the domain is settled and that no images on the new site are still being served from Wix. That second one is the most common way a migration falls apart weeks after everyone declared it finished.