Moving from Squarespace or Wix to WordPress: the migration guide

Moving from Squarespace or Wix to WordPress usually means a rebuild plus moving the content that can transfer. Take stock, test the import privately and rebuild what's missing before touching the domain or email. Careful work cuts the risk. No migration can promise unchanged rankings or zero disruption.

Squarespace or Wix? Read your platform's export section, then follow the shared steps from the inventory onwards.

How a builder to WordPress move works

Both routes share most of the work. What differs is how much each platform lets you take with you.

Neither path is a one click conversion of the whole site. This guide's worked destination is self hosted WordPress, where you choose the host. Differences for WordPress.com are labelled where they matter.

For the wider context, start with the small business website guide.

When should you stay on the current platform?

Start from a real requirement, not a feeling. That might be a content structure, an integration or a workflow the current platform can't handle.

Test whether the current platform can meet it before you approve a move. A bigger site or SEO ambitions alone don't prove the builder is unsuitable.

WordPress isn't automatically the best choice for every growing business. A suitable builder can save real operational effort.

For the broader choice, see comparing website platforms and whether WordPress fits the business. If you're still undecided, try our website platform comparison tool.

What changes with WordPress

Self hosted WordPress gives you choices about how the site is built. It also hands you jobs the builder used to handle:

• hosting, including its renewals

• software and plugin updates

• backups and tested recovery

• managing who has access

• support when something breaks

Managed hosting can take on some of this, depending on the contract. If the terms are new to you, see how a CMS works.

Describe your actual destination in any comparison. Not every WordPress setup gives the same control.

Content rights, platform exports and third party licences are separate questions. Wix says the content you build there belongs to you. Purchased fonts, images and apps are different. Check whether each licence transfers before you rely on it.

What can you export from Squarespace?

Squarespace gives you a content export. It's narrower than it sounds.

Squarespace's export guide produces an XML file for WordPress. XML is a structured text format that importers can read. Here's what it covers:

The export isn't a working website, just a starting point for the content.

Squarespace requires a published site set to Public, and trial sites can't export. Don't expose confidential or member only content just to run an importer. Move that material by an authorised manual or specialist route instead.

The current path is short: open the Import and export content panel and choose Export. Pick the WordPress option and choose a primary blog if you have several. Then download the file and keep the original unchanged.

Then list what the file leaves behind:

• portfolio, store and other unsupported page types

• page specific headers, footers and sidebars

• audio, product and video blocks

Also check your forms, navigation and downloadable files. Rebuild or move them separately wherever the import misses them.

Importing the file

On self hosted WordPress, the WordPress Importer reads the file. Squarespace isn't among the importers in WordPress's import documentation. Don't expect a dedicated one. Run a pilot import first.

On WordPress.com, a guided Squarespace importer handles the upload. It can match authors to users. It can also set an optional /blog/%postname% permalink structure on plugin enabled plans. A permalink structure is the pattern WordPress uses for page addresses. Recheck either dashboard when you start, because menus change.

After importing, review each post and page for:

• titles, authors and dates

• categories and formatting

• internal links that still work

• images and linked files

Squarespace's guide warns that images might not migrate into self hosted WordPress. WordPress may keep links to the old host instead. Those break when you cancel. Squarespace says WordPress.com copies images to its own servers.

Don't assume a linked PDF became a stored WordPress file either. The media section below gives a practical way to check.

Count unsupported layouts and functions in the estimate. A content export doesn't become an editable copy of the original template, so plan the design deliberately.

What changes when the source is Wix?

Wix works differently again, because its sites must run on Wix's own servers. There's no working site to export. You rebuild the presentation and functions, then move the content and data you're entitled to.

The blog

Wix's help centre says blog posts can't currently be exported to other platforms. Copying posts by hand can suit a small blog. A larger archive may need a specialist or custom process, tested on a sample first.

Don't rely on RSS for the archive either. Wix's RSS feed shows only the 20 most recent posts.

Those numbers are examples. They show the coverage gap, not a real project or proof that 20 posts would import cleanly. Whatever the route, keep what matters:

• post content, authors and dates

• categories and relevant comments

• images and metadata

• a decision on each URL

Test with different post types, not just the newest simple article. Don't assume a migration tool supports every Wix feature. Check it against your sample.

Store data and redirects

