Moving from Wix or Squarespace to WordPress: The Complete Migration Guide

Moving from Wix to WordPress – or from Squarespace to WordPress – is one of the most common projects on my desk, and it is almost never a whim. The site owner has usually spent two or three years on the builder, the business has grown, and the platform has started saying no: no to the layout they want, no to the integration their new CRM needs, no to the loading speed Google wants, no to leaving without pain. Builders are genuinely good at getting a first website online in a weekend. They are much less good at being the website of a business that now depends on search traffic, custom features and a design that does not look like a template.

The move itself has a reputation for being risky, and the reputation is half deserved: done casually, a builder migration can lose rankings, break every inbound link and drop email for a day. Done properly, it is a controlled, boring process – the old site keeps running until the new one is proven, every old URL is mapped to a new one, and the cutover takes minutes, not days. I have done this migration many times for clients in Germany, the UK, the US and Australia, and this guide is the complete version of what I tell them: how to know you have really outgrown the builder, what each platform lets you export (and what it holds hostage), how to handle the URL and SEO side, what to do about forms, members and store data, how the DNS and email cutover works, and what it costs.

Table of contents

• Signs you have outgrown Wix or Squarespace
• What actually exports from each platform
• URL structures and the 301 problem
• Rebuilding the design: copy it or improve it?
• Forms, members and store data
• The migration, step by step
• Keep the builder running while you build
• DNS and email cutover without downtime
• Protecting your SEO through the move
• Timeline and cost: what to expect
• The post-move checklist
• Frequently asked questions

Signs you have outgrown Wix or Squarespace

Not everyone should migrate. If your site is a simple brochure, the builder subscription is not hurting you and you never fight the editor, stay where you are – a migration you do not need is just cost. I wrote a full comparison of the two worlds in WordPress vs website builders; this section is the shorter test. You have outgrown the builder when several of these are true:

• You design around the platform instead of the business. The homepage looks the way it does because that is what the editor allowed, not because it is what converts. Every new section is a compromise.
• You need a feature the app market cannot deliver. A real booking flow, a members area with proper roles, a CRM or ERP integration, multi-language done properly, a calculator, gated content – on a builder these are either impossible or bolted on through a third-party widget in an iframe that looks and performs like one.
• Speed scores are stuck. Builder sites ship the same heavy JavaScript bundle to every visitor and you cannot remove it. If your mobile PageSpeed score has a ceiling in the 50s or 60s no matter what you delete, that ceiling is the platform.
• SEO work hits walls. You cannot control everything you want – clean URL structures, some schema types, fine-grained redirects, server-level settings. Content teams feel this first.
• The subscription maths stopped making sense. Builder plans that started at a few euros a month become EUR 25-40 per month with commerce and apps – EUR 300-500 a year, forever, for a site you still do not own. Good WordPress hosting for the same site is EUR 5-15 per month, and the platform itself is free.
• Your store has grown up. Transaction fees on lower plans, limited shipping and tax logic, no real B2B pricing, weak export options – stores outgrow builders faster than any other site type.
• You want to own the asset. A builder site cannot be moved, backed up independently or handed to another developer. A WordPress site is files and a database; it goes wherever you go.

One honest counter-sign: if the real problem is that nobody updates the site, WordPress will not fix that. Migrate for capability, ownership and growth – not in the hope that a new platform will create discipline the old one did not.

What actually exports from each platform

This is the part that surprises people most, so let me be blunt: neither platform gives you a full export, because neither platform wants you to leave. What you get differs a lot between the two.

Squarespace is the friendlier of the pair. It offers a built-in export to a WordPress-format XML file, which covers regular pages and one blog with its posts, including text and image blocks. That sounds better than it is, because the export leaves plenty behind: product pages, events, album and gallery pages, audio and video blocks, index pages, drafts, and every bit of styling and CSS. Store products come out separately as a CSV file. So a content-heavy Squarespace blog migrates semi-automatically; anything more structured is a partial export plus manual work.

