Gemin
Get in touch

Wix to Webflow

Migrate from Wix to Webflow

A Wix migration is a rebuild, not a one-click export. That is the honest starting point. The upside is that the rebuild is where the site can finally get a structure your team and search engines can work with.

Start a project

A migration like this usually takes 2–3 weeks

What the migration covers

What moves, and what we figure out first.

What moves

  • Every important page, rebuilt in Webflow
  • Wix CMS collection data where it can be exported as CSV
  • Blog and other non-portable content through the best available extraction path
  • Images, metadata, redirects and tracking setup

What we figure out first

  • Collections and pages move differently. Wix CMS collections can export to CSV. Layouts and many app-driven features do not come across that way.
  • Absolute positioning needs a real responsive rebuild. Wix layouts often need to be redrawn in Webflow using flex and grid, not traced pixel by pixel.
  • Wix apps become decisions. Booking, stores, members, forms and other apps are replaced with native Webflow features, embeds or connected services.

The scope depends less on page count than on what Wix is doing behind those pages. A mostly static site is a straightforward rebuild. CMS collections, the blog, the apps and any Velo code are what change the job, so I check those before quoting rather than counting pages.

Why people move

What changes when you move from Wix to Webflow.

What is being compared Wix Webflow
How pages are laid out Wix Elements placed at coordinates, or their newer editor Webflow Elements in flow, with the responsive rules written down A site built by placing things has no responsive behavior to carry across. It is defined during the rebuild, often for the first time.
Content model Wix Wix CMS collections Webflow Webflow collections with references
Getting content out Wix CMS collections and most product data as CSV. The rest is extracted by hand Webflow Not applicable The single biggest driver of what a Wix migration costs, and the blog is the part people are most often surprised by.
Custom code Wix Velo, inside Wix Webflow Custom code, APIs, and services outside
SEO control Wix Improved, still constrained Webflow Per-page and per-item, with real redirect handling
Apps Wix Bookings, members, stores and forms, each a separate product Webflow A native feature, an outside service, or dropped Every installed app holds its own data and needs its own answer. It is the part of a Wix quote that moves most.

What actually changes

The layout gets rules instead of coordinates.

Now

A Wix canvas

  • Elements at fixed coordinates
  • One desktop arrangement
  • A separate mobile arrangement
  • No rule connecting the two

After

A Webflow layout

  • Elements in flow, in grid and flexbox
  • One structure, with rules per breakpoint
  • Everything between the two widths, decided
  • Components, so a change happens once
A Wix site built in the classic editor has two arrangements and no rule connecting them, which is why there is nothing to convert. The responsive behavior is not carried across: it is decided during the rebuild, in most cases for the first time.

Once you have decided

What actually migrates.

What you have What happens Why
Pages Rebuild Made again in Webflow. The old version is a reference rather than something that can be imported. Wix layouts do not export, and absolute positioning would not be worth carrying if they did.
CMS collections Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. Exportable as CSV, which is the one part that moves as data.
Blog posts Rebuild Made again in Webflow. The old version is a reference rather than something that can be imported. There is no cross-platform blog export, so posts are extracted from the live site and rebuilt as collection items. This is the row people assume is a CSV and it is not.
Images Rebuild Made again in Webflow. The old version is a reference rather than something that can be imported. There is no bulk media export, so assets are collected from the Media Manager, compressed and rehosted. On an image-heavy site it is the line that moves the quote most.
URLs and redirects Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. Wix paths rarely match the new structure; every one gets mapped.
Wix apps and Velo Rebuild Made again in Webflow. The old version is a reference rather than something that can be imported. Installed apps, Velo code and anything calling an external API get audited one at a time, then become a native feature, custom code, a service chosen for the job, or a deliberate removal.

Before you budget it

Where this migration gets complicated.

  1. 01

    Wix apps are third-party products, each with its own answer

    Bookings, members, stores and forms are apps with their own data. Each becomes a Webflow feature, a different service, or a deliberate removal, and the answer is different for every one.

  2. 02

    Velo code is Wix's runtime and does not come out

    Any site using Velo has logic written against Wix's own APIs and data collections. None of it ports. What it was doing has to be established by reading it, then rebuilt as custom code or as a service outside the site.

The part quotes leave out

How I move it without losing the search footprint.

  1. The search footprint is inventoried before anything moves

    A crawl shows what the current Wix site links to now. Analytics and Search Console show which addresses people and search engines are still reaching, including ones nothing on the site points at any more, so the list is the union of all three. The traffic, the top pages and the queries earning impressions get written down at the same time: without a baseline, a change in how you count and a change in what you get are the same graph.

  2. What can stay where it is, stays

    Addresses first, then the titles and descriptions attached to them, then the canonicals. Metadata is the easiest thing to lose in a rebuild, because the new site will happily generate something plausible for every page and nothing will report a problem.

  3. Everything that changes gets one rule, not a chain

    A redirect pointing at a redirect still arrives, so nothing looks broken. Each address gets an intentional destination rather than an inherited one: individual rules where the destinations differ, a pattern where a whole route family changes predictably. The new sitemap goes in at cutover carrying the canonical addresses and nothing else.

  4. Every old address is requested after launch and the response recorded

    The whole list, not a sample. Looking for anything returning 404 that should not, anything returning 200 that should have moved, and anything taking more than one hop. Then indexing and traffic by landing page for the week after cutover, which is the window included, and longer by arrangement where the site is large enough to warrant it.

None of this guarantees a ranking, and search results can move during a migration for reasons nobody controls. The goal is to change platforms without unnecessarily changing what search engines already understand about the site, and to notice quickly when something did change. Afterwards I watch indexing, what the old addresses return and traffic by landing page, so normal recrawling can be told apart from an implementation problem.

How it runs

Six stages, and what each one looks like.

Wix

Other migrations

Coming from somewhere else?

Reach out and see if we are a good fit.

Start a conversation

Currently booking two to four weeks out.