Wix Stores exports products to CSV, a spreadsheet style file, with up to 5,000 rows per file. Digital products can't be exported that way. A row count isn't a product count, so read the actual file before promising coverage. Other apps and records need their own assessment.

Export your existing Wix redirect list as evidence. Wix's CSV import takes up to 500 redirects per file. That's a file limit, not a known limit for the whole site. Wix redirects only work on custom domains, not free Wix addresses.

Once the same custom domain serves WordPress, requests reach the new host. Wix's redirect manager no longer handles them. Set up the approved mappings where the site is now served. That could be the host, a content delivery network or WordPress itself. Then test them there.

If the old address is a free Wix subdomain, raise that before approving the project. You can't redirect from it permanently. Update the listings and links you control, and use any visitor notice available. Don't expect search signals to transfer in full.

Inventory the site before importing

Put everything into one inventory. Record public pages and relevant private content, then add the parts people forget:

• existing redirects and external links to current URLs

• media and downloadable files

• forms and the emails they send

• apps, automations and analytics

• advertising that points at specific pages

Keep confidential records in controlled project files. Decide each action from content and business evidence. Low traffic alone doesn't make a policy, support or seasonal page disposable.

Export Search Console and analytics baselines with their date ranges and definitions. Missing or thin data limits what you can conclude. Keep desktop and mobile screenshots for reference, without customer details in them.

Scope decisions sit with planning the new website. For the metadata column, our meta title and description checker helps.

Prove the route on a sample

Run a representative import before estimating the rest. Include these:

• an ordinary text page

• a page with a complex layout

• an older post and one with unusual media

• a product with variants, if you sell online

Record what arrived and what changed. Note what failed and the manual work involved.

Reconcile source and destination by stable identifiers, not titles alone. Keep an exception list and clear duplicates before rerunning. A record count can match while the wrong records or fields came across.

A common mistake is treating the importer's success message as proof that every record arrived.

Build and import on a private environment

Settle the destination before importing anything:

• the host and supported software

• the theme or block system

• integrations and backups

• who maintains it afterwards

An Australian hosting location can suit an Australian audience. It isn't a blanket performance guarantee. For providers, see comparing Australian hosting options.

Build on staging, a private copy of the site. Protect it with real access controls. A noindex instruction only asks search engines not to index a page. It doesn't keep anything confidential.

While you import and test:

• keep production secrets and unneeded personal data out of test copies

• stop customer emails and live webhooks, the automatic messages to other systems

• use the payment provider's test mode

• keep test analytics separate from live data

It's a recommended workflow, not a record of tests run for a client.

Plan the new structure and keep useful URLs where you can. Rebuild templates, navigation and layouts around the content and tasks you're keeping. See planning site structure for the detail.

Stacking a platform change on top of a major rewrite and a redesign adds risk. It also makes problems harder to diagnose.

Import a clean copy, keep the logs and resolve exceptions. Take a backup you can restore before any destructive rerun or bulk change. Use tools that understand WordPress data, not a blind find and replace on the database. Our guide to backups and tested recovery covers the safety net.

Rebuild forms and editing

Rebuild forms and integrations as complete workflows. Test each form end to end:

• validation and accessible error messages

• spam handling and storage

• notifications to the right inbox

• records in your customer database (CRM) and the customer's confirmation

Check the measurement event fires once, at the real success point. A button click isn't a received enquiry. For the setup, see GA4 measurement setup.

Include a staff editing task in acceptance. Check who can preview, approve and publish, and where the recovery instructions live. Record how licences renew. Don't leave the business depending on an unnamed developer account.

Check images, files and missing features

Some media will still point at the old platform after import. Find it before you cancel anything.

Start with your media inventory. Then open rendered pages in your browser's developer tools, on the Network panel. Reload with the cache disabled and look at the URLs actually requested:

• image sources, including the srcset list of responsive sizes

• CSS background images and lazy loaded media

• video posters and social preview images

• download links to PDFs and other files

Look for the old builder's hosts. Examples worth checking include images.squarespace-cdn.com, static1.squarespace.com and static.wixstatic.com. That isn't a complete list.

A visible image isn't proof, because your browser may have cached it. Open representative files directly. Confirm the intended copies sit in the new Media Library or another approved store. Check the responsive variants too.

Classify external references rather than replacing all of them. A video you mean to keep on a third party service can stay. An image tied to a cancelled subscription needs a copy, a replacement or a decision to keep paying. Check usage rights before copying licensed assets.

