Moving from Wix to WordPress: What Transfers and What You Rebuild

There is no export button: what "moving" from Wix to WordPress really means

People ask me to "transfer" a Wix site the way you move a file from one folder to another. It does not work like that, and it is better to hear it before the project than in the middle of it. Wix states it plainly in its help center: a Wix site is built with Wix's technology and has to be hosted and operated on Wix's servers. There is no file to download and upload to another host.

So a move from Wix to WordPress is three separate jobs. The first is a rebuild: the design, the page layouts and the forms are built again on WordPress. The second is carrying content over: texts, images, products, customers. The third is the switch itself: the domain, the email and the addresses Google already knows. Most of the risk sits in the third job, and it is the one that gets the least attention in a quote.

When staying on Wix is the right call

I earn nothing from telling you to stay, and I still say it often. A move costs a rebuild and carries a risk to your rankings. It pays off only when the platform is what is holding the business back. Check that before anything else: the rebuild or redesign tool asks the questions I would ask, and the free site report shows what is actually wrong with the current site. Staying is usually the better decision when:

• The site does its job. Inquiries or orders come in, and you update it yourself without calling anyone.
• What bothers you is the look. A new design inside Wix is far less work than a new design plus a new platform.
• The site ranks poorly because the content is thin. Thin content stays thin on WordPress; write the pages first.
• Nobody will maintain a WordPress site. Wix handles hosting and updates for you; on WordPress, updates, backups and security are yours or your developer's.
• A busy season is close. A move is planned for a quiet month, not for the weeks before your peak.

When it is time to move

The honest reasons are about what the business needs next, not about Wix being "bad". The site has to connect to a CRM, an invoicing system or stock management in a way the platform does not offer. The store needs pricing by customer type, quotes or a checkout with your own rules. You want to own the code and the hosting and be free to change developer. Or content is becoming a channel and you need full control over page structure, templates and speed. If two of these are true, the conversation is worth having. If none is, go back to the previous section.

What you can take with you, and what is rebuilt

The table at the top of this article lists it item by item. The short version: data that lives in a list can be exported, and anything that is a page cannot.

Pages and blog posts are the manual part. Wix's own help page says that exporting blog posts to other platforms is currently not possible, and WooCommerce's migration guide says the same about pages and posts: there is no direct export. In practice the texts are copied page by page into the new site, which is also the right moment to delete what nobody reads and rewrite what is out of date.

Images need their own line in the plan. According to WooCommerce's guide, Wix does not bundle media such as product images in its exports, so the images are downloaded and uploaded again. If you still have the original files from the photographer, use those and not the copies on the site.

The domain: the 60-day lock, the transfer code and how long it takes

First find out where the domain is registered. If you bought it from another registrar and only connected it to Wix, nothing has to be transferred; you change where it points. If you bought it through Wix, you have two options, and the first one surprises most people: you do not have to transfer the domain in order to leave. Wix lets you keep the domain registered with it and edit its DNS records so that they point to a site hosted elsewhere. Wix notes two limits: the name servers of a Wix domain cannot be changed, and DNS changes can take up to 48 hours to update everywhere.

The second option is a full transfer to another registrar. Wix sends a transfer authorization code (EPP code) to the email address of the domain's registrant contact, you give that code to the new registrar, and according to Wix a transfer usually takes up to 7 days. Wix also writes that once the domain is transferred away, the Wix site is disconnected from it. That is why the new site has to be finished and tested before the transfer starts, not after.

The lock is what catches people. Under the ICANN policy that Wix describes, a domain cannot be transferred within 60 days of registering it, of changing the registrant contact information, or of a previous transfer between providers, and Wix says it cannot change this. The classic mistake is to correct the owner details "to tidy things up" a week before the move, and lock the domain for two months. If you are inside the lock period, use the first option: point the DNS records at the new site now and transfer the registration later.

Email depends on the domain: plan the MX records first

A site that is down for an hour is unpleasant. A business whose email silently stops arriving loses inquiries without knowing it. Mail to your domain is delivered according to the MX records in the domain's DNS, and they sit in the same place as the records that point to the site. Wix's transfer page answers this directly: business email does not keep working by itself after a transfer, and the MX records have to be added again at the new provider.

So before anything is touched, copy every DNS record of the domain into a document: MX, the TXT records that mail services use to verify your messages (SPF, DKIM), and any record that belongs to another service such as a newsletter tool. If you only repoint the site and leave the domain at Wix, change the records of the site alone and leave the mail records as they are. If you transfer the domain, recreate all of them at the new provider and send a test message in both directions on the day. And if the mailboxes themselves were bought through Wix, ask Wix support what happens to them when the plan is cancelled before you cancel it.

