Squarespace's XML export is a partial content file in WordPress format, not a backup of the whole site, and it does not commit you to moving to WordPress. Products, orders and membership orders come out through separate reports, and none of those reports carries billing or logins across. So the sensible alternative is the simplest destination that runs your real workflow, which sometimes means staying exactly where you are. Below is a decision table, a fair look at Wix, Webflow, Framer, Shopify, WordPress and Astro, a clear account of what each Squarespace export contains, and a validation checklist to finish before you cancel anything.
The short answer, and a decision table
Pick by the job, not by the brand. You might want a different hosted editing experience, more visual control, a store where checkout drives every decision, or a content site that a developer maintains. Each one points somewhere different. There is no unqualified winner here, and anyone who names one without asking what you publish and sell is guessing.
Say this early too: a redesign, a template change or a tidy-up of your navigation and page structure inside Squarespace is sometimes the whole answer. If your editors are happy and your payments and forms work, the problem may be the design, not the platform.
| Present constraint | Shortlist | Editing model | Operational responsibility | Migration check |
|---|---|---|---|---|
| Site works, design or content is tired | Stay on Squarespace | Same hosted editor | Squarespace runs hosting and updates | List what the redesign needs; confirm no feature is missing |
| Want another hosted builder | Wix | Hosted visual editor | Wix hosts; site must run on Wix servers | Rebuild one page of each type and connect the domain |
| Need finer visual and CMS control | Webflow | Visual designer plus CMS collections | Vendor hosting; you manage structure | Map content fields and test editor permissions |
| Design-led marketing site, lighter blog | Framer | Visual canvas plus CMS | Vendor hosting; you manage redirects and plan | Import a sample of posts and check media |
| Store operations drive the decision | Shopify | Commerce admin plus themes | Vendor-run checkout; you manage apps and data | Import a product sample and run a full test order |
| Want an open platform and a big plugin catalogue | WordPress | Block editor plus plugins | You or a host manage updates, backups, security | Stage a copy and run a plugin update cycle |
| Structured content and custom requirements | Astro with a headless CMS | CMS interface; developers own the front end | Developers own build, hosting and releases | Check an editor can publish without a developer |
If you want a wider list than this, there is a broader CMS shortlist on this site.
Decide what you are replacing
"Replace Squarespace" is really seven separate jobs, and most migrations go wrong because people treat them as one.
- Design: layout, typography, spacing, custom CSS.
- Content model: pages, blog posts, categories, galleries, the way things relate.
- Editorial workflow: who writes, who approves, how a page goes live.
- Ecommerce: products, checkout, tax, shipping, fulfilment.
- Scheduling: bookings and appointments. (Squarespace's help site notes that Squarespace Scheduling is now Acuity Scheduling, so check which product you actually pay for.)
- Member access: logins, gated pages, paid plans.
- Integrations: forms, email lists, analytics, anything connected by embed.
Now look at the dependencies that sit beside the site. Your domain is one. Your email is another. Your website plan is a third, and each connected service is a fourth. Squarespace's own guidance on moving a site in recommends contacting your email provider and backing up emails, contacts and settings before a domain transfer, which tells you email is not the same thing as the domain. And a domain transfer away needs an auth code sent from no-reply@squarespace.com, which Squarespace says to troubleshoot if it has not arrived within 24 hours, per its transfer-away steps.
Moving a domain does not move a site, and downloading an XML file does not replace one. Write the seven jobs down, mark which ones your current setup does well, and only then shop.
Practical alternatives, compared by job
These are assessments of fit, not rankings. Each gets a tradeoff and one test you can run yourself.
Wix
Fit: you want to try another hosted builder with a similar do-it-in-the-browser feel. Tradeoff: Wix says its sites must be hosted and operated on Wix's servers, because its SaaS architecture does not support external hosting. Content you build belongs to you, but the site itself does not leave. Connecting a domain also requires a plan upgrade. So you are exchanging one hosted dependency for another, which is fine as long as you know it. Test: rebuild one page of each type (a service page, a blog post, a contact form) and connect your domain, before you commit.
Webflow and Framer
Fit: you want more visual control and a content system built around collections. Webflow publishes a CMS overview and Framer has its own CMS. Tradeoff: you gain layout freedom and take on more responsibility for structure. Fields, collection design and redirects become your job. Test: import a sample of posts and read the result with an editor's eyes.
Framer is a useful example because a third-party marketplace plugin, Squarespace Import by Adam Kansky, documents the path. You export from Settings, Advanced, Import & Export, WordPress, which produces an .xml file, and drop that into the plugin. The plugin says posts arrive in Framer CMS with title, date, body, excerpt, a cover image, and authors, tags and categories as linked collections, with drafts staying drafts. It also says it copies in-post images so nothing breaks after cancellation. Redirects for the date-based post URLs need a Framer plan that includes them.
Note what that covers: a blog. It says nothing about your pages, your store or your styling. It is a plugin vendor's description, so check the result on your own posts.
Shopify
Fit: store operations and checkout drive the choice, and the website is secondary. Tradeoff: product data moves with effort, and Squarespace exports products, customers and orders separately, as a Shopify migration vendor, LitExtension, describes. Page content is a separate job again. Test: import a small product sample, then place and fulfil a test order end to end. If you later need a custom storefront on top of a commerce engine, that split has its own trade-offs, covered in our note on headless ecommerce, but only reach for it when a real store requirement demands it.
WordPress
Fit: you are prepared to manage hosting and the plugin lifecycle, and you value an open platform with a very large ecosystem. The project lists its core features openly. Tradeoff: freedom comes with maintenance. Updates, backups, security and plugin compatibility belong to you or your host. It is not automatically cheaper or better than a hosted builder, just differently weighted. Test: build a staging copy, run a full update cycle, and see whether the people who edit the site are comfortable. Our WordPress alternatives piece is useful reading if you are on the fence the other way.
Astro with a headless CMS
Fit: content delivery and custom requirements justify development support. Tradeoff: Astro is a web framework, not a hosted builder. It does not automatically include an editor, a commerce engine or memberships, so each of those is something you choose and wire in. Test: can an editor create, preview and publish a page without opening a code editor? If not, the content model is not finished. The editorial side is covered in our headless CMS development notes.
What the Squarespace XML export actually contains
Squarespace's export article, updated 9 October 2026, documents the XML route as a partial content export. It covers selected layout, text and image content and one blog page. It does not cover every page type, and it lists exclusions: style settings, custom CSS and store pages do not export this way. The file is in WordPress format, but the article says explicitly that the destination does not need to be WordPress.
So read the XML as a content file that other tools can import. It is not a site backup, and it is not a design export. Your template, your CSS tweaks and your store pages stay behind.
There is one more trap. A file that references an image is not proof that you hold a copy of that image. Before you cancel anything:
- Open the destination site in a private window and check that every image loads.
- Confirm media files are copied into the new platform or your own storage, not hotlinked from the old site.
- Cut a page's old image URL from your thinking: if the new page still points at it, the copy is not durable.
- Only then consider the old plan cancellable.
Commerce and memberships need their own plan
Store and member data does not ride along with the site XML. Squarespace documents separate exports for each, and each one has limits.
| Item | What it is | What still needs separate validation |
|---|---|---|
| Site XML | Partial content file in WordPress format | Styles, custom CSS, store pages, media copies, other page types |
| Product CSV | Documented for physical and service products | Omitted details, digital products, product-page presentation |
| Order CSV | Reporting export from the Orders panel | Native import, fulfilment flow, customer communications |
| Membership-order CSV | Records of membership orders | Passwords, entitlements, stored payment methods, recurring billing |
| Functionality | Forms, scheduling, analytics, embeds | Rebuild and test each one in the destination |
On products: Squarespace's product CSV article, updated 10 June 2026, documents a physical and service product workflow and lists omitted details, including additional product information, reviews, featured images, image alt text and variant images. Don't extrapolate the physical-product workflow to digital or subscription products. Product data and product-page presentation are separate jobs.
On orders: the order export is a reporting tool for reviewing sales, bookkeeping or managing orders outside Squarespace. You can filter by status, date range and product. Specific-product exports include form responses unless you untick them, and only active products on enabled store pages appear in that search. The existence of a report does not mean another platform can import it natively, or that your operations carry on unbroken.
On memberships: Squarespace's member management article, updated 5 October 2026, documents membership-order CSVs, and its migration guidance concerns members coming into Squarespace. Don't flip that into a universal rule for leaving. A membership-order report holds records. It does not show that passwords, entitlement rules, stored payment methods or recurring billing arrangements can move to your destination. Ask the payment provider, ask the destination vendor, and work out what customers must do themselves (reset a password, re-enter a card, accept new terms). Don't promise continuity until you have those answers in writing.
When staying put is the better move
A working brochure site with satisfied editors and supported workflows often needs better pages, not a new stack. That is a serious option, not a consolation prize.
Weigh the burden realistically. Replacing payments, forms, scheduling, analytics and the habits of your staff is real work, and it should be justified by the requirement that triggered the move. Ask yourself:
- What exactly broke or limited us, and can a template, layout or content change fix it?
- Which workflows are quietly working today that the new platform would make us rebuild?
- Who edits the site, and would they be slower or faster on the alternative?
- Does the new platform meet the requirement natively, or does it need a paid add-on or a developer?
- If the move took twice as long as planned, what would we stop being able to do?
If the answers show a design problem, fix the design. If they show a hard limit (a checkout you cannot customise, a content model you cannot structure), then move, and use the table above to choose where. I won't put a price band on any of it. Costs depend on your catalogue, your members and your tooling, and a guessed figure would be worse than none.
Migration validation checklist
Work through this in order, and keep the source site live until every line passes.
- Inventory: every page, blog, product, digital item, member plan, schedule, form, download and connected service.
- Sample first: run a small export and import before committing to the full move.
- Reconcile: compare counts and field mapping between source and destination.
- URLs: preserve them where you can, and set permanent redirects where you cannot.
- On-page data: check titles, metadata, canonicals, structured data and media.
- Behaviour: test mobile editing, keyboard navigation, form delivery, checkout, fulfilment, consent banners, analytics, customer access and any billing flow.
- Agree the endgame: a final data sync, customer communications, an operational rollback and a monitoring plan.
- Retain the source until the data and workflows you need have been checked.
None of this guarantees rankings or conversions. It reduces the chance of silent breakage, which is a different and more honest goal.
Bring your Squarespace URL and a list of products, memberships and connected services to plan the move around what must keep working.
FAQ
Does the Squarespace export include my whole site?
No. The XML route is a partial content export. Style settings, custom CSS and store pages are among the items Squarespace lists as not exported this way, and it covers one blog page, not every page type. Keep the old site until you have rebuilt and checked everything the file leaves out.
Does the XML file force me onto WordPress?
No. The file is in WordPress format, but Squarespace's article says the destination need not be WordPress. Other tools can read it, as the Framer plugin above does for blog posts.
Does store data export separately?
Yes. Products, orders and membership orders come out through separate exports, and customers separately again according to the migration vendor cited above. The product CSV is documented for physical and service products with a list of omitted details, so check the omissions against your catalogue.
What must I check for memberships?
The membership-order CSV gives you records. Before promising anything, confirm with your payment provider and destination how logins, access rules, stored payment methods and recurring billing will work, and what members will have to do themselves.
The sharpest caveat is that every Squarespace export is a record, not a running system: neither the XML file, the product CSV nor the order and membership reports carries your design, your billing or your customers' access with it. Choose the simplest destination that runs your real workflow, and if that is Squarespace, stay.