Wix is the harder case. There is no site content export at all – no XML, no HTML download, nothing official that moves pages or blog posts out of the platform. What Wix will give you as files: store products as CSV, contacts as CSV, and your media files one by one. Everything else – page content, blog posts, layouts – has to be moved either manually (copy and paste into WordPress, fine up to perhaps 30-40 pieces of content) or with scripted extraction, where a developer pulls the published content from the live site programmatically. I use the scripted route for Wix blogs above roughly 50 posts; below that, careful manual migration is often faster and cleaner because a human sorts formatting problems as they go.

On both platforms, images deserve their own line item. Squarespace’s XML references images on Squarespace’s CDN, so they must be downloaded and re-imported into the WordPress media library during the import – otherwise your “migrated” site is hotlinking images from an account you are about to close. Wix images live on Wix’s CDN the same way and are collected during the content extraction. Either way, the finished WordPress site must reference only its own media library, with proper file names and alt text – which is also the moment to compress and convert images properly, something builders never let you control.

And a category of things that never migrates from either platform, because it does not exist as portable data: the design itself, animations, app and widget functionality, form logic, and any SEO settings you configured in the builder’s panels. All of that is rebuilt, not moved – which, as I argue below, is an opportunity rather than a loss.

URL structures and the 301 problem

Here is where migrations quietly succeed or fail. Every page on your old site has a URL, and Google, other websites and people’s bookmarks all point at those exact addresses. Builders impose their own URL patterns: Wix blog posts typically live under /post/your-title (older sites used /single-post/), and Wix pages get whatever path was set in the editor. Squarespace blogs usually sit at /blog/your-title or with date-based paths like /blog/2023/6/14/your-title, and pages under short slugs. A clean WordPress build will not reproduce these patterns – nor should it – so every old URL will be different from its new counterpart.

If you do nothing about that, the day you switch, every old URL returns a 404: rankings drain away over the following weeks, backlinks point at error pages, and printed materials and social profiles lead nowhere. The fix is the 301 redirect – a permanent, server-side “this page has moved here” that passes both visitors and ranking signals to the new address.

The catch with builders is that you cannot set these redirects on the old platform in any way that survives the move: once your domain points at the new WordPress hosting, Wix and Squarespace are out of the loop entirely. All redirects must therefore live on the WordPress side, ready before the cutover. The process is mechanical but must be complete:

• Crawl the old site with a tool such as Screaming Frog and export every indexed URL – pages, posts, categories, tags, images if they rank.
• Map every old URL to its new home in a spreadsheet: /post/why-we-rebranded becomes /blog/why-we-rebranded/, and so on. Pattern-based rules handle whole sections (everything under /post/ maps to /blog/), with one-off rules for the exceptions.
• Load the map into WordPress – I use the Redirection plugin for one-off rules and regex rules for the patterns, or server-level rules for very large sets.
• Test before launch by requesting old paths against the new site on the staging or hosts-file level, and again within an hour of the DNS switch.

Do not redirect everything to the homepage. A hundred old URLs all pointing at / is treated by Google as a soft 404 and throws the ranking value away. Each page redirects to its true equivalent; genuinely retired content redirects to the closest relevant page or is allowed to 404 honestly.

Rebuilding the design: copy it or improve it?

Clients often ask me to “move the site as it is” – same design, new platform. I understand the instinct, and I usually argue against it, for three practical reasons.

First, an exact copy is more expensive than it sounds. Builder designs are made of platform-specific blocks, spacings and effects; reproducing them pixel for pixel in a custom theme means hand-measuring someone else’s compromises. Second, the design you have was shaped by the builder’s limits – the strange section breaks, the stacked mobile layout, the template-shaped header all exist because the editor forced them. Copying them into WordPress preserves problems you are paying to escape. Third, you are touching every page anyway: this is the cheapest moment you will ever have to fix structure, hierarchy and conversion flow, because the rebuild cost is already in the budget.

What I recommend instead is a redesign-quality rebuild: keep your brand, your content and everything that demonstrably works, and rebuild the site as a lightweight custom WordPress theme with proper structure – real heading hierarchy, editable sections, clean markup, fast templates. In practice that means the new site looks like a sharper, faster version of the old one rather than a different company. Where clients have a designer, I build from their Figma file; where they do not, I structure the rebuild directly from the existing content plus reference sites they like. Either way the result is the same class of build I do in custom WordPress development projects: no multipurpose theme, no page-builder plugin recreating the problem you just left, a mobile PageSpeed score the builder could never reach, and an editing experience where your team changes text and images without being able to break the layout.

