Squarespace to WordPress Migration Guide

Squarespace has an export button, and it produces a WordPress file. That sounds like the whole job, and it is why Squarespace migrations go wrong more often than Wix ones. With Wix, everybody knows they are rebuilding from the start. With Squarespace, people click export, import the file, see their blog posts appear, and assume they are finished. They are perhaps forty per cent finished, and the missing sixty per cent is not obvious until something is already live.

This is what the export actually contains, what it silently leaves behind, and the order that gets you across without losing search traffic.

What the export really gives you

Squarespace exports a WordPress eXtended RSS file. A .xml file in the format WordPress's own importer reads. That is a genuine head start over a platform with no export at all, and it is worth having.

But it is a partial export, and Squarespace is upfront about that in their documentation on exporting your site. The gaps are specific and they are the parts of your site most likely to be earning money.

Three of those are worth pulling out, because they are the ones that catch people.

One blog page only. If your site has a main blog and a separate News or Case Studies collection, the export takes one of them. The others have to be exported separately, if the interface allows it, or moved by hand. Count your collections before you start.

The whole shop. Products, categories, orders, customers. None of it is in the XML. Squarespace exports products to CSV separately, and that CSV needs mapping into WooCommerce by hand.

All design. Every style tweak, every custom CSS injection, every layout decision. The export is content, not appearance. You are choosing a new design whether you meant to or not.

7.0 or 7.1 makes a difference

Squarespace has two generations still in use and they behave differently on the way out.

7.0 sites are built from templates with distinct page types (Index pages, Album pages, Cover pages) several of which do not export at all. If your site leans on Index pages for its layout, expect the export to arrive as a set of disconnected sections with the structure gone.

7.1 is more uniform, which makes the export more predictable, but it also means far more of your site is built from sections and blocks that come across as flattened content rather than as layout.

Either way, check what page types your site actually uses before estimating the work. Two sites with the same page count can be a day apart.

Take an inventory first

Before you export anything, build a list of every URL on the site. This is the step that decides whether your rankings survive, and it takes about an hour.

Three sources, and you want all three, because each knows something the others do not:

1. Your sitemap, at /sitemap.xml. Squarespace generates it automatically. This is what Squarespace thinks your site is.
2. Google Search Console, under Pages → Indexed. This is what Google thinks your site is, which is the list that matters. Export it.
3. A crawler. Screaming Frog's free tier handles 500 URLs, enough for most sites, and finds pages that are linked but missing from the sitemap.

Put the union in a spreadsheet with a column for the new URL. That sheet is your migration plan, your redirect map and your launch test script.

While you are in Search Console, sort by clicks over twelve months and mark the top twenty pages. Those are the ones where a broken redirect costs money, and the ones to test first on launch day. Export the existing titles and meta descriptions as well. They were written for pages that already rank, and a migration is the wrong time to rewrite them.

Squarespace URL conventions

Squarespace URLs are tidier than Wix's, which makes the redirect map simpler, but there are two patterns to know.

The good news is in the first two rows: if your blog lives at /blog/ and you set WordPress to match, most of your URLs change only by a trailing slash, and WordPress adds that itself. That can turn hundreds of potential redirects into none.

The dated format is the one to check for. Some Squarespace configurations put the year, month and day into post URLs. WordPress can reproduce that exactly, Settings → Permalinks → Custom Structure with /blog/%year%/%monthnum%/%day%/%postname%/, and doing so is usually easier than redirecting every post individually. Squarespace uses unpadded numbers (/3/14/) where WordPress pads them (/03/14/), so test one before deciding.

Step one: build the new site somewhere else

Do not point the domain at anything until the new site is finished. Build on a staging domain, get it right, switch at the end.

Three decisions come first.

Hosting. WordPress is software that has to run somewhere, which is the biggest practical change from Squarespace. There is no included platform any more: updates, backups and uptime become somebody's job. Our guide to choosing a host covers what to look for.

A theme. None of your Squarespace design comes across, so pick something close to what you want rather than trying to reproduce what you had. Squarespace templates lean on generous whitespace and large typography, and there are WordPress themes built on the same instincts; chasing an exact copy usually ends with a page builder fighting a theme and a slow site.

Permalinks. Set these before importing anything. If you change the structure afterwards, every redirect has to be rewritten.

Step two: export from Squarespace

In Squarespace, go to Settings → Import / Export → Export, choose WordPress, and if you have more than one blog collection, choose which one. Squarespace prepares the file and offers a download. It is not instant on a large site.

Open the file before you do anything with it. It is XML, so any text editor will show it, and you are checking two things: that it is not empty, and that the post count roughly matches what you expect. A truncated export is easier to spot now than after an import.

Then export the second set of things, because the button only covers one:

