What moves with you and what does not
Start by getting clear on what you are actually taking with you, because most of the anxiety around leaving a builder comes from a misunderstanding of what you own. You own your words, your photographs, your logo, your domain name, and every bit of ranking authority your web addresses have built up in Google. None of that belongs to Squarespace or Wix. It is yours and it travels.
What does not travel is everything the platform generated for you. The design is theirs. The layout system is theirs. The blocks, the templates, the styling controls, the built-in store, the booking widget, and the member area are all theirs, and they exist only inside their system. There is no file you can download that turns a Squarespace or Wix design into a working website somewhere else. That is not an oversight on their part. It is the product.
This surprises people less on Wix than on Squarespace, because Squarespace at least has an export button and Wix does not have one at all. The Squarespace export produces a single file in the format WordPress uses, and it covers your standard pages, one blog, your text, and simple image blocks. It skips product pages, album pages, index pages, event pages, custom styling, and most of the specialty blocks. If your site has two blogs, only one comes out. Useful, but a long way short of a copy of your site.
The practical takeaway is that a move off a builder is a rebuild with your existing content, not a transfer. That sounds worse than it is. Rebuilding is the point: you are leaving because the platform's foundation is the problem, so keeping the foundation would defeat the exercise. What matters is that the rebuild lands your content on web addresses Google already trusts, or forwards cleanly from them. Squarespace vs. custom, in full → Wix vs. custom, in full →
The one thing to internalise
You are not exporting a website. You are extracting content and rebuilding it on addresses Google already knows. Everything else in this guide follows from that.
The audit to run before you cancel anything
Every bad builder migration story starts the same way: someone cancelled the plan, the site came down, and then they discovered what they had not copied. On Wix in particular the live site is the only copy of your content that exists, so the audit is not paperwork. It is the backup.
Run all of this while the old site is still live and still paid for. It takes an afternoon on a typical small business site and it makes every later decision easier.
Pre-move audit
- Capture every web address. Pull the list from your sitemap file, which both platforms generate automatically and which usually sits at your domain followed by "/sitemap.xml". Cross-check it against Google's free Search Console tool, which shows addresses Google knows about even when the sitemap has forgotten them. This combined list is the master reference for the whole project. Do this first. Nothing else can be planned without it.
- Pull twelve months of search data. Search Console tells you which pages appear in results and which ones get clicked. Sort by clicks and draw a line: everything above it is a page whose address you protect at all costs, everything below it is a page you are free to consolidate. Guessing at this instead of measuring it is how businesses accidentally retire the one blog post that brings in half their enquiries.
- Save your current search listings. For every page that matters, record the clickable headline and the short summary Google shows underneath it. Those carry across unchanged unless there is a specific reason to improve them. Changing your content, your addresses, and your listings all in the same week leaves you with no way to tell which change caused any wobble that follows.
- Download every image at full size. Both platforms serve resized copies of your photos, so right-clicking what you see on the page gets you a shrunken version. Go into the platform's media manager and download the originals. If you no longer have the originals anywhere else, this is the only chance you get, and photography is expensive to replace.
- Write down what every feature does. The contact form: which fields, where do submissions go, is anything filtering spam? The booking tool: what does the flow look like, does it take payment, does it sync to a calendar? The store: how many products, are there variants, is there order history worth keeping? This list is what turns a vague quote into a fixed one.
- Screenshot the pages you like. Not because the design comes with you, but because "make it feel like the old one but faster" is a much easier brief to work from when there is a reference.
If you are doing this because the site also needs to look and work better, the audit doubles as the input for a proper brief. How to write a website brief →
Building the forwarding map
The forwarding map is the document that decides whether your rankings survive. It is a spreadsheet with three columns: the old web address, the new one, and a flag for whether that address currently gets search traffic. Every address from your audit gets a row, including the ones that are not changing, so you can confirm they exist on the new site before you flip anything.
Builder sites make this more work than a WordPress move, because both platforms impose address shapes that a hand-built site has no reason to copy. Squarespace blog posts normally live under a blog folder, and on some configurations the publication date is baked into the address. Wix adds its own folders automatically: blog posts sit under a post folder, store items under a product folder, booking services under a service folder. Older Wix sites, built before the platform changed how addresses work, can still have exclamation marks and hash symbols in them from the days when the whole site ran as one page.
You have a choice on each of those. Reproducing the platform's folder structure on the new site means no forward is needed and zero risk on that address. Using a cleaner structure means every one of those addresses needs a forward. For your top traffic pages, reproducing the old address is usually the right call even when the shape is slightly ugly, because the safest forward is the one you never have to rely on. For everything else, forward and move on.
Pages you are retiring still need somewhere to go. A discontinued service page forwards to the nearest remaining service or to your services list. A thin blog post that has never earned a click forwards to the category or service page it relates to. What you must not do is point everything at the home page. Google can tell when a forward lands somewhere unrelated, treats it as a soft dead end, and passes nothing through.
One trap specific to this move: if you set up any forwards inside Squarespace's URL mappings panel or Wix's redirect manager over the years, those stop working the moment your domain points somewhere else. They live on the platform, not on your domain. Copy them into your map before you cancel, or you will silently break addresses that have been working for years.
Critical path
The forwarding map has to be finished and signed off before the domain moves. Every row gets tested against a private preview copy of the new site, not against the live one after launch. A forward you discover is broken on Tuesday has already cost you Monday.
The mechanics of this are the same regardless of which platform you are leaving, so the redirect chapter of the WordPress migration guide applies here too. How to migrate off WordPress →
Getting your content out of Squarespace
Squarespace's export lives in the site settings, under the import and export area. Choose to export the site, pick the blog you want included if you have more than one, and wait for the file to build. What you get back is a single file in WordPress's format, which sounds unhelpful if you are not going to WordPress, but it is a plain text file that any developer can read and pull content out of without needing WordPress at all.
Work through what the export gives you first: your standard pages, your text, your basic image blocks, and one blog with its post dates and addresses intact. Those addresses are the useful part. They tell you exactly what to put in the old-address column of your forwarding map without having to transcribe them by hand.
Then go and collect what the export left behind. Product pages, album pages, index pages, and event pages come out by opening each one on the live site and copying the text. Gallery images come out of the media manager at full size. Any custom styling you or a previous designer added does not come out in a usable form and does not need to, since the new site is being built rather than skinned.
Squarespace form submissions are worth a specific mention. If your contact form has been storing enquiries inside the platform rather than emailing them, those submissions are business records and they disappear with the account. Export them to a spreadsheet before you cancel. The same goes for any email list you have been collecting through the platform's own marketing tools: get the subscribers out, in a file, on your own computer.
The move is also the cheapest moment you will ever get to improve weak pages. Content you carry across unchanged keeps ranking exactly as it did. Content you tighten while you are already touching it can start climbing within weeks, because Google re-reads everything anyway during a rebuild. What pages does a website need →
Getting your content out of Wix
There is no export. This is the single most important sentence in the guide for Wix owners, and it is worth reading twice because almost everyone assumes otherwise. Wix does not provide a way to download your site, your pages, your design, or your content as a file. The site exists on Wix and only on Wix.
What that means in practice is that content comes out the manual way. Open each page on the live site, select the text, and paste it into a document. Work through the site in the order of your address list so nothing gets skipped. For a business site of five to fifteen pages this is a couple of hours of careful, boring work, and it goes faster if one person does the whole thing in one sitting rather than three people doing it piecemeal.
Images come out of the Wix media manager, not off the page. The versions served to visitors have been resized and recompressed by the platform, so saving them from the browser leaves you with photos that look soft the moment they are used at any reasonable size on the new site. Download the originals from the media manager while you still have access.
Blog posts need the same treatment as pages, with one extra step: record each post's publication date alongside its text. Dates matter for how the new site presents the archive and for keeping the addresses consistent, and they are not obvious once the content is sitting in a document with everything else.
If your site runs on a free Wix address rather than your own domain, there is an honest limitation to be aware of. Addresses on the platform's own subdomain cannot be forwarded to anywhere else once the account closes, because you do not control that subdomain. Whatever search visibility those addresses have built up does not transfer. That is not a reason to stay, but it is a reason to buy a domain today rather than at launch, so at least some of the intervening months build authority on an address you own. How to choose and buy a domain name →
Building and testing the replacement site
The new site gets built and finished on a private preview address while your Squarespace or Wix site stays live and paid for. There is never a window where visitors land on something half-built. The switch is a single moment at the end, and by the time it happens the new site has already been through everything below.
Here is what a typical six-week move looks like when the content audit is done up front. The parts that depend on you are marked separately, because those are the ones that move the launch date when they slip. How long a website build takes →
- My work
- Your work
- Critical path
Pre-launch test pass
- Every page from the audit exists. Walk the address list row by row against the preview site. A page that quietly did not get rebuilt is far harder to spot than a page that is visibly broken, and the audit list is the only thing that catches it.
- Forms actually deliver. Submit the contact form and confirm the message arrives in the inbox it is supposed to arrive in, including from a phone on mobile data rather than only from the desk it was built on.
- Search listings carried across. Each page has its own clickable headline and short summary, matching what you recorded in the audit unless you deliberately improved it. Nothing is telling Google to skip pages that should appear in search, which is the most common leftover from a preview build.
- Speed measured against the old site, not in isolation. Run a free speed test on both the current builder site and the preview, on a phone profile, and write both numbers down. The whole point of this move is that the platform runtime is gone, and you want proof of that on paper rather than a vague sense that it feels quicker. See the Core Web Vitals guide for what the numbers mean.
- Every forward tested. Last gate before the switch. Go through the forwarding map line by line against the preview and confirm each old address lands where the map says it should. A forward that loops or lands on the wrong page has to be caught here.
The full pre-launch sequence, including the checks that apply to any new site rather than only to a platform move, is worth running as well. The website launch checklist → Core Web Vitals explained →
The domain, the switch, and the cancellation order
This is the part where sequence matters more than skill. Every step below is easy on its own. Doing them in the wrong order is how sites go dark for a day.
-
Three weeks out
Start the domain move
If your domain is registered through Squarespace or Wix, unlock it in the platform's domain settings and request the transfer authorisation code. Start the transfer at the registrar you are moving to. Registrars hold transfers for roughly five to seven days by policy, and a domain registered or transferred within the last 60 days cannot move at all until that lock expires. This is the one step with a waiting period nobody can shorten, so it goes first.
-
Two days out
Shorten the lookup window
The internet caches where your domain points, often for a full day. Two days before the switch, change that setting so it refreshes every few minutes instead. It means the changeover reaches everyone in minutes rather than trickling through over a day, and it means an undo would take minutes too.
-
Launch morning
Certificate first, then the switch
The security certificate that puts the padlock in the browser bar has to be in place on the new server before the domain points at it, or visitors get a full-page warning during the changeover. Certificates are free and issue in minutes, so this is purely a sequencing point. With it in place, point the domain at the new server. The forwards go live at the same instant because they were built into the new server from the start.
-
Launch afternoon
Walk the live site
Every page, every form, every forward, on the real domain rather than the preview. Small differences between a preview environment and a live one occasionally surface something the preview never showed. Then submit the updated page map to Search Console so Google starts re-reading immediately instead of finding out on its own schedule.
-
Two weeks after
Then, and only then, cancel
Keep paying Squarespace or Wix through one more billing cycle after launch. It is the cheapest insurance in the project: a month of subscription against the risk of finding out in week three that a page nobody thought about was never copied. Once the new site has been live for a fortnight with clean search reporting, cancel the plan and, if the domain has not moved yet, move it now.
Where the domain ends up matters as much as the fact that it moved. It should sit at a registrar you control, in your name, with your email address on it, not in a developer's account and not bundled with whatever hosting you happen to use this year. What to retain when you own a website →
The first 30 days after launch
Launch day is the middle of the project, not the end. The month that follows is when Google re-reads everything, follows the forwards, and decides what your new addresses are worth. Watching it properly costs a few minutes a day and catches the problems while they are still cheap.
Check Search Console daily for the first two weeks. It reports pages Google could not load, dead ends, and forwarding problems. A new dead end means an address slipped past the map: something Google still remembers that the new server does not answer for. Fix each one the day it appears by adding the missing forward. A dead end fixed within a day keeps its ranking. One left alone for a week usually does not.
Expect the appearance numbers to wobble in the first week. Positions drift a few places either way while Google works through a changed site, and that settles. What is not normal is a single important page dropping sharply and staying down. When that happens, check that page's forward first, then compare the new page to the old one on the things that carry ranking: the headline, the main heading, and the body text. Nine times out of ten something got trimmed during the rebuild.
Watch your analytics for the same period, but read them carefully. Traffic numbers after a platform move look strange for a week simply because tracking has been reinstalled and the old platform's own reporting has stopped. Compare like for like against the same week last month rather than against yesterday. Website analytics 101 →
If your business depends on local search, re-check your Google Business Profile in week one. The website address on it needs updating if any of your addresses changed, and the profile is often the last place anyone remembers to look. Local SEO for small businesses →
After 30 days, set the domain's lookup window back to its normal schedule and take stock. Run the speed test again and compare it to the numbers you recorded before launch. That comparison is the clearest evidence you will get that the move was worth doing, and it is the thing people forget to capture. Site speed optimization → See build pricing →
Key takeaways
- Audit before you cancel. On Wix the live site is your only copy of your content. Capture every address, download every image at full size, and export your form submissions while the account is still open.
- The Squarespace export is partial. It carries standard pages, one blog, and simple images. Products, albums, index pages, events, and custom styling do not come out and have to be collected by hand.
- Wix has no export at all. Plan for a few hours of manual copying rather than looking for a download button that does not exist.
- The forwarding map is the whole game. Builder platforms invent address shapes a hand-built site would not use, so more addresses change than in a typical move. Every one of them needs a forward to a relevant page, never to the home page.
- Redirects set up inside the platform die with it. Anything in Squarespace's URL mappings or Wix's redirect manager stops working the moment your domain points elsewhere. Copy them into the map first.
- Start the domain transfer three weeks out. Five to seven days of holding, plus a 60-day lock if the domain was registered or moved recently. It is the only step with a waiting period you cannot shorten.
- Cancel last, not first. Pay for one more billing cycle after the new site is live. It is the cheapest insurance in the entire project.
Common questions
Will I lose my Google rankings if I move off Squarespace or Wix?
Not if you plan the move properly. Rankings survive on two things: every old web address forwarding automatically to its new equivalent, and the page content arriving intact on the other side. Do both and Google carries the ranking authority across. The reason platform moves have a bad reputation is that Squarespace and Wix both build their web addresses in shapes that a normal site does not use, so a rebuild that ignores those shapes ends up with dozens of dead ends on day one. That is a planning failure, not something the platform does to you on the way out. Write the forwarding map before anything gets built, test every row of it against a private preview copy, and the move is close to invisible in search.
Can I export my Squarespace site?
Partly. Squarespace has a built-in export that produces a single file in the same format WordPress uses. It carries your standard pages, one blog, your text, and your basic image blocks. It leaves behind product pages, album pages, index pages, event pages, any custom styling you added, and most of the specialty blocks. It also only exports one blog, so a site with two blogs loses the second one. Treat the export as a head start on the writing rather than a copy of the site. Everything it misses still comes across, it just gets pulled from the live pages by hand instead.
Can I export my Wix site?
No. Wix has no site export. There is no button that hands you your pages, your layout, or your design, and there is no way to take the site anywhere else as a working site. Your content still comes with you, it just comes the manual way: page by page from the live site, copying the text and downloading the images at full size. For a business site of five to fifteen pages that is a few hours of careful work. It is worth knowing this before you start, because Wix owners often assume there is an export sitting in a settings menu somewhere and plan the timeline around finding it.
What happens to my domain if it is registered through Squarespace or Wix?
It stays yours, but you have to move it, and moving it takes days rather than minutes. Unlock the domain in the platform's domain settings, request the transfer code, then start the transfer at whichever registrar you are moving to. Registrars are required to hold transfers for about five to seven days, and a domain that was registered or transferred within the last 60 days cannot move at all until that lock expires. Start this step early. It is the one part of the move with a waiting period nobody can shorten, and it is the reason a migration timeline sometimes slips by a week for no other reason.
When should I cancel my Squarespace or Wix subscription?
After the new site is live and answering on your domain, not before. Cancelling first takes the old site down, which takes your content reference down with it, and on Wix that content reference is the only copy you have. Keep paying for one more billing cycle. It is the cheapest insurance in the whole project: roughly the cost of one month against the risk of discovering three weeks later that a page you forgot to copy is gone for good. Once the new site has been live for a couple of weeks with clean search reporting, cancel the plan and, if you have not already, move the domain out.
What happens to my blog posts and their web addresses?
They come across, and their addresses usually change, which is exactly why the forwarding map matters. Squarespace blog posts normally sit under a blog folder, sometimes with the date built into the address. Wix blog posts sit under a post folder that the platform adds automatically. A rebuilt site rarely reproduces those shapes, and it should not have to. Every old post address gets a forward to its new home. Posts that have never had a single visit from search can be forwarded to the relevant category or service page instead of being rebuilt, but they still need a forward. Sending them all to the home page is the one shortcut that reliably loses ranking.
How long does it take and what does it cost?
For a service business site of five to fifteen pages with no store and no large blog archive, three to six weeks from kickoff to launch, and a cost in the same range as a new multi-page build at $2,800–$5,000. The content already exists, which saves time on the writing. Pulling it out of a platform that does not want to let go, mapping the addresses, and testing the forwards adds that time back. A single-page site is faster and lands in the $1,200–$2,200 range; a larger site with more pages sits closer to $5,500–$10,500. Stores, booking systems, and member areas are scoped separately because what is behind them varies enormously.
What about my online store, bookings, or member area?
Those get scoped on their own, because they are the parts of the platform that genuinely do something. A small catalogue rebuilds cleanly with a real payment processor behind it and usually ends up cheaper to run than the plan tier the platform required. Bookings can either connect to a scheduling tool you already use or get built directly into the site. Member areas are the most involved of the three and the one worth talking through before committing to a date. What you should not accept is a vague promise that it will all be handled. Ask for the specific plan for each feature, in writing, before the build starts.