Migrating From Wix or Squarespace: Get Your Content Out

On Wix and Squarespace, the live site is the export. Wix does not let a site move to another host and says blog posts cannot be exported to other platforms. Squarespace exports an XML file, but its own documentation excludes most page types and warns that image links still pointing at Squarespace stop working once the site is cancelled. So the working method is the one that does not depend on the platform: an AI agent reads the published pages while they are still up and writes them down. The exports fill in what they can.

This post is part of our guide to Migrating a Website With AI.

What Wix lets you take

Per Wix's support page on exporting or embedding your site elsewhere, you cannot use another host for a Wix site; it depends on Wix's own technology and has to stay on Wix. A domain bought elsewhere can still be connected to it, but there is no way to download the site and run it somewhere else.

The pieces that do export, each from its own panel:

CMS collections. Per the CMS export article, a collection exports to CSV, either the whole collection, a filtered set or the field names only. If your site's dynamic pages were built on collections, this is your structured content.
Store products. Per the Wix Stores export article, products export to CSV with their data, up to 5,000 rows per file, and digital products are not supported.
Blog posts. Per the Wix Blog feature request page, exporting blog posts to other platforms is not currently possible. The page collects votes for the feature.

So on Wix, pages and blog posts have one source: the published URL.

What Squarespace lets you take

Squarespace's export article describes a single XML file in WordPress format, and is clear that it is built for importing into WordPress. What it includes: layout pages, one blog with its posts and comments, text and image blocks, and gallery pages on version 7.0. What it excludes: album, cover, index, info, portfolio, calendar and store pages; content in page headers, footers and sidebars; audio, video and product blocks; additional blogs beyond the first; drafts, style settings and custom CSS.

Two more notes from the same article. Images are not reliably carried along: if the content keeps links that point at Squarespace, those links stop working once the Squarespace site is cancelled, so the images have to be downloaded and uploaded somewhere else. And products are a separate export: per the products CSV article, up to 10,000 products at a time, without featured images, variant images or alt text.

If the site is mostly a blog with plain pages, the Squarespace file is useful. If it was built with index pages, galleries and a store, as many Squarespace sites are, the file covers a minority of the content.

The method: read the live site first

Because the exports are partial on both platforms, start with the agent reading the published site, then use the exports to fill specific gaps. The general method is in Content Inventory With an AI Agent. The parts that are specific to Wix and Squarespace:

Get the URL list from the sitemap and Search Console. Both platforms publish a sitemap. Search Console has the URLs that earn traffic, which on these platforms often includes blog posts under a path you did not choose.
Fetch each page and extract the text, headings and images. Both platforms render a lot with JavaScript. Check a sample of the extracted pages by hand. If the agent gets back a thin page, it may need to fetch the rendered version rather than the raw HTML.
Download every image at its largest size. This is the step with a deadline. Once the old subscription ends, the image URLs stop working. Squarespace's export article warns about this directly; on Wix the images only ever existed on Wix's servers.
Record the SEO title and description of each page from the rendered page's head. There is no reliable export for them on either platform, and they are part of what ranked.
Export what the panels allow. Collections and products on Wix, the XML file and product CSV on Squarespace. Use them to check the agent's work and to recover structured fields, such as product options, that are hard to read from a page.

A starting instruction for the agent, which you can adapt:

Read every URL in urls.csv on the live site. For each one, write a Markdown
file named after the path with: the old URL, the page title, the meta
description, every heading and paragraph as written, and a list of images
with their alt text and largest available source URL. Download each image
into /images keeping its original file name. Do not rewrite or summarize
anything. If a page comes back with less than 100 words, flag it in
thin-pages.csv instead of guessing. Put pages you could not fetch in
failed.csv with the status code.

The instruction is long on purpose. Every sentence in it closes a way the extraction usually goes wrong: rewriting, summarizing, silently skipping, and losing the full-size image.

URLs on Wix and Squarespace

Both platforms assign URL patterns you partly control. Common cases that need redirect rows:

Wix blog posts live under /post/slug. If the new platform uses the same pattern, keep the slugs and skip the redirects.
Squarespace blog posts live under the blog page's slug, often /blog/slug, and sometimes with a date in the path depending on settings. Each one maps to its new post.
Squarespace category and tag views use query strings on the blog page. These are usually not worth redirecting.
Both platforms serve some pages at paths with a trailing slash and some without. Take paths from the crawl, not from the navigation.

How the rows become a redirect file is in Redirect Mapping From a CSV. One detail that matters here: Google's site move guidance asks for server-side redirects from each old URL to its new one. For that to work, the old domain has to point at the new site, which means the domain moves to the new host before the redirects can take effect. Keep the old subscription running until you have confirmed the images are downloaded and the redirects resolve.

The domain

On both platforms, a domain bought through the platform can be moved. The details are the platform's and the registrar's, and they change, so check the platform's current help pages for the domain transfer or disconnection steps before you plan the launch date. A domain registered elsewhere only needs its DNS records changed. Either way, do not cancel the old plan on the day you change DNS; the old site should keep answering until the new one is confirmed live on the domain.

There is also a choice people miss: you do not have to move the domain's registration at all. Many builders, Beste included, connect a domain from any registrar by DNS records alone. If the domain was bought through Wix or Squarespace, the simplest path can be to leave it registered there for now, point its records at the new host, and move the registration later when nothing else is changing.

Feature by feature: what replaces what

On Wix or Squarespace	On Beste	Notes
Pages and sections	Pages built from library sections, by hand, from a prompt or by an agent	Paths can be nested to match the old ones.
Blog	Built-in blog with authors, tags, summaries and BlogPosting structured data	Posts are recreated; the post importer is for WordPress only.
Store products	Products catalog with options and variants	The agent creates products from your CSV export over MCP. Beste does not process payments: checkout is a Stripe payment link, a quote, WhatsApp or Shopify.
Forms	Dynamic forms	Export old submissions from the old platform first.
Multilingual add-ons	Multi-language support	A URL per language with hreflang on linked pages.
Bookings, member areas, apps	Nothing equivalent	Keep them on their own platform or subdomain.
Site SEO settings	Meta title and description on every page, sitemap, OG images, structured data, `/llms.txt`	Generated on every publish.
Analytics and pixels	Integrations by ID	Pro, Team and Business.

What you lose, and should expect to lose

Design, animations, the template, the app integrations, booking widgets, member areas, and anything that was an app rather than content. The honest check is to walk the inventory and mark each row that was an app feature rather than a page. If most rows are apps, read When Not to Migrate before going further.

How this works in Beste

Beste cannot read your Wix or Squarespace site, and it has no importer for either; the agent does the reading. What Beste provides is a destination the agent can write to. Over the MCP server, an agent creates pages and posts with matching slugs from the folder it extracted, picks sections from the library for each page and fills them with the text as written. Every change waits in the draft until you publish, and reads never count toward a limit, so the agent can compare the draft with its extracted folder page by page. On Free, external agents get 150 edits a month, which is enough to try the method on a section of the site; a full migration usually needs Pro, which removes the limit and adds redirects and password protection, per the pricing page.

Products from the CSV exports are created in the products catalog by the agent, with options and variants, and each variant can have its own price, stock and photo. Every page and post has a meta title and description field. The domain connects from any registrar on every plan by copying two records, with the certificate issued and renewed for you, described on the custom domain page. Redirects for the paths that changed are imported from a CSV on Pro, with a preview of matched, duplicate and unmatched rows before anything is saved. If you want the new site on the real domain before anyone sees it, password protection on Pro covers every page until you switch it off.