The honest exception: if the builder site was professionally designed recently and the move is purely technical (speed, features, ownership), a close rebuild with quiet improvements is reasonable. Even then, “close” should mean faithful to the brand and layout intent – not a forensic copy of every pixel.

Forms, members and store data

Content and design are the visible half of a migration. The data underneath needs its own plan, because this is where things get lost silently.

• Form submissions and contacts. Both platforms let you export contacts and form entries as CSV files – do it before anything else, because the moment the subscription lapses, that data is gone. On the WordPress side, forms are rebuilt (they are functionality, not content), and old submissions are archived as CSV or imported into whatever CRM or newsletter tool you use. Check where the builder’s forms were sending notifications; the new forms must notify the same people from day one.
• Members and logins. Neither Wix nor Squarespace exports member passwords – no platform does, because passwords are stored hashed. You can export the member list (names, emails, sometimes profile fields), import those as WordPress users with appropriate roles, and then every member sets a new password through a reset link. Plan the communication: a short email before the move (“we are upgrading the site, you will set a new password”) turns a support-ticket storm into a non-event.
• Store products. Products export as CSV from both platforms and import into WooCommerce with mapping work: categories, variants and options, prices, stock, images, SKUs. Variants are the fiddly part – builder option structures do not match WooCommerce attributes one-to-one, so budget review time per product type rather than assuming the CSV “just works”.
• Orders and customers. Order history can be exported for your records and accounting, and can be imported into WooCommerce where continuity matters (repeat-customer stores, warranty lookups). Many smaller stores instead keep the old order archive as spreadsheets and start WooCommerce clean – simpler, and auditors do not care where the history lives. Customer accounts follow the member rule: accounts recreated, passwords reset.
• Subscriptions and recurring payments. If you sell recurring anything through the builder’s payment system, treat this as the most delicate item in the whole migration: recurring billing agreements generally cannot be transferred between platforms, so subscribers must re-subscribe on the new site. Time this carefully and communicate it early.
• Bookings, events, reviews. App-based data on builders is often trapped in the app. Export whatever each app allows, and where an app offers no export, capture what you need manually before closing the account. Product reviews from Squarespace and app-collected reviews on Wix fall into this bucket surprisingly often.

The migration, step by step

Here is the sequence I run. The single most important property of this plan is that the old site stays live and untouched until step nine – at no point is your business offline or half-migrated in public.

1. Audit and crawl. Crawl the old site, export all URLs, list every page, post, form, app and integration. Export analytics and Search Console data as the “before” baseline. Note current traffic pages – they get extra care.
2. Export everything exportable. Squarespace XML and product CSV, or Wix CSVs plus the content extraction plan. Contacts, form entries, member lists, orders. Download media. Store it all somewhere safe that is not the builder.
3. Set up WordPress on proper hosting. Fresh install on the hosting the site will actually live on, reached via a temporary or staging URL, blocked from search engines for now.
4. Import and clean content. Run the XML import or the manual/scripted content move, re-import all images into the media library, fix formatting, set titles, slugs, categories and meta data. This step always takes longer than expected – budget for it.
5. Build the theme. The redesign-quality rebuild from the previous section: custom theme, editable sections, fast and accessible templates, forms rebuilt and tested, store rebuilt in WooCommerce if there is one.
6. Rebuild functionality. Every app and widget from the builder gets a WordPress equivalent – usually a lighter one. Newsletter signup wired to your actual list, booking flows, maps, galleries, integrations.
7. Prepare the redirect map. Every crawled old URL mapped and loaded into the new site, plus the SEO plugin configured, XML sitemap ready, analytics installed in parallel.
8. Full QA on staging. Content review page by page against the old site, forms tested end to end, test orders through the store, responsive and browser checks, performance pass. The client signs off on staging before anything public changes. My full pre-launch routine is in the WordPress launch checklist.
9. Cutover. DNS switches the domain to the new hosting (details in the next two sections), SSL is issued, search engine blocking is removed, redirects are verified live within the hour.
10. Monitor and close down. Watch 404 logs, Search Console and analytics daily for the first weeks, fix any missed redirects, submit the new sitemap – and only when the new site is proven stable do you downgrade and later close the builder subscription.

