Squarespace to WordPress migration UK

I have moved several Squarespace sites to WordPress for UK clients. The reasons are familiar. The template is running out of road, the editorial team wants more control over layouts, the subscription cost keeps rising while the platform feels static, the ecommerce side has outgrown what Squarespace offers, or someone wants to own their stack rather than rent it.

The migration itself is rarely the hard part. The hard part is being realistic about how little Squarespace lets you take with you and planning the rebuild rather than the import. This is a planning-level walkthrough. Concepts not clicks, because the Squarespace and WordPress control panels both shift around enough that step-by-step guides go stale within a year.

If you are still weighing the decision rather than executing it, the more general piece on why migration is usually safer than staying on the wrong platform is a better starting point. This post assumes the decision is made.

What Squarespace will and will not give you

The thing that catches every team is the gap between what Squarespace shows you in its export option and what actually comes out the other end.

Squarespace exports blog posts as a WordPress-compatible XML file. It exports basic pages and gallery pages in the same file. That is most of what comes across cleanly.

Everything else is on you. Product catalogues do not export in a WordPress-compatible format and have to be rebuilt or imported through a third-party tool. Member areas, event collections, scheduling and any layout produced by Squarespace blocks do not export at all. Custom code injected into pages does not export. Image alt text and SEO metadata come across partially at best. The visual design does not come across in any usable form, because Squarespace templates are tied to the platform.

Set the expectation early. The export is a starting point for content, not a copy of the site. The rebuild is the project.

Audit before you touch WordPress

Most of the migration work happens before WordPress is installed. The audit is the part that gets rushed and the part that pays back the most.

• Content types. Standard pages, blog posts, gallery pages, products, events, member content. Each becomes a separate decision about how to rebuild it on WordPress.

• Page inventory. Every live URL with its purpose and the blocks it uses. A crawl of the live site combined with the sitemap is the fastest way to build this.

• Blocks in use. List every Squarespace block type the site relies on. Image galleries, summary blocks, accordion blocks, code blocks, embedded forms, third-party embeds. Each one needs a WordPress equivalent.

• Forms and form submissions. Squarespace forms cannot export their submission history in a structured way. If past submissions matter, export them to CSV before the move and store them outside the new site.

• Commerce. Product list, variants, inventory, customer accounts, order history, abandoned cart data, tax rules, shipping zones. Commerce migrations need their own plan.

• Members area. Member records, login emails, gated content, subscription history. If you have members, this is the most fragile part of the move.

• Integrations. Mailchimp, Google Analytics, Facebook Pixel, any third-party scripts. List them and decide which carry over and which retire.

• Domain and DNS. Where the domain is registered, who has access, what records exist beyond the website. Email, subdomains, verification records.

Until that audit is written down, scoping the rebuild is a guess.

URL strategy and the redirect map

Preserve every URL you can. SEO is largely a function of which URLs Google has indexed and trusts and breaking them is the single biggest avoidable mistake in a migration.

Squarespace permalinks follow a small set of patterns. Pages sit at the slug. Blog posts sit at /collection-slug/post-slug. Products sit at /shop/product-slug or under custom store paths. The structure is rigid, which is awkward when you are on Squarespace, but useful here because it makes the redirect map predictable.

Export every live URL from the sitemap, cross-check against Search Console and analytics, then crawl the live site to catch anything the sitemap misses. The output is a spreadsheet with the old URL on one side and the WordPress destination on the other.

Match the new URL to the old where you can. WordPress permalink settings give you enough control to mirror /collection-slug/post-slug for blog posts. Where you cannot match, document the 301. Apply redirects at the web server level using Nginx or Apache rules where possible, rather than inside the application. Server-level redirects are faster and survive plugin churn.

A WordPress redirect plugin is fine for ad hoc redirects editors add later. The bulk redirect map belongs in the server config.

Design rebuild

The Squarespace template does not come across. You have a decision to make about the new design before you start building.

Three approaches I see work.