Here's an example before and after. An image served from https://cdn.oldbuilder.example.com/u/1234/team-photo.jpg should end up at https://www.example.com/wp-content/uploads/team-photo.jpg instead.

Recheck alt text, captions and filenames. Check sizes, cropping and document links with a crawl plus targeted manual checks. Keep a list of unresolved external dependencies. Retest them after the domain change. A common mistake is cancelling the old plan while images still load from its servers.

Plan stores, bookings and member data

Treat commerce, bookings and accounts as their own workstream. A product file doesn't move the business process behind it.

Squarespace's product CSV exports up to 10,000 products. It leaves out:

• additional product information

• customer reviews on products

• featured images and variant images

• product image alt text

WooCommerce's CSV importer maps recognised columns and skips the rest by default. Images must already be uploaded or downloadable from the web. The core importer can't set image alt text. It's a product tool, so orders, customers, bookings and subscriptions need their own plan.

In a pilot, map identifiers and SKUs, the stock codes for each item. Then check variants, prices and stock levels. If the store platform itself is still undecided, see assessing WooCommerce for the store.

Here, agency means your developer or migration partner. Shared means you and the payment or booking provider. A product CSV doesn't move every system on the map.

Plan each record type separately:

Don't export or recreate payment credentials casually. Ask the payment provider which arrangements it supports for stored cards and recurring charges. Don't promise that passwords or payment mandates will transfer. Plan account activation or resets, consent records and customer messages where needed.

Keep one source of truth during cutover

Decide which system is the source of truth while both exist. Depending on the platform, that might mean a short, controlled pause in sales or a specialist reconciliation. Record the final export time and every change since the first copy. Never run two live checkouts or booking calendars selling the same stock.

These figures are examples. Reconcile the 7 new orders and 2 refunds by identifier, status and stock effect. Don't just add 9 to the order count. A refund isn't a new order.

With the authorised team, test:

• tax and shipping settings

• discount rules and confirmation emails

• fulfilment and cancellations

• refunds from start to finish

Keep staging tests from triggering real dispatch or duplicate customer messages. Store required business records securely, under your retention policy.

A common mistake is importing the products and assuming the store has moved.

Preserve URLs and plan redirects

Keep useful URLs unchanged where you can. Give every changed or removed URL a documented outcome:

Keep URL punctuation exact. A Squarespace pattern like /blog/article-name can often be matched in WordPress. The matching permalink structure might be /blog/%postname%/. Check the real slugs, dates and trailing slashes first.

Keeping addresses helps customers and existing links, even where current traffic is low.

Map moved content to the closest relevant page. Avoid redirect chains and loops. Implement redirects where the old URL is actually served, and keep previous redirects too. Google's site move guidance warns against redirecting many old URLs to one irrelevant page, like the home page.

Use server side permanent redirects for permanent moves, then test the final status and destination. Before launch, review:

• content, metadata and headings

