Almost everyone who sets out to move their website off Wix starts in the same place: searching for the export button. There is not one, or rather there is one that does far less than the name suggests, and the gap between what you think you are exporting and what actually comes out is where migrations go wrong.
Almost nothing transfers automatically, and the part that matters most is not your content at all, it is your URLs. A move that copies every page across and gets the redirects wrong will cost you more traffic than one that rewrites half the content and gets them right. So the honest framing is this: you are not exporting a website, you are rebuilding one and carefully forwarding the old addresses to the new ones.
What moves with your website, and what does not
Both Wix and Squarespace are closed systems. They are not hiding your content maliciously, but neither was built to hand a site to a competitor, so the export paths that exist are narrow and mostly cover blog text.
| Thing | Reality | What that means in practice |
|---|---|---|
| Blog posts | The one thing with a real path out, usually via the site's feed or a blog-specific export. Text and structure come across. | Images inside posts often do not, and come through as links back to the old host that break the day you switch off. Budget time to pull and re-upload images and fix every reference. |
| Standard pages | No export. Your home page, services pages, about page and contact page exist as builder layouts, not portable documents. | Copy and paste the words, rebuild the layout. This is normal and it is also the moment most people improve pages they have been meaning to fix for two years. |
| Images and files | No bulk download in any convenient form. They live in the platform's media library. | Pull them individually, or crawl the live site and harvest them before you switch anything off. Do this early, while the old site is definitely still up. |
| Products, orders and customers | Product data can usually be exported as a spreadsheet. Order history and customer accounts are much harder, and passwords never transfer anywhere. | Plan for customers to reset passwords on first visit, and keep read access to the old store for records long after you stop selling on it. |
| Form submissions | Sitting in the platform's dashboard, and generally not exportable in a useful shape. | Export what you can before the account lapses. Anything you rely on for sales history, get it out first. |
| Design and layout | None of it. The templates are proprietary and there is no equivalent on the other side. | Rebuild. Treat this as the redesign it actually is rather than pretending it is a copy. |
| The domain | Yours, provided you registered it yourself or can get into the account that did. | Check this before anything else. If the domain sits inside a builder subscription or an old developer's account, sort that out first, because everything else depends on it. |
Illustrative of the common cases rather than a guarantee about your specific site. Both platforms change what they offer, so verify the current export options on your own account before planning around them.
That domain row is the one that stalls projects. If you are not certain the domain is in your own name and under your own control, settle that first: our guide on who owns your website covers how to check and how to get it back if the answer is uncomfortable.
The redirect map is the whole job
Here is the part that decides whether your traffic survives. Search engines have spent years learning that a particular address on your domain answers a particular question. When you rebuild, those addresses change, and unless every old one is permanently forwarded to its new equivalent, you are effectively launching a new site with none of that history.
This is harder coming off a builder than coming off almost anything else, because these platforms sometimes put their own structure into your addresses, so the old and new shapes do not line up neatly. Which means the mapping is manual work, page by page, and it cannot be skipped or guessed.
- List every address that exists today. Not the ones in your menu, all of them. Crawl the site, then cross-check against your analytics and your search console data for the last twelve months, because pages people still land on are often pages you forgot you published.
- Sort by what they earn you. Traffic, enquiries, links from other sites. The top of that list gets careful individual attention; the long tail can be handled in patterns.
- Pair each old address with a new one. Every single one needs a destination, and the destination should answer the same question. Sending forty retired pages to your home page is the classic shortcut and it wastes most of what those pages were worth.
- Decide what genuinely dies. Some pages should not come back. Let those return a clean not-found rather than forwarding them somewhere irrelevant, which is worse for the reader and no better for anyone else.
- Test the map before launch, not after. Every redirect, on a staging version, in a spreadsheet you can tick off. This is dull and it is the single highest-value hour in the project.
A sequence that does not lose a fortnight
Order matters more than speed here. The version that goes wrong is almost always the version where someone cancelled the old subscription early.
- Harvest everything first. Images, posts, product data, form history, anything in the dashboard you would miss. Do it while the old site is fully live and paid up.
- Build the new site somewhere private. Not on the live domain. A staging address, blocked from search engines, where you can get it properly finished.
- Build the redirect map alongside the new site, not at the end. It tends to reveal pages you forgot to rebuild, which is exactly what you want it to do while there is still time.
- Point the domain at the new site. This is the actual switch, and it is a change at your domain settings rather than anything dramatic. Expect a few hours for the change to be visible everywhere.
- Keep the old subscription running for at least a month. This is the cheapest insurance in the whole project. If something turns out to be missing, it is still there. Cancelling on launch day to save one month's fee is a false economy people regret.
- Submit the new site map and watch for a fortnight. Expect a wobble in rankings while everything is re-crawled. What you are watching for is not perfection, it is recovery: errors falling rather than rising, and the pages that mattered coming back.
What it costs and how long it takes
Illustrative ranges from the kind of work we quote, not a price list, and your own site could sit outside them for perfectly good reasons.
| Size of site | Typical range | Typical timeline |
|---|---|---|
| Small brochure site, up to about ten pages, no shop | $3,000 to $8,000 | Two to four weeks |
| Content-heavy site with a real blog archive | $8,000 to $20,000 | Four to eight weeks |
| Online shop with products, orders and customer accounts | $15,000 to $45,000 | Six to twelve weeks |
Ranges chosen to be honest about the middle of the market rather than to win a bidding war. The variables that move them most are the number of URLs, whether the content is being rewritten or carried across, and whether a shop is involved.
The running cost afterwards is the part people forget to compare. A builder subscription is one predictable monthly fee that covers hosting, updates and security. Off it, those become your responsibility, whether you handle them or pay someone. If you are weighing the two models rather than just the move, website builder or hire a developer sets them side by side, and our redesign work is where this kind of migration actually lands.
If you have not settled whether this is a move at all, rebuild or refresh is the prior question, and our company websites page shows what the rebuilt version usually looks like.
The mistakes that cost traffic
- Cancelling the old subscription on launch day. The most common and most painful. Keep it a month.
- Forwarding everything to the home page. Fast to configure, and it throws away most of what your old pages had earned.
- Forgetting the pages not in the menu. Old landing pages, event pages, posts from four years ago that quietly bring in half your traffic.
- Leaving images pointing at the old host. They work perfectly until the day they do not, which is the day you switch off.
- Launching the new site without blocking search engines from the staging version, so both exist at once and compete.
- Treating it as a straight copy. It is a rebuild. Budget for it as one, and take the opportunity to fix the pages you have never liked.
Not for you if
One thing worth saying plainly at the end. If you decide to do it, the work that protects your traffic is not the design and it is not the writing. It is the unglamorous hour spent listing every old address and deciding where it goes. Do that properly and the rest is just building a website.