A bespoke block theme built around the Gutenberg editor. Best fit if you want long-term editorial control with minimal plugin overhead and you have a developer available. The block theme model has matured enough that this is a reasonable default for content-first sites.

A starter theme with a page builder layered on top. Elementor, Bricks or Breakdance. Best fit if the team wants visual layout control without a developer in the loop for every change. The trade-off is plugin lock-in and a heavier front end.

A premium theme used as is or lightly customised. Cheapest path, weakest fit on bespoke needs. Reasonable for small marketing sites where the team will not push the design.

Pick the model that matches the team you will have for the next two years rather than the team you have today. A page builder that depends on a freelancer who disappears is worse than a block theme that anyone can edit.

Forms and integrations

Squarespace forms write submissions to a panel in the Squarespace UI and optionally to Mailchimp or Google Drive. WordPress forms work the same way through plugins. Gravity Forms, Fluent Forms, WPForms, Forminator. All are mature in 2026 and any will do the job.

The thing to plan is the integration side. If Mailchimp was receiving Squarespace form submissions, that flow needs rebuilding through whichever WordPress form plugin you choose. If a Squarespace form was feeding a CRM, point the new form at the same CRM. Past submissions live in CSV files outside the CMS unless someone needs them inside it, which is rare.

Ecommerce: Squarespace Commerce to WooCommerce

If the site sells anything, this is the part that needs the most care.

Squarespace lets you export products as CSV. The export includes basic fields. Title, description, SKU, price, stock, images, up to three variant options. Anything beyond three variant options is silently dropped, which is the kind of detail that bites you on launch day if you only spot it after import.

WooCommerce accepts CSV imports natively but the field mapping rarely lines up cleanly with what Squarespace exports. Plan to either reshape the CSV before import or use a third-party migration service that handles the mapping for you. Several paid services automate Squarespace to WooCommerce moves and are fine for catalogues of a few hundred products. For anything larger or more bespoke, a custom import script using the WooCommerce REST API gives you more control.

Plan separately for customer accounts, order history, abandoned carts, gift cards and stored payment methods. Customer accounts can usually be exported and imported, with the caveat that passwords cannot move so users have to reset on first login. Order history can be imported as historical data but rarely needs to be live in the new store. Stored payment methods always require re-authorisation because the tokens are tied to the gateway and account.

On the gateway side, Squarespace Commerce is tied to Stripe and Square. WooCommerce gives you the choice of every UK gateway, which is one of the reasons people move. Decide which gateway lives where before you touch the migration, because the order of operations matters for refunds and disputes that span the cutover.

Member areas

Squarespace Member Areas do not export in any structured way. If you have a paid membership running on Squarespace, plan the move carefully.

Export the member list to CSV. Plan a re-onboarding flow on WordPress, usually with MemberPress, Paid Memberships Pro or Restrict Content Pro. Communicate the move clearly. Passwords do not transfer. Member emails need to know the move is coming, when to expect their reset email and how to find the gated content under the new URLs.

Active subscriptions are the most fragile piece. If members pay monthly or annually, you have to either run both platforms in parallel for one billing cycle while the new subscriptions are seeded, or cancel and re-bill on the new platform with a clear notice. Neither is clean. Both work if planned and communicated.

Assets and the media library

Squarespace images embedded in blog posts come across in the standard XML import, but they remain hotlinked to Squarespace until you actively pull them into the WordPress media library.

The standard fix is one of the WordPress plugins that rewrites image URLs after import so the files live on the new host. Run it before you turn the Squarespace site off. Hotlinked images break the moment the source disappears.

Images on pages, in galleries, in product photos and in members areas need to be downloaded and re-uploaded manually or through a custom script. Build that into the schedule. For a site with a few hundred images this is half a day. For thousands it can be a week.

SEO carry-over

Meta titles, meta descriptions, OpenGraph tags, schema markup and the sitemap all need to survive the move.

Pick an SEO plugin and stay consistent. Yoast and Rank Math are the obvious defaults. Map Squarespace meta fields across to the equivalent WordPress fields during import or as a post-import pass, so every page has metadata populated on day one rather than slowly accumulating it.

