Migrate Wix to WordPress in 2026: What Really Moves

There is no Wix-to-WordPress importer. Not a hidden switch in the Wix dashboard, not a paid add-on, not a source in WordPress’s own import screen. What you are doing is a rebuild with the content carried across, followed by a redirect map that points every old Wix URL at its new WordPress address. That decides your schedule: a 40-page site is 40 pages of work. This guide is the order to do that work, what actually moves on its own, and the redirect discipline that keeps your rankings intact on the way over.

Key takeaways

• No tool converts a Wix site into WordPress. Wix produces no WordPress import (WXR) file, and WordPress’s importer has no Wix source.
• Text, images and post dates come across. Wix apps — Bookings, Events, Members — do not, and neither do form entries.
• Redirects are the load-bearing step, and they only work if the destination page exists first. Content before redirects, always.
• Bulk content goes in through the WordPress REST API from a CSV, not by pasting into the editor one page at a time.
• One 301 per old URL, no chains, no catch-all to the homepage, kept for at least a year.

What transfers from Wix, and what you rebuild

Wix has no “export everything” button. Some of your site is data that can be lifted and re-posted; the rest is layout, and layout on Wix is generated by Wix’s editor, so it cannot survive the trip. Knowing which bucket each element falls into is what turns a vague project into a list you can price and schedule.

The “no” rows are what break schedules: people budget for content and forget the booking form, members area and event calendar were doing real work.

Count the work in units before you agree to a date

Effort estimates in this genre are usually fiction. The honest way to size a Wix migration is to count the units on your own site and then measure how long the first three of each type actually take you. Extrapolate from your own timing, not from someone else’s blog post.

Multiply your own per-unit time by the count in each row, then add the app-dependent row last, because it is the one that refuses to behave. If the total is uncomfortable, that is information — not a reason to look for a one-click tool that does not exist.

Step 1 — Build the URL inventory before anything else

Fetch your Wix sitemap, usually at /sitemap.xml, and save the file. That gives you every URL Wix admits to. Then crawl the live site and add the pages the sitemap leaves out: thank-you pages, landing pages, tag archives, anything with traffic that is not in the list.

Build one spreadsheet with a row per URL and these columns: old URL, page title, type (page, post, product, archive), approximate word count, and whether it has inbound links or traffic. That last column decides your priorities. A page with links and traffic gets rebuilt carefully; a page with neither can be dropped, deliberately, now rather than after launch.

Check each URL character for character, including trailing slashes and capitalisation, because the two platforms disagree about both. If a URL looks mangled, work out how to find the original slug rather than guessing from the menu label.

Step 2 — Stand up WordPress on a staging address

Pick a host with SSH or a file manager, PHP 8.x, MySQL 8 or MariaDB 10.6+, free SSL and a staging site. You want the new site reachable at staging.example.com before the domain moves, so you can build and redirect-check without exposing a half-finished site. If hosting is the part you are least sure about, getting a domain and hosting for WordPress covers the account side.

Install WordPress and confirm the version. Core was 7.1.4 when this was checked on 2 November 2026, and the download page always lists the current release. Put staging behind HTTP auth or a maintenance plugin and set it to discourage search engines — two indexed copies of the same content is a mess to unwind.

Keep Wix paid for the whole build. The most common way this project goes wrong is cancelling Wix early, losing the live site, then rebuilding from the Wayback Machine.

Step 3 — Choose the theme and set permalinks before you import a single post

Permalinks are the shape of every URL on the new site, and changing them after you have imported 200 posts means rewriting 200 redirects. Set them once, at the start, at Settings ? Permalinks.

Two strategies, and they trade off:

• Match Wix where you can. Wix pages usually sit at the root, like /about. WordPress pages also sit at the root by default, so page URLs often survive with no redirect at all if you keep the same slugs.
• Pick a clean structure and redirect the rest. /%postname%/ is the practical default for posts. If Wix served posts at /post/slug, every post needs one redirect row — a known, countable cost.