Keep the builder running while you build

The rule that removes most of the risk from this project: the old site keeps running, unchanged, until the new one has fully replaced it. The WordPress build happens on its own hosting under a staging address, invisible to visitors and search engines. Your business notices nothing during the build – the live site takes orders and enquiries exactly as before.

Three practical points make the parallel period smooth. First, agree a content freeze for the final week or two: from the moment content is copied, new blog posts, product changes and price edits on the builder either wait for launch or are logged and applied to both. A shared “changes since export” list costs nothing and prevents the classic mistake of launching a new site with last month’s prices. Second, do not cancel anything early – keep the builder subscription and any connected apps active through launch and the monitoring period, because you may need to log in to check how something worked or re-export data you missed. A month of overlap costs EUR 20-40 and buys real insurance. Third, when it is finally time, downgrade before you delete: strip the builder account to its cheapest plan for another month or two rather than deleting the account, and keep your local exports forever regardless.

This is also the honest answer to “how long will my site be down during the migration”: it will not be. There is no moment when visitors see a construction page. The switch is a DNS change from one working site to another working site.

DNS and email cutover without downtime

The cutover is where non-technical owners get nervous, so here is exactly what happens. Your domain name is a signpost: DNS records tell the world “the website lives at this address, email for this domain goes to that server”. Moving the site means repointing the website records to the new WordPress hosting – and touching nothing else.

Email is the thing people break. Your email almost certainly runs on Google Workspace, Microsoft 365 or your registrar’s mail service – controlled by MX records that have nothing to do with the website. The iron rule of cutover day: change only the website records (the A record for the bare domain, the CNAME for www), and leave the MX, SPF, DKIM and every other record exactly as it is. When email dies during a migration, it is because someone replaced the whole DNS zone instead of editing two records. I copy the entire existing zone into a document before touching anything, so every record can be restored or recreated precisely.

Where the domain lives matters. If your domain is registered at an independent registrar and merely connected to Wix or Squarespace, the cutover is a two-record edit at that registrar. If the domain was registered through the builder, you have a choice: keep it registered there and just change the DNS records (fine, works immediately), or transfer it out to a normal registrar (cleaner long-term, takes a few days, do it before or after launch week – never during).

The sequence I use: a few days before launch, lower the TTL (the caching time) on the website records to five minutes, so the change propagates fast. On launch day – a low-traffic hour for your audience – update the A and CNAME records, confirm the SSL certificate is issued on the new hosting for both bare and www versions of the domain, and watch the new site come live region by region. Because both old and new sites are fully working during propagation, visitors on cached DNS simply see the old site for a little longer. Send a test email in and out. Total downtime, done this way: zero.

Protecting your SEO through the move

Everything in this section exists because of one fact: Google ranks URLs, not brands. Move a page’s address without a forwarding instruction and its rankings do not “transfer eventually” – they belong to a URL that now returns 404. I keep a full post on this topic – how to migrate without losing SEO rankings – so here is the builder-specific summary:

• The redirect map is 80% of SEO protection. One-to-one 301s from every old URL to its true new equivalent, live from the first minute of cutover. This is the whole reason the URL section above exists.
• Preserve titles and meta descriptions for pages that rank. Whatever you think of the builder’s SEO panel, the titles in it are the ones Google currently rewards. Carry them over into your WordPress SEO plugin first; improve them deliberately later, page by page, not accidentally during the move.
• Match content on ranking pages. A page that ranks should launch with substantially the same content, headings and internal links. Rewrite it a month later if you want – during the move, stability wins.
• Rebuild internal links. Imported content is full of links pointing at old builder URLs, including absolute links to the builder’s own domains. Every internal link gets updated to the new structure – redirects would catch them, but clean links are faster and safer.
• Search Console on day one. Verify the new site (the property stays the same if the domain does not change), submit the new XML sitemap, and watch the coverage and 404 reports daily. Missed redirects show up here first; fixing them within days costs nothing, discovering them after two months costs rankings.
• Expect a wobble, not a crash. Even a perfect migration shows a few weeks of fluctuation while Google recrawls. Done properly, rankings return to baseline and then usually improve – the new site is faster, cleaner and structurally better than a builder can be, and speed and crawlability are ranking inputs. A crash that persists past a month means missed redirects or changed content, and both are findable and fixable.

