On this page
Squarespace gave you a good looking site with almost no effort. Then you hit the wall: a layout it will not do, a feature it does not offer, or simply the realisation that you are paying every month for the privilege of staying online in someone else’s box. So you start looking at what it would take to move.
Here is the honest guide. Leaving Squarespace is a little more work than leaving an open CMS, because it is a closed builder that does not fully hand you your content. But it is very doable, and the payoff is a site you actually own.
What “outgrowing the builder” really means
Squarespace optimises for the common case: pretty, fast to launch, no code. The moment you fall outside it (an unusual page type, a content structure the blocks do not model, an integration that is not a Squarespace block) you are fighting the tool rather than using it.
A modern site built on your own code is the opposite trade. Someone has to build it, whether that is a developer, an AI agent or a service like ours. In return there is essentially nothing you cannot change later. Concretely, what you gain:
- Real control. The design is code in a repository you own. Any layout, any behaviour, no template ceiling.
- Your content is yours. Pages and posts live as plain, portable files or database rows, not locked inside a builder’s proprietary format.
- Predictable cost. No mandatory subscription just to keep your own site online. Static pages on a modern host are cheap or free at typical small business traffic.
Where does it go? Cloudflare is the usual answer these days, because the hosting is fast, global and priced for small sites. On top of that you can run a plain static site, a familiar CMS behind it, or one of the newer serverless options such as EmDash, which is Cloudflare’s own open source CMS (MIT licensed, Astro on Workers, content in D1 and media in R2). Cloudflare describes it as a spiritual successor to WordPress. It is one destination among several, not the only one, and it is worth knowing it exists before you decide.
Step 1: Export what Squarespace lets you
Squarespace has a partial export, and it is worth knowing exactly what it does and does not give you.
Go to Settings, then Import & Export, then Export. What you get is a WordPress format XML file. That is genuinely useful: Squarespace exports in the same WXR format WordPress uses, so it carries your blog posts, your pages and the basic structure, and almost any tool or developer can read it.
But read the fine print. The export typically covers one blog only, and it leaves out product pages (Squarespace Commerce), album pages, event collections, several block types, and all of your styling and design. Plan for the export to cover your blog and basic pages, and for the rest to be rescued by hand.
One more catch: because it is WXR, the page bodies come out as HTML, and Squarespace blocks (galleries, summary blocks, buttons) arrive as markup that only ever made sense inside Squarespace. Those need cleaning up rather than copying across.
Step 2: Rescue what the export missed
For anything the export skipped (commerce pages, event and album collections, odd custom pages) the fallback is to work from your live site. Your sitemap at /sitemap.xml lists every public URL, and each of those pages can be saved and converted. It is the same content rescue approach as leaving Wix, with the same caveat: saved page HTML is raw material for conversion, not something you keep as is.
This part is tedious but not clever, and it is exactly the kind of work a developer, or we, would handle for you. If you are doing it yourself, the practical version is: open the sitemap, list every page worth keeping, and copy the real content (words, images, links) into a plain document per page. Nobody needs the old markup.
For product data, if you ran Squarespace Commerce, check Settings, then Import & Export for the products CSV export. That one does exist, and it gives you clean product data with prices, SKUs and variants.
Step 3: Turn it into clean content
Whatever the destination, the goal is the same: content stored as structured text rather than builder specific HTML. Headings are headings, images are images, and nothing carries a Squarespace class name or an inline style.
That matters more than it sounds. Content in a clean, structured form can be re-themed forever, moved between systems, and read by search engines and AI tools without a fight. Content that is a tangle of old builder markup has to be untangled all over again the next time you change anything.
For a small site, redoing a dozen pages by hand in the new system is often faster and cleaner than any automation. For a real blog with hundreds of posts, the bulk gets converted automatically and the odd ones get fixed by hand. Either way it is the single biggest chunk of the work, and it is worth budgeting for.
Step 4: Move the images
Your images currently live on Squarespace’s CDN and stop being yours the day you cancel. Download them all, then upload them to your new host’s storage (on Cloudflare that is R2, which has no egress fees, so serving pictures does not cost you per view) and update every reference. Keep a map of old address to new address as you go, because that is what makes the next step possible.
Step 5: Rebuild the design, which is the upside
Your Squarespace template does not transfer, and that is the whole point of leaving. The new site is built as code you control. For most portfolio, business and blog sites that is a clean, quick job, and the result loads faster than a Squarespace page booting its runtime. If you like the current look, it can be reproduced closely as a starting point.
Squarespace built-ins need new homes: contact forms, SEO settings, galleries and pop-ups all have modern equivalents, but they are decisions to make deliberately rather than things that come along automatically. If you ran Squarespace Commerce, treat the shop as its own project. Serverless options are still thin on ecommerce (EmDash, for instance, has no official ecommerce plugin yet), so if the store is the business, settle that path before you commit rather than discovering the gap afterwards.
Do not skip: preserve your URLs
Squarespace has specific URL patterns (/blog/post-slug, collection paths) and those addresses carry your search rankings and every link anyone has ever made to you. Before you switch anything, get a full list of the old URLs from the sitemap. Keep the paths you can, and for the ones that change, set up permanent redirects (301s) from old address to new. Skipping this is the single most common way a migration quietly destroys search traffic, and it is very hard to fix months later.
The honest trade-offs
Moving off Squarespace means trading a no-code builder for a site somebody has to build and maintain. If “nobody ever touches code, ever” is a hard requirement and the builder still does everything you need, stay. There is no shame in it.
But if you have outgrown it and you want real control, portable content and no lock-in, a modern hosted site is a strong landing spot. If you are still comparing destinations, the best WordPress alternatives roundup puts the current options side by side, EmDash vs WordPress covers the serverless end of the field, and the Wix guide covers the same builder escape from the other side.
At 2emdash we do this for people who would rather not do it themselves: we rebuild your existing site on Cloudflare and hand you a simple panel to run it from. We’re an independent service, not affiliated with Cloudflare or the EmDash project.