One shortcut: if your Wix blog used /post/, setting the permalink structure to /post/%postname%/ makes that whole class of URL match and removes those redirects entirely — but you are locked into the prefix for as long as the site lives. Most sites prefer /%postname%/ and pay the redirect cost once.

Install the theme before content, not after. Building 30 pages in a default theme and switching later means re-checking every layout, image width and table on mobile. Pick the theme, build two representative pages, look at them at 390px, then start the bulk work.

Step 4 — Move content in bulk through the REST API, not the editor

Pasting 40 pages into the block editor is not a plan, it is a day you will not get back. WordPress’s REST API accepts authenticated POSTs at /wp-json/wp/v2/posts and /wp-json/wp/v2/pages, which means you can create hundreds of entries from a CSV with a short script. The posts endpoint reference lists every field; only a handful matter here.

Authentication is an Application Password, created per user under Users ? Profile, over HTTPS. Then one POST per row:

curl -s -X POST "https://staging.example.com/wp-json/wp/v2/posts" \
  -u "editor:abcd EFGH 1234 ijkl MNOP 5678" \
  -H "Content-Type: application/json" \
  -d '{"title":"Old post title","slug":"old-post-title",
       "content":"<p>Body HTML here.</p>",
       "date":"2020-04-18T09:00:00","status":"draft"}'

Three rules: log the HTTP status and returned post ID for every row, so a failure is a line in a file rather than a page you notice missing in three weeks; sleep briefly between requests instead of firing 200 at once; and run everything against staging first, then re-point the script at the live domain.

Wix blog content is the easiest part to bulk-build: a live Wix blog is a public web page, so you can read the rendered HTML and extract the body and publish date. If the blog publishes an RSS feed, the feed gives you titles, dates and bodies in a structured file, which is cleaner than scraping. Drafts and password-protected posts appear in neither.

If you would rather not script it, the plugin route is covered in WordPress migration plugins — but understand what those plugins do: they move a WordPress site between hosts, or generate a WXR file. None of them can read Wix. The Webflow to WordPress migration is the same shape of problem.

Step 5 — Move media, then fix filenames and alt text

Download every image you intend to keep, at the largest size Wix serves, before you cancel anything. That folder becomes your only copy of the originals. Upload in batches through Media ? Add New, or POST to /wp-json/wp/v2/media if you are already scripting.

WordPress files uploads under wp-content/uploads/YYYY/MM/ by upload month. That path is why a later media export needs a plugin that reads the database, not a copied folder.

Two fields get confused, and the confusion is why migrated sites have terrible image SEO:

• The filename — the actual file, e.g. wix-5f3c1a2b.jpg. Rename it before upload to something descriptive and lowercase, with hyphens.
• The alt text — a separate database field, entered per image in the media library or the block settings. It is not read from the file, and it is not stored inside the image.

That is the mechanism behind the usual complaint that a migration “lost” alt text. Wix stores alt text only if someone typed it in, and it appears on the page as an alt attribute. A bulk import that moves files but not those attributes arrives with empty alts and no error. If the old pages have them, scrape them alongside the image URLs; if they are empty, you are writing them from scratch, one image at a time — count that like everything else.

Step 6 — Rebuild the parts Wix apps were running

No clever shortcut here, and any guide implying otherwise is selling something. Wix apps are hosted features inside Wix; their data does not come out in a portable format.

• Forms. Rebuild each form in a WordPress form plugin, re-create notifications and confirmations, send a real test submission. Then export the old entries to CSV and archive them outside both platforms — they are customer data and they disappear with the account.
• Bookings. You need a booking plugin with the same shape: services, staff, availability rules, buffers, payment. Re-enter the catalogue by hand; no export maps onto a WordPress booking schema.
• Events. An events plugin plus a decision about the archive. Old events hold links, so keep them as pages; recreating 60 past events is usually a wasted week.
• Members. A membership plugin, plus a plan for existing members: they cannot keep their Wix passwords. Expect a password reset round and a short grace period where both old and new access paths work.

Budget this section by counting the app-dependent pages, not the pages overall. A 30-page brochure site with one contact form is a smaller job than an 8-page site with bookings and a members area.