• Products, from the Commerce area, as CSV.
• Contacts and mailing lists, as CSV. This is the asset that hurts most to lose and the easiest to forget, because it is not part of the website.
• Order history, as CSV, for your records rather than for import.
• Any second blog collection, separately.

Step three: import into WordPress

In WordPress, go to Tools → Import and install the WordPress Importer. Upload the XML, assign the content to an author, and, this is the part people click past, tick "Download and import file attachments".

That checkbox is the difference between owning your images and borrowing them. Without it, every picture in every post is still loading from Squarespace's servers, and they will all break the day you close the account. WordPress's documentation on importing content covers the general mechanics.

When it finishes, check three things, all of which fail quietly:

• Post count. Compare with Squarespace. A large import can time out partway and report success.
• Media library count. Not whether one post looks right. The count. If it is near zero, the attachment fetch did not happen and you should re-run the import.
• Publication dates. If everything arrived dated today, your archive is out of order.

On shared hosting, large imports frequently hit the PHP execution limit and stop silently. If the count is short, the usual fix is to split the XML into smaller files, or to ask your host to raise max_execution_time for the duration.

Step four: rebuild what did not come

Now the honest part of the work. Take the exclusion list from the top of this article and go through it against your inventory.

Pages mostly arrive, but as flattened text. The words are there; the arrangement is not. Rebuild each one in your new theme, keeping the heading structure. If a page had an H1 and four H2s with particular words in them, reproduce that. It is part of why the page ranks and it costs nothing.

Index pages, album pages and event pages did not export. These have to be recreated from what is on the live Squarespace site, so do it while the old site is still up.

Forms are rebuilt with a WordPress plugin, which is quick. Past submissions are a separate question: they live in Squarespace's form storage or a connected Google Sheet, and they do not travel. Decide whether you need them before the account lapses.

Custom CSS was written against Squarespace's class names and is worth nothing on WordPress. Read it for intent. What were you trying to change?. Then discard it.

If you have a shop

The catalogue moves through CSV into WooCommerce, and expect to fix the column mapping by hand, because the two systems disagree about how variants, options and stock levels are named. Images referenced in the export point at Squarespace URLs and need re-uploading.

What cannot move is orders, customer accounts, saved cards and reviews. Order history is best kept as a CSV record for accounting rather than imported. Customers will have to create new accounts, and that deserves an email explaining why before they discover it at checkout.

Reviews are the painful one, because they are content you earned. If you have many, it is worth copying the best of them into a testimonials section by hand rather than losing them entirely.

Images

If the importer fetched your attachments, the blog images are already yours. Page images often are not, so check.

Squarespace serves images through its own media service, and the URLs frequently carry a ?format= parameter that returns a resized copy. Saving what the page displays therefore saves a derivative rather than the original. Where quality matters, pull the original from Squarespace's asset manager.

A migration is also the one moment when renaming every image costs nothing, because you are handling them all anyway. Squarespace filenames are often a long hash; a descriptive filename is a small, permanent gain.

Step five: the URL map

Every URL in your inventory gets one of three decisions.

That last row matters more than it looks. Google's guidance on redirects treats a redirect to an irrelevant page as a soft 404, so the signals do not carry. Pointing thirty retired pages at your home page does not consolidate their value. It discards it. Send each to the category it belonged to, and where there is genuinely no equivalent, let it return a clean 404.

Do not leave any URL out of the map. One you forget becomes a 404 on launch day, and if it was earning, you find out weeks later.

Step six: write the redirects

Server-level redirects beat plugin redirects for a migration: they are faster, they run before WordPress loads, and they survive somebody deactivating a plugin they did not recognise.

On Apache, above the WordPress block in .htaccess:

Redirect 301 /shop/p/oak-table /product/oak-table/
Redirect 301 /news/spring-update /blog/spring-update/

For a whole prefix, one rule covers the set:

RedirectMatch 301 ^/shop/p/(.*)$ /product/$1/

And for dated blog URLs, if you chose not to reproduce the date structure:

RedirectMatch 301 ^/blog/[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}/(.*)$ /blog/$1/

On nginx the equivalent is a rewrite in the server block, which usually means asking your host. A redirect plugin is a reasonable fallback if server config is not available to you.

Step seven: the domain

If your domain is registered with Squarespace, you can transfer it out or leave it there and repoint it. Transferring is better in almost every case: you control renewal instead of depending on a company whose product you have just left. Squarespace documents the process for transferring a domain away.

Two practical notes. A domain cannot be transferred within sixty days of registration or of a previous transfer, so check the dates before you build a schedule around it. And if the domain came free with an annual Squarespace plan, confirm what happens to it when the plan ends. That is much easier to establish before you cancel than after.

