Squarespace to WooCommerce: What Actually Transfers

Squarespace's commerce tools are good enough to launch on and rigid enough to outgrow. The usual trigger is not a missing feature but an accumulation: transaction fees on the lower plans, a checkout you cannot restructure, subscriptions that do not behave the way your business does, and a price that has gone up more than once while your options stayed the same.

WooCommerce is the common destination because it inverts every one of those constraints. It is also the migration where people most often lose data they assumed was portable. Here is what actually moves.

What the export really contains#

Squarespace gives you two separate exports, and neither one is the site.

The site export is a WordPress-format XML file. It carries pages, blog posts with their publication dates and authors, and text content. It is genuinely useful and it is genuinely partial.

The product export is a CSV, generated separately from your commerce panel. It carries the catalog as rows: titles, descriptions, SKUs, prices, variants, stock counts, categories and tags.

Everything else is rebuild work. That is not a criticism of Squarespace. It is what a closed rendering system means. Your pages are not stored as portable documents anywhere; they are stored as instructions to Squarespace's renderer, and no exporter can turn those back into HTML someone else can use.

The image trap#

This is the mistake that cannot be undone, so it goes first.

Your product CSV does not contain images. It contains links to images, hosted on Squarespace's CDN. The same is true of images inside the site XML. As long as your Squarespace account is live, those links resolve and any importer can fetch them. The moment your subscription lapses, they stop resolving, and a CSV full of dead image URLs is not a catalogue you can rebuild from.

So the order of operations is not negotiable:

1. Export the product CSV and the site XML.
2. Run the import into WooCommerce while Squarespace is still paid up, so images are pulled into your own media library.
3. Confirm images are served from your new domain, not still hot-linked to Squarespace.
4. Only then cancel.

Point 3 catches people. Several importers will happily leave the image src pointing at Squarespace's CDN, the site looks perfect, and it breaks weeks later when the subscription ends. Spot-check a handful of product images in the page source and confirm the URLs are yours.

Reshaping the product CSV#

WooCommerce ships with a CSV importer that is genuinely capable, but it expects a different shape from what Squarespace hands you. Three differences do most of the damage.

Variants are rows, not products. Squarespace exports one row per variant, with the parent product's details repeated or blank. WooCommerce wants a parent "variable product" row followed by "variation" rows that reference it. Import the file raw and you get either hundreds of separate simple products, or a catalogue where only the first variant of each product survives.

Options are positional. Squarespace stores variant options as generic option-name and option-value pairs. WooCommerce wants named attributes. That mapping is mechanical, but it has to be done deliberately, and it is where "Size / Large" quietly becomes "Colour / Large" if the columns shift for products with different option counts.

Descriptions carry Squarespace markup. Product descriptions come across as HTML that may reference Squarespace's own classes and block structure. It renders, but it renders as unstyled remnants inside your new theme. Cleaning this is tedious rather than hard, and skipping it is the difference between a store that looks migrated and one that looks abandoned.

For catalogues under about 50 products, reshaping by hand in a spreadsheet is genuinely faster than configuring an import tool. Above that, script it or use a purpose-built importer, but read the result before you trust it.

What does not come out at all#

Customer accounts and password hashes. Customers will need to re-register. You can import customer records as WooCommerce users, but everyone resets their password. Say so in your launch email rather than letting people discover it at checkout.

Order history. Squarespace exports orders as a CSV for your records, and that file is fine for accounting. Turning it into native WooCommerce orders is a separate import that most stores decide is not worth it. Keep the CSV, keep read-only access to your Squarespace account for as long as you can, and move forward.

Form submissions. Every enquiry sitting in your Squarespace form storage is invisible to the export. Download them before you cancel or they are gone.

Subscriptions and recurring payments. These do not migrate. Recurring billing is a relationship between your customer, your payment processor and the platform. Moving means re-establishing subscriptions on the new stack, which is a customer-communication project as much as a technical one. If a meaningful share of your revenue is recurring, plan this first, not last.

The URLs that decide whether rankings survive#

Squarespace's address patterns are distinctive, which is good news: distinctive patterns map cleanly.

Squarespace pattern	WooCommerce destination
/shop/p/product-slug	/product/product-slug
/store/p/product-slug	/product/product-slug
/store or /shop	/shop
/blog/2024/3/14/post-title	/blog/post-title
/about-1, /new-page	/about, real slug
/config/...	home (never a content page)

The dated blog paths matter more than they look. Squarespace stamps the publish date into every post URL. WooCommerce sites conventionally do not, and nobody wants to keep /blog/2019/11/2/ in their addresses forever. But those dated URLs are the ones Google has indexed and other sites have linked to. Every one needs a 301 to its clean equivalent, or you lose the accumulated authority of your entire archive in a single afternoon.

That is a mechanical transformation (strip the date segment, keep the slug) which means it can be generated rather than typed. Our redirect map generator does exactly this transformation for Squarespace paths, and outputs .htaccess, nginx or a WordPress Redirection CSV.

The template-default URLs are the other easy win. Squarespace appends -1 when a page name collides with an existing one, which is why so many sites ship with /about-1 in production. Map those to real slugs and redirect the old ones.

A realistic timeline#

For a store of a few hundred products, expect 10 to 14 days, and expect the split to surprise you:

• Days 1–2, inventory. Crawl the live site, export everything, list every URL, pull the form submissions, download the order CSV. Nothing is built yet and this is the phase that decides whether the rest goes smoothly.
• Days 3–7, rebuild. Theme, product template, catalogue import, category structure, payment and shipping configuration.
• Days 7–9, reshaping. The CSV work above, plus description cleanup and image verification.
• Days 9–11, review. You looking at staging and asking for changes.
• Day 12, cutover. DNS at a quiet hour, redirects live at the same moment.
• Days 12–14 and beyond, verification. Re-crawl the old URL list, confirm every redirect resolves, resubmit sitemaps, watch Search Console.

The rebuild is not the long pole. The inventory and the verification are, and they are the two phases that get cut when someone quotes you a weekend.

The honest case against#

Some Squarespace stores should stay put.

If you sell fewer than a dozen products, you do not have a plugin ecosystem problem, and nothing about your workflow is fighting the platform, WooCommerce will hand you responsibilities (hosting, updates, security, backups) in exchange for flexibility you may not use. That trade is only worth it when the flexibility is the point.

The clearer signals to move are structural: transaction fees that now exceed what hosting would cost, a checkout you need to change and cannot, a catalogue outgrowing what the admin can comfortably manage, or a genuine need to own the stack. If none of those are true, the better answer is to stay and revisit in a year.

And if you are moving mainly for speed and ownership rather than commerce features specifically, look at WordPress without WooCommerce or a custom build before defaulting to a full store stack. Carrying commerce infrastructure you do not need is its own kind of overhead.

What we would do#

We run this migration as a fixed-price job: full URL inventory before anything moves, catalogue reshaping done properly rather than dumped through an importer, images pulled into your own media library and verified, a complete 301 map covering the dated blog paths and the /shop/p/ patterns, and Search Console monitored afterwards.

If you want to see what your own URL structure would look like mapped, the redirect generator is free and runs entirely in your browser. If you would rather hand the whole thing over, tell us the URL and you will get a fixed number back.