Timeline and cost: what to expect

Honest ranges, based on the projects I actually do. Every migration includes the same skeleton – export, content move, theme build, redirects, cutover, monitoring – and scales with content volume and functionality:

Those figures buy the redesign-quality rebuild described above, not a copy-paste job: custom theme, full redirect map, forms and functionality rebuilt, QA, cutover and post-launch monitoring. At agency rates in Germany, the UK or the US, multiply by three to six; the process should be the same, so compare quotes on what is included (crawl, redirect map, content import method, post-launch monitoring) rather than on the number alone. My quotes are fixed price, based on a look at your actual site, within 24 hours.

Set against the builder’s running costs, the payback is straightforward: a business-level builder plan plus apps commonly costs EUR 300-500 per year, against EUR 60-180 per year for good WordPress hosting. The migration typically pays for itself in two to four years on subscription savings alone – before counting the speed, SEO headroom and features that were the real reason to move.

The post-move checklist

Launch day is not the finish line; the two weeks after it are. This is the closing routine:

• Within the first hour: test the top 20 old URLs redirect correctly on the live domain; submit the XML sitemap in Search Console; run a test form submission and a test order; confirm SSL on bare and www; send and receive a test email.
• First week, daily: check the 404 log and add any missed redirects; watch Search Console coverage and Core Web Vitals; compare analytics against the pre-move baseline; keep an eye on the inbox routes for every form.
• Update the outside world: Google Business Profile, social profiles, email signatures, directories and any ad campaigns pointing at old deep URLs – redirects catch them, but direct links are better.
• Set up the boring essentials builders did for you: automated off-site backups, updates routine, security hardening, uptime monitoring. This is the one genuine responsibility WordPress adds, and it is either an hour of setup plus a monthly routine or a small maintenance plan.
• Weeks 2-4: confirm rankings have stabilised for your money pages, fix stragglers, then downgrade the builder plan; cancel it fully once a month has passed with no surprises. Keep all exports permanently.
• After a month: start using what you moved for – the content plan the builder’s SEO ceiling discouraged, the features that were impossible, the speed budget you now control.

Planning a move off Wix or Squarespace?

I migrate builder sites to fast, custom-built WordPress every month: full content and data export, redesign-quality rebuild, complete redirect map, zero-downtime cutover and post-launch monitoring – fixed price quoted within 24 hours after a look at your site. See the WordPress migration service and my portfolio, or send me your site address and I will tell you honestly what the move involves – including if I think you should stay where you are.

Frequently asked questions

How do I move from Wix to WordPress?

There is no direct Wix to WordPress export, so the process is: export what Wix allows (products, contacts as CSV), move page and blog content manually or via scripted extraction, rebuild the design as a WordPress theme, map every old URL to a 301 redirect, then point your domain at the new hosting. The old site stays live until the new one is ready.

Can I export my Squarespace site to WordPress?

Partially. Squarespace exports pages and one blog as a WordPress-compatible XML file; products export as CSV. Design, product pages, events, galleries, drafts and app functionality do not export and are rebuilt on the WordPress side.

Will I lose my Google rankings when I leave the builder?

Not if every old URL gets a one-to-one 301 redirect to its new equivalent and ranking pages keep their titles and content through the move. Expect a few weeks of minor fluctuation, then recovery – often followed by improvement, because the new site is faster.

How long does a Wix or Squarespace to WordPress migration take?

Typically two to four weeks for a business site, longer for stores or very large blogs. The live site stays online throughout; the actual switchover is a DNS change with zero downtime.

Will my email stop working during the migration?

No – if it is done correctly. Email is controlled by MX records that are separate from the website records; a careful cutover changes only the website’s A and CNAME records and leaves email untouched.

Can I keep my domain name?

Yes. If the domain is registered outside the builder, only two DNS records change. If it was registered through Wix or Squarespace, you can either keep it registered there and repoint it, or transfer it to an independent registrar – just not during launch week.

What happens to my members and customer accounts?

Member and customer lists export and can be recreated in WordPress, but passwords never transfer from any platform – every user sets a new password via a reset link. Announce it in advance and it is a non-issue.