How to Migrate From Squarespace to WordPress Without Losing Traffic

The Export Button Is Not the Migration

Search for this topic and you will find a dozen tutorials that boil down to four steps: export from Squarespace, install WordPress, import the file, point the domain. That description is accurate and it is also the reason so many of these migrations go badly.

The export is real and it does useful work. It is also partial in ways that are not obvious until after you have cancelled the subscription, and the part of the project that determines whether you keep your search traffic is not in those four steps at all.

This is the version we run on client projects. It assumes you have already decided to move, and if you have not, the tradeoffs are laid out in Squarespace vs WordPress.

What the Squarespace Export Actually Contains

Start here, because the scope of your project is defined by what is not in this list.

The export lives under Settings, then Import and Export, and produces a .xml file in WordPress WXR format.

What comes across:

• Standard pages
• One blog page and its posts, including categories and tags
• Text blocks and image blocks
• Embed blocks
• Gallery pages

What does not come across:

• Product pages and all commerce data
• Album pages
• Index pages, including their layout and settings
• Event collections
• Custom CSS
• Every style setting, font, and color choice
• Form blocks and every submission they collected
• Audio blocks, video blocks, and product blocks
• Member area content and member records
• Folders as navigation structure

There is one more constraint that catches people: the export handles one blog page per run. If your site has more than one blog collection, you export once per blog and merge the results.

So the honest framing is this. If your site is pages plus a blog, the export does most of the content work. If your site leans on commerce, events, forms, member areas, or index pages, the export covers a minority of it and the rest is a rebuild.

Before You Touch Anything: Benchmark

This is the step that separates a migration you can manage from one you can only apologize for, and it takes about a day.

Crawl the whole site. Screaming Frog or Sitebulb. Every URL with its status code, title tag, meta description, H1, and word count. Export it and save it somewhere that is not the website.

Export Search Console. Sixteen months of performance data by page and by query. This tells you which URLs are earning traffic, which is almost never the same list as the pages you think are important.

Export GA4. Sessions and conversions by landing page for the past twelve months.

Export your backlinks. Which external sites link to which URLs on your domain. These URLs are non-negotiable redirect targets even when the pages get almost no traffic.

Save the sitemap. Squarespace publishes one at /sitemap.xml. Download it as a file.

Screenshot your rankings. Dated, for every keyword you care about.

Pull your form submission history. Squarespace stores it and does not export it. Get it out now, while the account is active.

Once the Squarespace site is gone, none of this can be recreated. The full reasoning behind each item is in our SEO migration checklist.

Build the URL Map

This is the spine of the project. One spreadsheet, one row per old URL, one column for its new destination.

Build the source list from the union of three exports: the crawl, Search Console, and your backlink file. The crawl finds every linked page. Search Console finds pages that earn traffic without being linked internally. The backlink file finds pages other sites point at, including ones orphaned years ago. Any one source alone will miss URLs.

Squarespace URL patterns to watch for specifically:

• Blog posts usually sit at /blog/post-name or under whatever slug the blog collection uses, and often carry a date-based path depending on how the collection was configured
• Pages inside a folder inherit the folder slug in their path
• Product URLs sit under the store collection's path, typically /shop/product-name
• Event URLs sit under the events collection
• Squarespace serves URLs without a trailing slash, and WordPress commonly adds one, which is a redirect you need to handle deliberately rather than accidentally

Then apply the same four rules that govern every migration. Keep the URL identical wherever the new build allows it, because an unchanged URL carries no risk at all. Map one to one to the closest equivalent page, never in bulk to the homepage, because a redirect to an unrelated page is treated as a soft 404 and drops the original from the index. Resolve chains so each old URL points directly at its final destination. Use 301, and leave the rules in place permanently rather than for a few months.

WordPress side, implement the map with a redirect plugin or, better, at the server level in your host's configuration. Server-level rules are faster and do not depend on WordPress loading.

Move the Content