Other items to carry across explicitly:

• Sitemap.xml at the same URL

• Robots.txt with the same rules where they still apply

• Schema markup, particularly Article, BreadcrumbList, Organization, Product and FAQPage where used

• Search Console verification for the new property before launch

• Analytics property and tag continuity

Submit the new sitemap to Search Console once launch is verified. Watch the coverage report daily for the first two weeks. Most rankings settle within a month if the redirect map is clean.

Domain and DNS cutover

Lower the DNS TTL on the apex record a day or two before cutover so propagation is fast when you switch. Move the domain registrar if needed, although moving DNS records is enough for the cutover itself and the registrar move can wait.

List every DNS record on the existing setup. Website records, email records, subdomains, verification records for Google, Facebook, Microsoft. Copy the lot. Email records in particular are the most commonly forgotten piece and the most damaging when broken. A cutover that takes the website live but quietly stops email reaching the office is the canonical migration nightmare.

On UK setups the domain often sits with a Squarespace-supplied registration or with a UK registrar like 123 Reg, Names, or Fasthosts. The model is the same. Map every record, copy them across, switch the nameservers when ready.

Hosting and the WordPress stack

WordPress hosting is the part Squarespace handles for you and the part you take on by moving.

For UK clients the bracket I default to is managed WordPress hosting. Kinsta, WP Engine, Cloudways, Pressable or a regional UK provider like Krystal. Managed hosts handle backups, security, updates and performance tuning without making them the editorial team's problem. The monthly cost is higher than shared hosting and lower than the salary of one in-house sysadmin.

Shared hosting works for small brochure sites with low traffic. It does not work for ecommerce, members areas or anything performance-sensitive. Pick the bracket that matches the site.

Training the editors

WordPress is more flexible than Squarespace and slightly more complex to learn. The editors will feel the difference on day one.

Plan a short training session with the people who will actually be editing. Walk through the three or four jobs they do most often. Adding a blog post, swapping a hero image, editing a service page, publishing a press release. A one-page cheat sheet for those tasks is usually enough. Save the longer documentation for later.

If the build uses a page builder, anchor the training to the page builder. If it uses block patterns, anchor it to those. Editors do not need to understand the difference between a custom post type and a page, they need to know which button to press to get their job done.

Cutover and rollback

Write the cutover plan down before you go near it.

The shape I use:

• Build the WordPress site on a staging environment in parallel with the live Squarespace site. They never share data.

• Run a content freeze on Squarespace once staging is signed off. New posts wait. The window is usually 24 to 48 hours.

• Run a final content sync to pick up anything that landed since the last import.

• Switch DNS to the new WordPress host with TTL already lowered.

• Verify the redirect map by spot-checking the top 50 URLs and a random sample beyond that.

• Monitor for the first week. Search Console for crawl errors, server logs for unexpected 404s, analytics for traffic dips.

Rollback is the part most teams skip writing down. Keep the Squarespace site paid up for at least a month after launch. If something catastrophic surfaces, you can point DNS back and triage without pressure. Once two weeks of clean monitoring are behind you, archive the Squarespace site as a static HTML export and a CSV bundle, then cancel the subscription.

GDPR and data handling during the move

A migration is a data processing event. The ICO expects the lawful basis for the move to be documented, the data minimised to what is needed and any third-party processors handling the move covered by an agreement.

In practice that means logging which data leaves Squarespace, who handles it during the transfer and that the new host is covered by the same UK GDPR commitments the old one was. For ecommerce and members areas this matters more. For a brochure site with a contact form it is mostly a documentation exercise. Either way, the exposure is small if planned and large if ignored.

What to do next

If you are at the planning stage, the practical move is to do the audit yourself or with whoever is going to deliver the build. Until the pages, blocks, forms, products and URLs are written down, scoping is a guess.

If you want a second pair of eyes on the plan, or want someone to deliver the migration end to end, get in touch and tell me what the Squarespace site looks like. You can also see what WordPress development and ongoing WordPress support look like as freelance engagements.