Keeping Google: the URL map and 301 redirects

Google does not rank your site; it ranks addresses. On the new site most addresses will be different, and every old address that returns "page not found" is a page whose ranking you gave up. Google's guide to site moves describes the work: list the old URLs, decide where each one should go, and redirect with a permanent redirect such as 301 or 308. Once the domain points to WordPress, those redirects are set on the new site.

• Build the list from three places: the current sitemap, the pages that receive visits in Google Search Console, and pages that other sites link to.
• One old address, one matching new address. Google warns against redirecting many old URLs to one irrelevant destination such as the home page.
• Redirect straight to the final address. Google advises against chains of redirects.
• Keep titles, headings and the main text of pages that rank. A move is a bad week to also rewrite your best page.
• Submit the new sitemap in Search Console after launch, as Google recommends, and watch the "not found" report for addresses you missed.
• Leave the redirects in place. Google says to keep them as long as possible, generally at least a year.

What to expect from Google after the switch

Nobody can promise that rankings will not move, and anyone who does is selling. Google itself writes that you should expect temporary fluctuation in ranking during a move, and that for a medium-sized site it can take a few weeks or more until the new URLs replace the old ones in the results. What a good migration controls is whether the dip is short and recovers. Because the domain stays the same, there is no change-of-address request to file; that tool in Search Console is for moving to a different domain. The new site also has to be at least as fast as the old one, and the checks for that are in my WordPress speed guide.

Moving a Wix store to WooCommerce or Shopify

A store has more data and therefore more that can be exported. Wix Stores exports products with their data to a CSV file, up to 5,000 rows per file, and Wix notes that exporting digital products is currently not supported. Orders can be exported to CSV as well, and contacts too, up to 50,000 at a time. On the other side, WooCommerce has a product importer built into its admin, and its documentation also describes an official Wix migration extension. Customer passwords do not move: WooCommerce's guide says they cannot be migrated, so every customer sets a new password. Tell customers in advance; do not let them find out at the login screen.

A store is also a reason to stop and ask whether WordPress is the right destination at all. If the catalog and the checkout are standard and nobody on your side wants to deal with servers, Shopify may fit better. Shopify's help center has a guide for moving from Wix: it recommends importing products by CSV, and describes a Store Migration app that imports products and customers from Wix. Shopify says the app is in early access and available only to certain stores, and that products with more than three options are imported without their options. I build on both, so the recommendation follows the store: WooCommerce when you need your own pricing rules and live connections to other systems, Shopify when you want the platform to run itself.

Whichever you choose, three things are set up from scratch and tested with a real purchase: the connection to your Israeli payment provider, invoices, and shipping rules. None of them comes across in a CSV file.

The order of work, and the checks on launch day

The Wix site stays live and untouched until the new one is ready. The new site is built on a temporary address that is closed to search engines. That gives you time and a way back, which is the whole point of the order below.

• Inventory: every page, every address, every form, every connected service, and all DNS records of the domain.
• Export what can be exported from Wix: products, orders, contacts. Download the images.
• Build the WordPress site on the temporary address and move the content in.
• Write the address map and set up the 301 redirects on the new site. Test each one before launch.
• Check the domain: where it is registered, whether it is inside a 60-day lock, and which option you are using.
• Switch on a quiet day, early in the week, when someone is available to fix things.
• On the day: send and receive email, submit every form, place a real order, open the top old addresses and confirm each lands on the right page, open the site to search engines, submit the sitemap.
• Keep the Wix plan for a few weeks after the switch. It is your reference for anything that was missed, and your way back.

What drives the cost of a move

I do not publish prices, and a number without a scope would be a guess anyway. What I can say is what makes one migration a small project and another a large one. The project scope estimator puts your site into one of those groups before we talk, and every project gets a fixed quote after a short call. When you compare quotes, the questions in my guide to red flags when hiring a WordPress developer apply here too, with one addition: ask to see the redirect map as a deliverable. On my side, the site is built by my WordPress development service, with AI used for the repetitive parts of copying and checking content, and judgment for the rest.

• The number of page types. Thirty pages on one layout are less work than six different layouts.
• The same design rebuilt, or a new design. A new design is a design project on top of the move.
• How much content is copied by hand: pages, blog posts, images.
• A store: the number of products and variants, and whether order history and customers come along.
• What Wix apps did for you: bookings, members area, forms, newsletters. Each needs a replacement on the new site.
• The number of addresses in the redirect map, and how many of them bring traffic today.
• Languages. A Hebrew and English site is two sets of content and a right-to-left layout that has to be checked.