Squarespace to WordPress — the one route with a real file

Squarespace to WordPress is the rare website-builder migration that deserves the word migration, and it works in both directions — WordPress to Squarespace has its own importer and its own set of traps. Squarespace writes a WordPress-format .xml file — a WXR, in WordPress’s own vocabulary — and WordPress has read that format natively for the better part of two decades. There is an official WordPress guide to doing exactly this. Nothing else on this site has that.

What it does not mean is that your site comes across. The file is narrow, and knowing its edges in advance turns a frustrating weekend into a predictable one.

What is actually inside the export file

Squarespace documents the contents of its .xml export precisely, and it is worth reading the list rather than assuming. The file carries layout pages; one blog page, including all of its posts and up to a thousand comments per post; text blocks; image blocks; and the text content of embed and Instagram blocks with minimal structure. On version 7.0 it also carries gallery pages, including York project pages.

Everything else stays. Squarespace lists the exclusions itself: other page types — albums, covers, indexes, info pages, calendars, portfolios and stores — plus content sitting in page-specific headers, footers and sidebars, any blog page beyond the first, dropdowns, audio blocks, product blocks, video blocks, drafts, style settings and custom CSS.

Two consequences of that list are worth stating before you start. If you run two blogs, pick which one the file carries and plan to move the other by hand. If you sell anything, the store is not in the file and never was — products are a separate .csv export.

Where WordPress is going to live

There are two WordPresses and the import works differently on each, so decide this before you export.

[WordPress.com](/go/wordpress) is the hosted service. It lists Squarespace by name among the platforms it imports from, which makes it the shortest path — you upload the file to a running site and the platform handles the rest. It is also the more constrained option: the plan you are on determines what you can install and what you can change.

Self-hosted WordPress is the software on a server you rent. You install the WordPress Importer plugin from Tools, Import, and upload the file there. This is the route that gives you full control over permalinks, which matters enormously for the redirect step later. If you are going this way you need hosting — Hostinger is one of the cheaper places people land — and the practical constraint is not price but PHP configuration, as the import step below explains.

Either way, set your permalink structure before you import, not after. Changing it afterwards moves every URL you have just created and invalidates a redirect map you have not written yet.

Running the export

In Squarespace, open Settings, then Import & Export Content, and choose the WordPress option. Squarespace generates the .xml and offers it as a download. It is a text file; it will be small, because it contains no images.

If you have more than one blog page, this is the moment the single-blog limit bites. Export, then open the file in a text editor and confirm which blog came. It is far better to discover that now than after the import.

Importing it into WordPress

On the WordPress side, go to Tools, then Import, and install and run the WordPress Importer. Upload the .xml and the importer will ask you two things.

First, how to assign authors — you can map the old author to an existing user or create a new one. Second, whether to download and import file attachments. Tick that box.

Then the part that nobody warns you about until it has already gone wrong: the importer fetches your images from the live Squarespace site. The official WordPress guidance is explicit that the original site needs to be publicly accessible for the attachments to download. If you have already cancelled Squarespace, taken the site private, or moved the domain away, the importer has nowhere to fetch from and you get posts full of broken images. Import while the old site is still up and still answering on its original address.

Two failure modes to expect on self-hosted installs, both of them server configuration rather than anything you did wrong. A file larger than your host’s upload limit will be rejected outright — hosts will usually raise it on request. A large import can also exhaust PHP’s memory limit mid-run, which produces a partial import. If that happens, do not simply re-run it on top; check what landed, remove the duplicates, and either raise the limit or split the file.

The images, properly

Squarespace states that it is not possible to export images or uploaded videos from your site in bulk. The importer’s attachment fetch is therefore doing real work, and it is worth verifying rather than trusting.

After the import, open half a dozen posts and check that the images are being served from your new domain’s media library rather than still being loaded from a Squarespace address. Anything still pointing at the old host will break the day you cancel. A search-and-replace across the database, or a media-import plugin, is the usual fix for stragglers.

Uploaded video is not in the file at all. If you have any, it is being re-uploaded by hand, and this is a good moment to ask whether it should live on a video host instead.

Rebuilding your redirects on the WordPress side

Your Squarespace URLs and your new WordPress URLs will not match. Squarespace has its own path conventions per collection type; WordPress uses whatever permalink structure you chose. Every old address needs a 301 to its new equivalent, and those 301s have to exist on WordPress, because once the domain points there, nothing Squarespace holds is ever consulted again.

WordPress has no redirect manager in core. You either install a redirect plugin, which gives you an interface and a bulk import, or you add the rules to your server configuration, which is faster to serve and harder to edit. Both are fine. What is not fine is skipping it, and a site with a blog archive can easily have four hundred rows in the map.

Build the map from the old site’s sitemap before you export anything. The method is in build the redirect map.

Moving the domain, last

The domain is the final step, for the same reason it is the final step on every route: it is the one change the public sees immediately, and the one with a mandatory waiting period attached if you choose to transfer rather than point.

Point the domain at your WordPress host by changing its DNS records, and copy your existing MX and TXT records across before you do, or your email stops arriving. Transfer the registration afterwards, at leisure, if you want to consolidate billing. Detailed sequence in the DNS cutover.

Before you cancel Squarespace

Keep the Squarespace plan running for a few weeks after launch. It costs one more billing cycle and it buys you the ability to re-run an import, re-download an image, or point the domain back if something is badly wrong.

Confirm before you close the account: every post has its original publication date; the image library is being served from your own domain; twenty sample old URLs each 301 to the right place; your forms submit and notify; your email still arrives. Then cancel, and check separately whether the domain registration and any email subscription are on their own renewal schedules.

For the order this fits into, and what the other routes look like, see the full plan for switching website builders.