How to migrate from Wix without losing Google rankings

Migrating from Wix doesn't by itself make you lose your Google rankings. The drop happens if the URLs change without a map, if 301s aren't active on the new hosting the moment you disconnect the domain, or if pages that were already getting clicks aren't rebuilt. Wix doesn't export a ready-to-rehost site: you have to rebuild the pages and migrate content, domain and data.

This guide is for those who have already decided to leave. If you're still weighing up whether it's worth it, start with the guide to the alternative to Wix for businesses. The general method for a migration, with figures from a two-step Joomla move, is covered in the guide on how to migrate a site without losing Google rankings. Here we deal only with the Wix case: what can be carried over, where the 301s need to live, and which mistakes bring your traffic down.

Who this guide is useful for (and who it isn't)

It's useful if you have a Wix site with your own domain, a few pages that already bring in searches or contacts, and you've decided to switch platform. The typical reader is the owner or marketing manager of an SME: the site has become a channel, Wix feels too limiting, and the real fear isn't the cost of a redo, it's switching off traffic that already exists.

This isn't the right guide if your site still lives at a nome.wixsite.com address and has never had organic clicks worth protecting: in that case you're not migrating an SEO asset, you're publishing a new site. It's also not the right guide if the issue is an online store with a catalogue, customers and orders to move: that's a different scope, covered in the guide on how to migrate from Shopify, which deals with catalogue and transactional data. Wix Stores has similar constraints, but the process is not this one.

Does migrating from Wix make you lose your Google rankings?

No, not automatically. Google documents moving a site with a URL change as a sequence: prepare the destination, map old address to new address, enable permanent redirects, update sitemap and Search Console, monitor. Server-side 301 and 308 redirects are the ones Google treats as permanent. 302s and JavaScript-only redirects are weaker and slower to consolidate.

What isn't true, and what we hear far too often, is "if you switch platform you lose everything". You lose everything if, on switch day, the domain is already responding on the new hosting and the old URLs have no destination. You lose chunks if you only rebuild the home page and three services, leaving out the blog posts Google had already indexed. You don't lose rankings because Wix and the destination CMS are different: Google sees pages, not the builder's brand.

Some fluctuation in the following weeks is expected. Google has to re-crawl, reassign signals, work out the canonicals. It's not a guarantee of parity within seven days, and it's not a death sentence either. If, after go-live, Search Console fills up with 404s on paths that previously received impressions, the problem is the map, not "the migration" in the abstract.

What Wix lets you take with you, and what it doesn't

Wix is a hosted builder. The site lives on their infrastructure. You don't get an archive of the designed site to upload to another server. Anyone who promises to "move Wix as is" is describing a visual rebuild, not a file transfer.

What can, in practice, be saved before touching the DNS:

1. Text and structure. Home, services, about us, contacts, landing pages, blog posts. Inventory every public URL, not just the menu items. The menu hides orphan pages that are nonetheless in Google.

2. Images and files. Many images on a Wix site come from a Wix CDN, not from your domain. If you leave them there and shut down the account, the new pages end up without photos. Download them and re-upload them to the destination. Don't assume a hotlink to the CDN will stay valid.

3. List of URLs and metadata. Title, meta description, H1, slug. These are needed so you don't have to rewrite from scratch the signals with which Google has already understood each page. Changing platform doesn't force you to change every title.

4. Forms and contacts. Leads live in the Wix panel. Export what the panel allows and rebuild the forms on the new site, with a privacy notice and consent. Personal data remains your responsibility: we cover this in the guide on GDPR and websites.

5. Domain. Two distinct cases. If the domain is only pointed to Wix (DNS or nameservers), the switch is simply a repointing. If the domain is registered with Wix, there's also a registrar transfer, with its own timing. Don't mix the two on the same day without a checklist.

What doesn't travel: the theme, the editor's animations, Marketplace apps, Wix Bookings, Wix Events, automations, forms in the state you designed them. These need to be replaced or left behind. Deciding this in advance avoids finding out at go-live that the booking calendar was Wix, not "the site".

The point generic guides leave out: where the 301s live

Wix has a redirect manager. It's for changing slugs inside Wix. Once the domain stops pointing to Wix, that manager stops responding. The 301s that protect rankings, after you leave, need to live on the new hosting, or at the layer that responds to the domain.

The damage we see most often with closed platforms isn't rebuilding the pages. It's disconnecting the domain from Wix before the 301s exist on the destination. For a few hours, sometimes a day, Google and users find the new site without the old paths, or the old hosting already switched off. The 404s from that window stay in Search Console reports for weeks.

The correct sequence is the opposite of the intuitive one. First you build and test the destination, with the map already loaded. Then you change the domain's pointing. Then you verify that every URL in the map returns a 301 to the new address, and that the new address returns 200. Turning off Wix to "tidy up" on the morning of the switch is the move that costs the most traffic.

How to map the URLs of a Wix site

One row for every public URL that matters. Not one row per menu section. Tools: a crawler of the current site, an export of pages from Search Console (last 16 months, if the property exists), a manual list of campaign landing pages. The three lists don't match. You need the union of them.

Wix cases to handle one by one:

• Custom domain already active. https://www.tuaazienda.it/servizi remains the address to protect. If you can keep the same path on the new site, the 301 isn't needed on that page: what's needed is a 200 at the same URL. Fewer changes, less work for Google.

• Site still on wixsite.com. You're also changing the visible domain. This is a move with a change of host and hostname. The 301s from the old hostname only work as long as that hostname responds. If you turn off the Wix site, the 301s from wixsite.com disappear. In this case, the SEO value to save is low if there were no clicks; don't invent work you don't actually have.

• Blog. Wix often uses paths like /post/nome-articolo or variants. The new CMS will use a different folder. Every indexed article needs its own row. Merging ten posts into one "news" page is a loss, not a simplification.

• WWW, HTTP, trailing slash, parameters. Wix may have served multiple variants of the same content. The map should include the URL that Google shows in Search Console, not the one you prefer. Then, on the new site, just one canonical version.

• Pages you won't bring over. They're not "forgotten". They're redirected to the closest equivalent, or a deliberate 404 is left if they had no traffic. A 301 from all old URLs to the homepage is a mistake: Google reads it as a weak signal, and the user lands in the wrong place.

The map is a spreadsheet, not an intention. Minimum columns: current URL, status (200/redirect/other), clicks or impressions if you have them, destination URL, redirect type, verification date after the switch.

How to migrate from Wix, step by step

1. Snapshot. Full crawl, Search Console export, list of conversions (forms, phone, bookings). Mark the ten URLs that matter most. Those are rebuilt first and tested last.

2. Content inventory. Text, images, files, forms, any products. Download the images from the CDN. Export the contacts you need. Note down the Wix apps in use: each one is a gap to cover or to abandon.

3. Rebuild in staging. The new site is built on an environment that isn't yet the production domain. Same paths where possible. Titles and H1s of pages that already rank are reused, barring obvious errors. This isn't the time to "rewrite everything for SEO".

4. Loading the 301s in staging. Every row of the map must already respond, on the new hosting, before the switch. Test with tools that show the HTTP status, not with "I clicked and it opens".

5. Domain switch. DNS or nameserver change. A low TTL set in advance reduces the wait. The Wix site is not deleted. The new site must already serve 200s and 301s.

6. Afterwards. New sitemap submitted in Search Console. URL inspection on the ten pages that mattered most. Monitoring of 404s, canonicals, and clicks per page. Google recommends keeping redirects in place for a long time; don't turn them off after two weeks just because "it's done now".

If during the rebuild you also want a faster site, speed is measured on the destination, not declared. The reference remains the Core Web Vitals, explained in the Core Web Vitals guide. Don't promise a ranking jump just because the new CMS "is faster". Speed is one piece. The 301s and the content are the others.

Five mistakes that make traffic drop

1. Domain switch to an empty destination. The new site is "almost ready", the client is in a hurry, the DNS gets changed. The 301s come later. This is the sequence that produces mass 404s.

2. Only the homepage, then "we'll do the rest". Google and users land on internal URLs. If services, blog and campaign landing pages aren't there, the traffic has nowhere to go.

3. All 301s to the homepage. Technically it's a redirect. For Google and for the person it's a loss of context. A services page should land on the services page, not on the showcase.

4. Hotlinking Wix images with a closed account. New pages are left without photos. Search Console won't tell you the same day; your clients will.

5. Noindex or robots.txt on old paths "to clean up". Google, in its guide to moving a site, warns against blocking previous URLs during the transition. If the crawler can't see the 301, it can't follow it.

Staying, WordPress, managed CMS: who's better off where

Leaving Wix doesn't have a single destination. The table isn't a ranking: it's a scope, with the same criteria on every row.

When KeideaCMS isn't the right choice

KeideaCMS is a managed proprietary CMS for business websites, ecommerce and, on a dedicated plan, bookings. It isn't Wix. We don't replicate the Marketplace, Wix Bookings, Wix Events, Wix Restaurants or the automations in their dashboard. If the appointment calendar or the restaurant menu is Wix, you're not changing website: you're changing the software you work with. In that case, stay, or choose an industry-specific vertical, not a general CMS.

We're not the right choice either if you want to keep doing everything yourself, at low cost, with a self-service builder. There, Wix or another builder remain consistent. We're not the right choice if you need a WordPress site on which your developer installs plugins at will. We're not the right choice if the site is still a single page on wixsite.com with no rankings to protect: you just need a well-made first site, not an SEO migration project.

Finally: we don't transfer Wix's code, because Wix doesn't hand it over. Anyone who asks for "the same site, another server" gets a rebuild. This should be said before signing.

How we approach this problem at KeideaCMS

For a company leaving Wix, the work is a migration with a map, not a restyling. We rebuild the pages on our CMS, keep the paths that can be kept, upload the 301s before the switch, move the domain once the destination responds. KeideaCMS is a proprietary subscription-based platform, on our servers. The domain, the content and the data remain yours, exportable if you ever change your mind. We don't hand over the software's code: the subscription fee pays for continuity, updates and a point of contact, not ownership of the files.

We don't promise to preserve every ranking position. We promise a method aligned with what Google asks for when moving a site, and monitoring after go-live. What's included in the project and what remains optional can be found on our plans page; the comparison with other approaches is on the comparison page. The journey of a business website, from brief to launch, is described on the building a business website page.

KeideaCMS

Want a review of your Wix site before switching the domain?

Request a URL map analysis → How we build our websites

Checklist before the domain switch

To be ticked off in writing, not verbally on the day of the DNS change.

• Complete list of public URLs (crawler + Search Console + campaign landing pages).

• The ten highest-value URLs have a 200 on the new path, or a 301 to the equivalent.

• No mass 301 to the home page.

• Images downloaded from the Wix CDN and re-uploaded. No leftover hotlinking on the pages that matter.

• New forms active, with privacy notice. Export of Wix requests already done.

• Wix apps in use listed: replaced, or accepted as a loss.

• The 301s respond on the new hosting before the switch, verified via HTTP status.

• DNS TTL lowered in advance. Domain: clear whether it's just pointed or also registered with Wix.

• Wix account not cancelled on switch day.

• Search Console: domain property ready, new sitemap to be submitted right after.

• No noindex and no robots.txt block on the paths that need to redirect.

Sources and check date

Migration method and redirect types: Google Search Central documentation, consulted on September 13, 2026, How to move a site and Redirects and Google Search. The Wix support pages on legacy export and 301 slugs, checked the same day, returned a 404: the export limits and the fact that Wix's 301s only live as long as the domain points to Wix are described here as structural constraints, not as a citation of a current Wix article. Proposed author: Marco Artese. Proposed reviewer: Marco Artese. The public byline is awaiting human approval.

In summary

Migrating from Wix without losing rankings is a mapping job, not a theming one. You inventory what Google already knows, rebuild on the destination, activate the 301s on the new hosting, and only then disconnect the domain. Wix doesn't give you the site in a folder: it gives you content and, if you've connected it, a domain. Everything else has to be rebuilt. If your business runs on a Wix app, maybe you don't need to migrate. If the site is a channel with URLs that already bring in clicks, the risk isn't changing platform: it's changing the DNS before the destination is ready. The next step, if you want a read of your current Wix setup, is a URL map analysis: no commitment, a clear scope.