Squarespace export code: an .xml file, and what it leaves behind.
Squarespace does have an export. It produces one file, shaped for a WordPress import. Before you promise a client their code, read what that file carries and what the help centre says stays on the platform.
One .xml file. Content, not code.
The help centre’s article on exporting your site describes an .xml file “primarily set up to export the content that will import to your WordPress site”. Layout pages export. One blog page exports with its posts. Text blocks and image blocks export. Then comes the longer list: store, calendar, portfolio, index and cover pages do not, nor do drafts, style settings or custom CSS, because “many features rely on our platform’s JavaScript and CSS”.
Images and uploaded videos have no bulk export; the Asset library lets you download images one at a time. Form submissions export to a .csv per form block, every field, one submission per row, uploaded files left out but linked. Products and contacts export to .csv. And the file cannot go back in: the article says content from one Squarespace site cannot be imported into another.
- HTML and CSS of your pages
- Not in the .xml. Styles and custom CSS stayFAIL
- Images and files
- One at a time, from the Asset library
- Form submissions
- CSV per form block, without the uploadsPASS
- Blog posts
- One blog page and its posts, in the .xml
- Store, portfolio, index and cover pages
- Not exportedFAIL
- The editor and templates
- Not exported. Developer Mode is 7.0 onlyFAIL
- Your domain
- Transfer away; cancel the site separatelyPASS
Read from Squarespace’s help centre on 3 September 2026. The links are at the foot of the page.
What you actually send the client. An .xml, and an explanation.
The email is polite. They would like their website files. On Squarespace you send an .xml file built for a WordPress importer, a folder of images you downloaded one at a time, a .csv per form, and a note about the pages that did not come along: the store, the events calendar, the portfolio, the index pages and the cover page. The design comes as a description.
Then the client asks what to do with an .xml file. The truthful answer is “import it into WordPress”, which nobody was proposing. What they own, in practice, is their words and their form records. What they paid for, month after month, was the arrangement of them. The same request lands differently on the other two platforms: Wix has no site export at all, and Webflow hands over a ZIP with the CMS left behind.
The CODES test names the two letters this fails. Ownership asks whether you can leave with what you built. Data asks where the records live — and on Squarespace, form submissions live wherever the block was told to store them: an inbox, a spreadsheet in Google Drive, or the Contacts panel, which the help centre says is one of only two options that keep submissions inside the site.
An export built for a competitor’s importer is not a handover.
Rebuild it as a folder of files. Then the export is a copy command.
The owned stack is a folder of static files on hosting with a free tier, behind a strict content-security policy, making zero third-party requests at runtime. The site and the export are the same object. Hand the folder to the client and they have every page, every style and every image, in a form any host can serve and no plan change can withdraw.
Keep the domain. Squarespace’s transfer-away article walks through switching the domain lock off, requesting the transfer code, and waiting up to fifteen days, with sixty-day locks after a purchase or a transfer in, and a further lock after a change to the registrant contact. It also says the transfer does not cancel the site subscription — you do that separately, after the domain has moved, so the old site stays up while the new one is built.
Move the content while the old site is live. Pages and posts come out of the .xml as structured text; products and contacts come out as .csv; form records come out per block. Images come out one at a time, so budget the afternoon. The pages the export skips are rebuilt from the live site.
Then run the release gate before anything ships. A banned phrase, a dead link, a claim nobody can source: the build fails and nothing goes out. The CODES test tells you where to build; the gate keeps what you built worth handing over.
The next export the client asks for is a copy of a folder.
Every claim above, dated and linked.
Sources
- Exporting your site: what the .xml carries and what it does notsupport.squarespace.comAccessed 3 September 2026
- No bulk export of images or uploaded videos; individual images from the Asset library; products and contacts to .csvsupport.squarespace.comAccessed 3 September 2026
- Form blocks: export submissions to a .csv from Storage, all fields, one submission per row; uploaded files not includedsupport.squarespace.comAccessed 3 September 2026
- Form storage options; mailing lists and the Contacts panel are the only options that store submissions within the sitesupport.squarespace.comAccessed 3 September 2026
- Transferring a domain away: the domain lock, the transfer code, up to fifteen days, sixty-day locks; the site subscription is not cancelled by the transfersupport.squarespace.comAccessed 3 September 2026
- Developer Platform FAQ: available only on version 7.0; cannot create or modify a 7.1 sitesupport.squarespace.comAccessed 3 September 2026
Read the sharpest chapter first. It costs an email.
We’ll send the build-gate chapter in full: the checks, the code, and the reasoning. Read it. If it doesn’t change how you think about shipping client sites, you’ve lost ten minutes and kept a working release gate.
That did not send. Check the address and try again.