Unlock, get the authorisation code, start the transfer at the new registrar, and allow up to a week. Do it after the new site is built and before you cancel Squarespace.

Step eight: launch

The order is deliberate.

1. Final content check on staging. Every URL from the inventory exists and reads properly.
2. Redirect rules in place and syntactically valid.
3. Settings → Reading → "Discourage search engines" must be OFF. Staging sites are noindexed; live sites must not be. Launching with this ticked is the most common WordPress launch error and it removes you from Google entirely.
4. Point the DNS at the new host.
5. Wait for propagation, usually minutes, occasionally hours.
6. Test the top twenty URLs by pasting each old URL and confirming a 301 to the right page. Not by clicking around the new site.
7. Submit the new sitemap in Search Console, and leave the old one for a few weeks so Google recrawls the old URLs and finds the redirects.
8. Keep Squarespace running for a month. It is your rollback and the only remaining copy of anything you missed.

Because the domain is not changing, you do not need Search Console's Change of Address tool. That is for moving to a different domain, and Google's documentation on site moves with URL changes covers the distinction.

What to expect afterwards

Rankings move after a migration, and knowing that is normal stops you overcorrecting.

Expect two to six weeks of fluctuation while Google recrawls and follows the redirects, then a return to roughly where you were. Squarespace migrations often settle slightly better than they started, because more of the technical surface becomes yours to control. What is not normal is traffic dropping and staying down past six weeks. That means redirects are missing, and the answer is in your inventory.

Watch three things weekly for two months:

• Search Console → Pages, for "Not found (404)" climbing. Each one is a gap in the map.
• Clicks against the same period last year, not against last week.
• Core Web Vitals. On Squarespace, performance was Squarespace's problem; on WordPress it is yours. Google's overview of Web Vitals sets out what is measured, and our piece on why WordPress sites get slow covers the usual causes.

How to check it actually worked

"It looks fine" is not a test. A migration can look perfect and still be losing traffic, because the failures are all invisible from the front end. Five checks, none of which takes long, and all of which have caught real problems.

Test redirects with headers, not with clicks. Clicking a link tells you a page loaded; it does not tell you whether it arrived via a 301, a 302, or a chain of four hops. Only a 301 passes signals properly. From a terminal:

curl -sI https://yoursite.com/old-page | head -1

You want HTTP/2 301. A 302 is temporary and tells Google not to move anything. If you would rather not use a terminal, any online redirect checker shows the same thing, and the browser's network tab shows the full chain.

Count the indexed pages. Note the figure in Search Console before you migrate, and watch it after. It will dip while Google recrawls, then recover. If it settles at half of what it was, pages are missing rather than merely reindexing.

Crawl your own new site. Run the crawler over the live site once it is up and look for internal links pointing at old Squarespace URLs. Imported content frequently carries absolute links to the old domain structure inside the post body, and those become redirect hops or 404s that nobody sees because nobody clicks them.

Check a page that was not in your inventory. Pick something obscure, a page you had forgotten existed, and see what happens to it. If your inventory was complete it will redirect. If it 404s, your inventory missed things, and it will have missed others.

Look at the 404 log after a fortnight. Search Console reports what Google found; your server log reports what everybody found, including people following links from other sites. Two weeks of real traffic surfaces gaps that no amount of planning does.

What you gain, and what you give up

Worth being straight about, because a migration is a trade rather than an upgrade.

That last row is the one that decides whether the move was a good idea. Squarespace was quietly doing a job in the background, and after the migration that job does not disappear. It moves to you or to somebody you pay. A WordPress site nobody maintains is worse than the Squarespace site it replaced, and it usually takes about eighteen months to find out.

What usually goes wrong

Roughly in order of frequency:

Attachments not imported. The checkbox was missed, the site looks fine, and every image breaks when Squarespace lapses.

The second blog collection forgotten. The export takes one. Nobody notices the News section is missing until a customer asks.

The import timed out. It reported success at 60 per cent and no one compared counts.

Dated URLs unhandled. Every post 404s because the permalink structure does not match and no rule was written.

"Discourage search engines" left on. One checkbox, and traffic disappears within a fortnight.

Squarespace cancelled too early. The rollback and the last copy of the unexported pages go together.

How long it takes

Squarespace builds are usually a little faster than the equivalent Wix ones, because the blog and basic pages genuinely do import. The saving disappears if the site leans on Index or Album pages, which do not.

If you would rather it were handled, that is what our website migration service does. Inventory, import, rebuild, redirect map and launch, with the old site kept live until the new one is proven. Afterwards a care plan covers the updates, security and backups that Squarespace used to do quietly in the background; our guide to backups explains what changes there, and what maintenance costs sets out the ongoing figure.