Step 7 — Build the redirect map, one row per URL

This step decides whether the migration costs you traffic. Everything before it is copy; this is the part Google reads.

The rules are short and every one of them is load-bearing:

1. One row per old URL. Not one rule per section, not a pattern you hope covers the rest.
2. One hop. Old URL goes straight to the final URL. A redirect that lands on another redirect wastes crawl budget and leaks signal.
3. 301, not 302. Permanent, because it is.
4. No catch-all to the homepage. Sending every dead URL to / is a soft 404: Google treats it as “this page is gone” and the ranking goes with it. A blank 404 is more honest and no worse.
5. Keep the map for at least a year. Links, bookmarks, old newsletters and other people’s blog posts keep arriving long after you have stopped thinking about the migration.

That last row matters as much as the others: if a page has no equivalent, let it 404 or return 410. Redirecting it somewhere vaguely related teaches Google your redirects are unreliable.

Implementing it

The Redirection plugin keeps its table in the database and imports a CSV, which is the sane choice when you have more than about 20 rows. At the time of checking — 2 November 2026 — it was at version 5.10.1, 2,000,000+ active installs, rated 4.4 from 703 reviews, last updated 19 September 2026. If you prefer to keep redirects out of the database, the same map goes into .htaccess on Apache or a location block on nginx, which is faster and survives a plugin being deactivated.

Verifying it, which is not optional

Do not trust the plugin’s green tick. Check the actual response from the actual server:

curl -sI https://example.com/about | head -1
# HTTP/2 301

curl -sI https://example.com/about | grep -i '^location:'
# location: https://example.com/about/

curl -s -o /dev/null -w '%{num_redirects}\n' -L https://example.com/about
# 1

A 301, a Location: header pointing at the new URL, and a hop count of 1. A hop count of 2 means you have a chain — usually because the destination slug changed after the redirect was written. A 200 on the first request means the redirect is not firing at all and the old path still resolves. Run this against every row in the map, not a sample, and keep the output file.

Why redirects come after the content, not before

The instinct is to set redirects up on day one so nothing breaks. Resist it. A redirect pointing at a URL that does not exist yet is a 301 into a 404 — Google follows the hop and finds nothing, which is worse than the old page simply being unavailable, because now the old URL is confirmed dead. Redirects are also unwritable before the content exists: you cannot map /services-page to /services/ until you know the new page got the slug services and not our-services. Build the content, confirm the slugs, then write the map in one pass with the real destination list in front of you.

Step 8 — Sitemaps and Search Console, in that order

WordPress generates a sitemap at /wp-sitemap.xml without a plugin. Submit it in Google Search Console and Bing Webmaster Tools once the new site is live on the real domain. If an SEO plugin has taken over the sitemap, submit that URL instead — submitting both is harmless; submitting a stale one is not.

Keep the old Wix sitemap submitted until Wix is gone — it is a list of URLs Google already knows. For the first month, watch Pages ? Not indexed for two shapes of failure: old URLs returning 404 (a missing redirect row) and new URLs marked “duplicate, Google chose a different canonical” (two pages targeting the same thing).

One myth: you do not need the Change of Address tool. That is for moving to a different domain; yours is staying put and only the software changes. What you need is working 301s, a live sitemap and time. Google’s own documentation on 301 redirects is blunt about this: permanent redirects are how you tell Google a URL has moved for good.

If SEO settings were part of why you are leaving Wix, that is the next decision — choosing a WordPress SEO plugin covers titles, schema and sitemaps, and you want it installed before re-entering 200 meta descriptions by hand.

Step 9 — Decommission Wix in the right order

In this order, because each step depends on the one before:

1. Lower the DNS TTL a day or two before launch, so the switch propagates in minutes rather than hours.
2. Point the domain at the new host and confirm the live site loads over HTTPS with no mixed-content warnings.
3. Test the redirect map against the live domain — the same curl checks as Step 7, now that the real domain resolves to WordPress.
4. Keep Wix paid for at least 30 days. You will find a missing page, an image you forgot, a form entry you needed. A live reference copy is worth one month’s subscription.
5. Export the leftovers: form entries, any customer records, the media folder, the URL list, and the analytics you can still reach.
6. Cancel Wix only after the redirects have been verified and Search Console shows the new URLs being indexed.