• canonical tags (each page's preferred address) and internal links

• structured data and indexing settings

• references to the live address, not staging

Update sitemaps and internal links to the final URLs.

A hosting move that keeps the same public URLs is a different job from a URL change. Google's hosting change guidance covers that case. Don't use Search Console's Change of Address tool for a platform move that keeps your domain. The full workflow lives in the detailed migration SEO checklist.

Search visibility can fluctuate during a move. A planned move doesn't guarantee rankings, or recovery within a set number of days.

A common mistake is forgetting the redirects the old site already had.

Keep domain and email decisions separate

A website move doesn't require changing your domain or transferring its registration. First, identify who handles each part:

Here, you means the business account holder and agency means your web host or developer. Shared means you and the provider for that service. One supplier can fill several roles. Plan each change separately anyway.

DNS is the set of records that points your domain at each service.

Wix and Squarespace domains

A domain registered with Wix can point at the new host. It can also use custom nameservers while staying registered at Wix. Wix asks you to unassign the domain from the site first. It also needs both nameservers from the new provider.

Changing nameservers moves who serves your DNS. Wix's own records then stop working. Email routing stops too, unless the new provider has the right mail (MX) records. Wix also can't renew the SSL certificate through DNS after the switch, so check HTTPS afterwards.

With Squarespace, you can keep the registration there and point it at the new host. You can also plan a separate transfer. Transferring away doesn't move your hosting or cancel the subscription. Check mailboxes separately with your email provider. A transfer can take up to 15 days.

Australian domains have their own rules. Squarespace says .au and .com.au domains don't carry the 60 day lock other domains can have. Check the actual domain and registrar rules before planning dates.

Records and email

Before changing anything, record every DNS entry:

• A, AAAA and CNAME records

• MX records for email, plus TXT records for verification

• SRV records some apps rely on, and any subdomains

• DNSSEC, a security layer for DNS, and certificate settings

Keep the email and service records you need. Change the website records deliberately. Don't leave an old AAAA (IPv6) record sending some visitors to the previous host.

Test inbound and outbound email, plus form notifications. Keeping MX records alone doesn't recreate mailboxes, billing access or every authentication setting. Ask the responsible provider to verify the setup, including any DNSSEC change.

Don't schedule an optional registrar transfer on the same day as the website cutover without a reason. Record each change and its previous value. Note who made it and how to reverse it. Cached DNS means a reversal isn't instant.

A common mistake is changing nameservers before copying the email records across.

Launch only after the essential checks

Treat launch as a series of gates, not a date.

It shows order, not elapsed time.

Arrange a valid certificate for every production hostname alongside the DNS change. Check HTTPS works when the new host starts serving traffic. Never leave a payment or login page on an invalid certificate to fix later.

At launch, remove staging only index blocks from the live pages. Keep access controls on anything private. Make sure an old staging address doesn't stay public as a duplicate.

Name one person who makes the go or no go call. Agree the criteria first, where they apply:

• critical content and enquiry delivery

• bookings or checkout, end to end

• email delivery and redirects

• logins and the recovery plan

A high checklist score doesn't make up for a failed transaction path. Include complete tasks with a keyboard in acceptance, using our guide to testing website accessibility.

Define recovery before launch:

• what triggers a rollback, and who decides

• whether the old setup is still ready

• how DNS or routing reverses

• how new orders and messages are handled

Restoring an old snapshot can discard new orders or submissions. Reconcile the changes rather than assuming a backup solves it.

Run live checks straight after cutover, with permission. Check the public site from a fresh browser, not a logged in admin session. Keep the old service available until acceptance and dependency checks justify retiring it. The website launch checklist covers the wider checks.

What affects cost and timing?

Budget for two jobs: the rebuild and the migration itself.

We haven't published a dedicated migration price. For context, our website design and build page lists Starter builds at $2,400 to $5,000. Business builds are $5,000 to $12,000. Both are AUD, excluding GST, and neither is a migration quote.

Ask for separate prices for:

• migration and content work

• commerce and integrations

• licences and testing

• overlap with the old services

Here's a fictional first year budget, in AUD excluding GST:

A separate $550 contingency brings the planning allowance to $7,510. In a real quote, avoid counting bundled costs twice.

The estimator doesn't replace a migration quote or check a budget. For the wider picture, see website build cost planning and ongoing WordPress maintenance costs.

These timing scenarios are example planning ranges, not Elev8d averages or promises:

Custom membership or booking work needs its own estimate. These things move the timeline:

• unsupported content and archive size

• product variants and integrations

• approvals and any redesign

• missing access and final data reconciliation

Count your staff's time and payment timing too. Our general build estimate doesn't replace a migration schedule.

Monitor and hand over the new site

Use review windows, not deadlines. Straight away, check that:

• the site loads over HTTPS

• email and essential tasks work

• redirects and measurement behave

In the first week, investigate errors and reconciliation exceptions. Over the following weeks, review search and qualified outcomes. Performance and staff workload count too.

Compare like periods and definitions. Note changes in season and advertising. Changes to the offer or tracking matter too. Having no search data yet isn't a confirmed failure. A serious functional fault needs fixing now, not at the monthly report.

Here's a final checklist by stage:

At handover, record:

• business owned access and licences

• maintenance and support responsibilities

• backup and recovery arrangements

• renewal dates for every service

Our guide to website access and developer handover covers the detail.

Apply the check to each subscription and system, not the provider account as a whole. Cancel only services confirmed unnecessary, after keeping the records you need. Domain, email and scheduling subscriptions may still be needed after the website plan ends.

A common mistake is cancelling the whole account and taking email or the domain with it.

What we recommend at Elev8d

Frequently asked questions

Next steps

Pick the situation that fits.

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.