With the map built, run the actual transfer.

Export from Squarespace. Settings, then Import and Export, then Export, choosing WordPress format. Repeat per blog page if you have more than one.

Import into WordPress. Tools, then Import, then the WordPress importer. Check the box to download and import file attachments. On sites with a lot of images this step times out. If it does, increase the PHP execution limit and memory on the server and run it again rather than assuming it finished.

Verify the images. This is the step people skip and later regret. Crawl the new site and search the source for squarespace-cdn.com. Any hit is an image still hosted by Squarespace, which will vanish the day your subscription lapses. Pull those down locally before you cancel anything.

Rebuild what the export skipped. Working from the exclusion list above: index pages, album pages, events, member areas, forms, and any custom CSS. Products come across through a separate CSV export from the Squarespace store, mapped into WooCommerce's product importer column by column, and the mapping needs deciding rather than guessing.

Check the content survived. Compare word counts against your original crawl. Squarespace blocks sometimes import as stripped text, and a page that ranked because it was thorough will not keep ranking as a summary of itself.

Rebuild titles and meta descriptions. The WXR file carries some of this and not reliably all of it. Use your original crawl export as the source of truth and confirm every page that earns traffic still has the title it had before.

Rebuild the Things That Do Not Export

Three of these deserve specific attention because they are where projects run long.

Forms. Squarespace form blocks do not export and neither do their submissions. Rebuild every form in a WordPress form plugin, wire the notifications to a real inbox, and test an actual submission end to end before launch. Then pull your historical submissions out of Squarespace while you still can.

Commerce. Products export as a CSV separate from the WXR file. Mapping into WooCommerce means aligning columns for SKU, price, variants, categories, images, and inventory. Variants are where this gets tedious, because the two systems model them differently. Budget real time for it and reconcile the product count afterward.

Member areas. Squarespace member content and member records do not transfer. If you are running paid memberships, the members themselves have to be recreated in whatever membership plugin you choose, and you need a communication plan for asking people to reset passwords. Do not discover this in launch week.

Test Before You Launch

Build on staging, and protect it with HTTP authentication rather than a noindex tag. Authentication cannot be forgotten, because if it is still on at launch nobody can reach the site and you will know in a minute. A forgotten noindex tag is invisible and removes the site from search over the following two weeks.

Before you flip anything:

• Run the complete list of old URLs through the redirect rules and confirm every one returns a 301 to the intended destination in a single hop. Not a sample. All of them.
• Confirm no page carries an unintended noindex tag
• Confirm robots.txt is the production version
• Confirm the XML sitemap contains only canonical, indexable, 200-status URLs
• Submit a real enquiry through every form and confirm it arrives
• Complete a real test transaction if you have a store
• Check every template on a phone
• Compare page speed against the baseline you recorded

Launch, In Order

1. Back up the Squarespace export files and confirm you can still access the account
2. Push the WordPress site live with the redirect rules already active, not added afterward
3. Remove the staging protection, then immediately verify robots.txt and check the live source for stray noindex tags
4. Update DNS. If Squarespace is your registrar you can either transfer the domain out or leave it registered there and repoint the records. Do this early in the day and allow for propagation
5. Crawl the live site immediately, looking for 404s, redirect chains, and missing titles
6. Hand check thirty of your highest traffic old URLs
7. Submit the new sitemap in Search Console
8. Confirm analytics and conversion tracking are recording

Launch on a Tuesday morning. The problems you find on day one are cheap to fix when the people who built the site are at their desks.

Do not cancel Squarespace yet. Keep the subscription running for at least thirty days. It costs one month's fee and it is your only way back if something turns out to be missing.

What to Expect Afterward

A short dip is normal. A permanent loss is not.

Search engines need to recrawl every redirected URL, follow it, process the destination, and reassign the signals. For a site under two hundred pages that takes roughly two to three weeks. Larger sites take six to eight.