Redirects live on the new host, not in Wix. Once DNS moves, Wix’s redirect settings stop being consulted, so every rule has to exist as a 301 served by WordPress, .htaccess or nginx.

What the move actually costs

No honest article can quote a migration price, because the work scales with your unit count. What can be stated is which parts are free.

The three plugins above are free to download from wordpress.org, and for a one-time move the paid tiers mostly buy conveniences you will not use again. Where money genuinely helps is the app-dependent row: if your site runs bookings and memberships, paying someone who has done that specific rebuild is usually cheaper than learning it under deadline.

When you should not migrate

Some sites should stay on Wix, and saying so is more useful than another checklist.

• Your site is a small brochure site that works. Eight pages, one contact form, no blog, no store. The rebuild is doable, but the gain is mostly philosophical. If nothing on the site is currently costing you customers, this is a hobby project with a business justification bolted on.
• Your site depends heavily on Wix apps. Bookings with staff calendars, a members area with course progress, an event system with ticketing. Rebuilding them means assembling three or four plugins and owning the integration yourself. That is a legitimate reason to stay, or to move only after prototyping the hardest app on staging.
• You have no organic traffic to protect. If the site gets almost nothing from search, the redirect map is cheap insurance rather than a rescue operation — and the migration is a straight content move with no ranking risk to manage.
• You are migrating to save money. Price the hosting, the premium plugins your replacement features need, and your own hours at anything realistic. WordPress is cheaper at scale and rarely cheaper for a five-page site.

The reverse is also true: a site with a real blog, a real product catalogue, or a design that has hit the ceiling of the Wix editor. There the rebuild pays for itself in control — you own the database, the theme and the redirects.

Frequently asked questions

Is there a one-click Wix to WordPress importer?

No. Wix does not produce a WordPress import file, and WordPress’s importer has no Wix source — it reads WXR XML, which only WordPress itself generates. Any service advertising one-click Wix migration is either scraping your live pages and rebuilding them, or moving you to a Wix-hosted product. Ask what it does with your redirects before you pay.

Can I keep my Wix URLs on WordPress?

Sometimes. Wix pages usually sit at the root, and WordPress pages do too, so identical slugs survive untouched. Blog posts and products usually need a redirect each, because the prefixes differ. Check your sitemap against your new permalink structure before you import, and count the mismatches — that count is your redirect workload.

Will I lose my Google rankings?

Not if the content exists and every old URL 301s to its real replacement. Rankings fall when old URLs return 404, when redirects point at the homepage, or when a redirect lands on a page that is still empty. Expect some fluctuation for a few weeks while Google reprocesses; expect a permanent loss only where you deleted content that had links.

What happens to my Wix blog comments?

They do not come across. Wix has no comment export, and the RSS route carries posts, not comments. Copy the ones worth keeping into the new posts by hand, or accept that they stay behind. If comment volume is a real asset, plan a few hours for it and treat it as a content task rather than a migration task.

How long does Wix need to stay live?

Until the new site is built, reviewed and redirected — and then about 30 days more. You need a reference copy while you rebuild, and you will want it after launch when a page turns out to be missing. Cancelling early is the one mistake that turns a recoverable migration into an unrecoverable one.

Can I move a Wix store to WooCommerce?

You can rebuild one. Products, prices and images come across by hand or by CSV import into WooCommerce; orders, customers and app data do not, and Wix’s store data has no export that maps onto WooCommerce’s schema. Count products as units, rebuild variations manually, and reconcile stock before you take the old store offline.

The short version

Rebuild the site, carry the content in through the REST API, rebuild the apps that were doing real work, then map every old URL to its new one with a single 301 and verify each one with a HEAD request. Do it in that order and the domain switch is boring, which is exactly what you want. If you need a theme that will not fight you on tables or media widths while you do it, our free Spiracle themes are built for that shape of site.