What a Squarespace export actually contains

The word "export" does a lot of damage here. It sounds like the site comes out in a box and goes into another one. What actually comes out is a text file, and knowing exactly what is in it changes how you scope the move.

Squarespace's export produces a WordPress XML file. Not an archive, not a folder of assets: one XML document in a format designed for a different platform, which is the first clue about how much of your site is in it.

What the XML actually holds

Three things, in useful shape.

Your pages, as text. The words on them, and the basic block structure that held the words. Titles, body copy, headings, the content of text blocks.

One blog page. Not your blogs. One. If the site runs a blog and a news section and a case study feed, the export carries whichever single blog page you selected, and the others need doing again. This is documented behavior and it is the detail that surprises people most, usually after they have already switched the old site off.

Image references. Not the images. The XML points at the files where they live, on Squarespace's own domain.

Everything that stays behind

The list is longer than the one above, which is the point of writing this down.

</Figure>

Two of those are worth a sentence each because they are the ones that turn into problems rather than tasks.

Images are referenced, not included. If the Squarespace subscription lapses before the assets are pulled down, the references point at nothing and the pictures are gone. Download them early, as a deliberate step, before anybody starts counting days on the old plan.

Form submissions are not content. Everyone remembers the forms. Almost nobody remembers what was already in them. If a contact form has been quietly collecting leads into Squarespace storage rather than a CRM, export that first.

Why the page count misleads

Here is the practical consequence, and it is the reason this post exists.

Somebody looks at the export, counts what it contains, and scopes the rebuild from that number. But the export is weighted toward the content that is easy to represent as text, which means it systematically undercounts exactly the pages that take the longest to rebuild. An index page holding twelve sections appears in the XML as almost nothing. A gallery is a handful of references. The homepage, usually the most designed page on the site, may come out as four paragraphs.

The way to scope it properly is boring: walk the live site page by page, list the page types, and decide for each one whether it is being rebuilt as-is, consolidated into something else, or dropped. Then use the export to avoid retyping the words.

What the export does save you

Having said all that, it is worth having.

It saves the retyping, which on a site with fifty blog posts is genuinely a few days. It gives you dates and slugs in a machine-readable form, which is the start of the redirect map and the only place some of those old URLs are written down in one list. And it is a snapshot: a file that still exists after the subscription ends, which is not true of anything else about the site.

Treat it as one input. The Squarespace to Webflow page covers what the rebuild actually involves, and what actually breaks in a migration covers the failures that happen after launch rather than during it.