Weeks one through three will fluctuate. By weeks four to six you should be back at baseline, and if the new site is genuinely faster and better structured, ahead of it.

What is not normal is a drop of thirty percent or more that has not started recovering by week three. That is a defect rather than the migration settling, and the first four places to look are the redirect map, robots.txt, the live source for a stray noindex tag, and whether page content got shortened during the rebuild.

The Five Failures That Cause Almost All the Damage

Redirect map built from the sitemap alone. It misses every orphaned page that still earns traffic and every page with inbound links that was not linked internally.

Bulk redirect to the homepage. Feels complete, functions as a mass delete.

Images left on the Squarespace CDN. Everything looks correct until the subscription lapses, then every image on the site breaks at once.

Forms rebuilt but never tested. Enquiries stop arriving and nobody notices for eleven days, because an absence of leads looks exactly like a slow month.

Content trimmed during the redesign. Pages that ranked for being thorough became pages that were merely tidy.

Frequently Asked Questions

What does the Squarespace export actually include?

The Squarespace export produces a WordPress WXR file containing standard pages, one blog page and its posts, text and image blocks, embed blocks, and gallery pages. It excludes product pages and commerce data, album pages, index pages, event collections, custom CSS, all style settings, form blocks and their submissions, audio and video blocks, and member area content. It also exports only one blog page per run, so a site with several blogs needs several exports.

How long does a Squarespace to WordPress migration take?

For a straightforward site of pages and a blog with fewer than a hundred URLs, two to four weeks is realistic including design, content checks, redirect mapping, and testing. Sites with a store, member areas, events, or heavy custom CSS take four to eight weeks because those elements are rebuilt rather than imported. The export and import itself takes under an hour. Everything else in the schedule is rebuilding what the export leaves behind and getting the redirects right.

Will I lose SEO rankings moving from Squarespace to WordPress?

Not if the redirects are complete. Expect two to four weeks of fluctuation while search engines recrawl and reprocess the new URLs, then a return to baseline or better. Permanent losses come from specific mistakes: URLs that were never mapped, old URLs redirected in bulk to the homepage, a staging noindex tag left live, or page content shortened during the redesign. Every one of those is preventable with work done before launch.

Do images transfer from Squarespace to WordPress?

The WordPress importer will attempt to download images from the Squarespace CDN into your media library, but the process frequently fails partway on larger sites and leaves some images still pointing at Squarespace URLs. Those pages look perfectly fine until the Squarespace subscription lapses, at which point the images disappear. Before cancelling anything, crawl the new site and confirm no image is still served from a squarespace-cdn.com address.

Can I keep my domain when moving from Squarespace to WordPress?

Yes. If the domain is registered elsewhere, you simply repoint the DNS records at your new host. If Squarespace is the registrar, you can either transfer the domain out, which requires unlocking it and retrieving an authorization code and takes several days, or leave it registered with Squarespace and change the DNS records to point at the new host. Either works. Handle the domain before launch day rather than during it, because DNS changes take time to propagate.

Do Squarespace form submissions transfer to WordPress?

No. Form blocks do not export, and neither do their stored submissions. Rebuild each form in a WordPress form plugin before launch, and export any historical submission data you need out of Squarespace while the subscription is still active. Once the account closes, that data is gone. This catches people who assumed their enquiry history lived in their email inbox as well as in Squarespace.

Move It Once, Move It Properly

The technical work here is not exotic. It is a sequence, and the projects that go wrong are the ones that ran the sequence out of order, usually by building the new site first and thinking about URLs last.

If your Squarespace site earns meaningful traffic, get the benchmarking and the URL map done before anything gets designed. That single reordering prevents most of what goes wrong.

Get a free Revenue Opportunity Analysis and we will show you which of your current pages are earning the traffic, which URLs carry links you cannot afford to break, and what your redirect map needs to cover. See how we handle rebuilds in WordPress development and website design and development, or read our process. Book a strategy call or call us at 321-401-7016.