Wix to WordPress migration UK

Wix is harder to leave than Squarespace. That is the headline. Where Squarespace at least gives you a WordPress-compatible XML export for blog posts and basic pages, Wix gives you almost nothing. No native full-site export. No pages export. No structured content export of any kind for most of what sits on your site.

I have moved a handful of UK Wix sites to WordPress. Every one of them was a rebuild dressed up as a migration. That is not a complaint, it is a planning decision. Once you accept that the rebuild is the project, the rest becomes manageable.

This is a planning-level walkthrough. Concepts not clicks, because the Wix editor and the WordPress admin both shift around enough that any step-by-step guide goes 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.

What you can and cannot take out of Wix

The thing that catches every team is the gap between what Wix lets you take and what you assume you will be able to take.

Wix gives you an RSS feed of recent blog posts, capped at roughly the last 20 entries depending on the configuration. That is the only structured export route Wix offers natively. Beyond those 20 posts, the blog content has to be scraped or rebuilt manually.

Pages have no export at all. Every page on the Wix site, from the homepage to the about page to every service page, has to be rebuilt manually on WordPress. The same is true for forms, form submissions, products in Wix Stores, bookings in Wix Bookings, members in Wix Members, events, restaurants, anything the editor built using Wix apps.

Design and layout stay on Wix. There is no template file, no CSS export, no design asset package. The visual identity, as implemented on Wix, exists only inside Wix's proprietary editor.

Third-party migration services fill some of the gap. Several paid services will scrape Wix content and push it into WordPress for a flat fee. They work, with caveats. They are good at posts and basic page content. They are unreliable at anything generated by a Wix app, at custom layouts and at structured data the Wix editor never exposed in the first place. Treat them as a head start, not a finish.

Audit before you touch WordPress

Most of the work in a Wix migration is in the audit and rebuild, not in moving data. Get the audit right and the rest becomes routine.

• Page inventory. Every live URL with its purpose and what is on it. A crawl of the live site plus a manual walk-through is the fastest way to build this.

• Wix apps in use. Wix Stores, Wix Bookings, Wix Members, Wix Events, Wix Restaurants, Wix Hotels, Wix Forms, anything from the Wix App Market. Each app needs a WordPress equivalent decision.

• Blog and content collections. Post count, frequency, authors, categories, tags. Plus any Wix Velo collections holding structured data.

• Forms and submissions. Every form, where it sends data and whether past submissions matter. If they do, export the history before the move because Wix does not always retain it after a subscription change.

• Members and gated content. Member list, what content is gated, subscription model if any, login email addresses.

• Commerce. Product list, variants, inventory, customer accounts, order history, payment gateways, tax rules, shipping zones, abandoned cart data.

• Velo custom code. Wix Velo is the JavaScript layer Wix exposes for custom logic. If the site uses it, list every Velo file and what it does. None of it transfers. It all gets rewritten in PHP or as a WordPress integration.

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

Until that audit is written down, scoping the rebuild is a guess. For Wix migrations specifically, the audit usually surfaces two or three Wix apps the team forgot were doing work and those find their way onto the scope late and over budget if not caught early.

URL structure and the Wix legacy problem

Wix URLs follow a few patterns that are predictable enough to plan against. Modern Wix sites use clean paths like /service-slug or /post/post-slug. Older Wix sites, particularly anything built before Wix moved off its hash-bang router, used URLs with /#! prefixes that confused search engines for years.

If the Wix site is old enough to have lived through the hash-bang era, check what Google has actually indexed. Some sites will have both old hash-bang URLs and modern URLs in the index for the same content. The migration is a chance to consolidate to one canonical URL per page, but you have to know what the index looks like first.

Export every live URL from Search Console, the sitemap if Wix is generating one and a fresh crawl of the site. The output is a spreadsheet with the old URL on one side and the WordPress destination on the other.

WordPress permalink settings give you enough control to mirror most Wix patterns. Where you cannot match exactly, 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.

Wix ADI versus Wix Editor X versus the classic Editor

It matters which Wix product the source site was built on, because the rebuild path differs slightly.

Sites built with Wix ADI, the simplified AI-driven builder, are usually the easiest to rebuild because the page structure is constrained and predictable. You can often reproduce them with a stock WordPress theme and minimal page builder work.

Sites built with the classic Wix Editor are pixel-positioned, which is fine on the canvas but awkward to translate. Pixel layouts do not map to WordPress out of the box. The rebuild is a redesign that respects the existing brand rather than a faithful reproduction.

Sites originally built with Editor X, the responsive-first editor Wix retired and folded into Wix Studio in early 2025, are closer in spirit to a modern WordPress block theme. The information architecture usually transfers cleanly even if the components themselves have to be rebuilt.

In every case the design itself needs to be remade. The migration is the right moment to redesign rather than try to replicate the Wix look pixel for pixel, because matching it exactly costs more than picking a WordPress design that already fits the new platform.

Design rebuild

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. 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.

Forms and Wix app replacements

Forms move to a WordPress form plugin. Gravity Forms, Fluent Forms, WPForms, Forminator. All are mature and any will do the job. Past submissions live in CSV files outside the CMS unless someone explicitly needs them inside it.

Wix Bookings moves to a WordPress booking plugin. Wix Restaurants moves to a sector-specific plugin if one fits. Wix Events moves to a calendar or events plugin. Wix Members moves to a WordPress membership plugin. Wix Stores moves to WooCommerce.

The mapping is rarely one to one. Each WordPress plugin has its own model and the migration is the right moment to reassess whether the original Wix app was even being used as intended. Most teams find one or two Wix apps they were paying for but no longer needed.

Ecommerce: Wix Stores to WooCommerce

Wix Stores exports products to CSV with the basic fields. Title, description, price, SKU, stock, images, variants. The export is incomplete in practice. Variant pricing, product options and complex shipping rules rarely come through cleanly. Plan to either reshape the CSV before import or use a third-party migration tool that handles the mapping for you.

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.

On the gateway side, Wix Payments locks you into the Wix-owned payment processor. 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.

Assets and the media library

Wix hosts images on its own CDN. When you scrape or import Wix content, the image references usually point at the Wix CDN and remain hotlinked until you actively pull the files in.

A WordPress plugin that rewrites image URLs after import fixes this for blog content. It pulls the files onto the new host. Run it before you turn the Wix site off. Hotlinked images break the moment the source disappears and a Wix site that has been moved away from often loses access to its CDN sooner than you would think.

Images embedded in pages, products and members areas need to be downloaded and re-uploaded manually or through a custom script. Budget time for this. For a site with a few hundred images it is half a day. For thousands it can be a full week.

SEO carry-over and the Wix upside

Wix has historically had a reputation for weak SEO. Some of that is fair, some of it is outdated. Modern Wix sites perform reasonably well technically, but the level of control over meta data, schema, sitemaps and crawl directives is still limited compared to WordPress.

Moving to WordPress is one of the few migrations where the platform you arrive on gives you more SEO control than the platform you came from. That is an upside. The catch is that any technical SEO issues that existed on Wix do not vanish on WordPress. A site that was thin on content will still be thin. A site that lacked internal linking will still lack it. The migration is a chance to fix these, not a guarantee they will fix themselves.

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

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

Domain and DNS cutover

If the domain is registered through Wix, plan to move the registration as well. Wix lets you do this but the process is slower than moving DNS records. The pragmatic order is to point the domain at the new WordPress host first using DNS, then move the registrar later once everything is stable.

Lower the DNS TTL on the apex record a day or two before cutover so propagation is fast when you switch. 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.

Training the editors

WordPress is more flexible than Wix and slightly less visually direct. Editors used to dragging elements around the Wix canvas 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 reference for those tasks is usually enough. If the build uses a page builder, anchor the training to the page builder. Editors do not need to understand the WordPress dashboard, 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 Wix site. They never share data.

• Run a content freeze on Wix 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 Wix subscription paid up for at least a month after launch. If something catastrophic surfaces, you can point DNS back at Wix and triage without pressure. Once two weeks of clean monitoring are behind you, archive what you can scrape out of Wix as static HTML and 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.

For Wix migrations this matters slightly more than most because so much of the move runs through third-party scraping or migration tools. Log which data leaves Wix, who handles it during the transfer and that the new host is covered by the same UK GDPR commitments. For ecommerce and members areas the exposure is higher. For a brochure site with a contact form it is mostly a documentation exercise.

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, Wix apps, 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 Wix site looks like. You can also see what WordPress development and ongoing WordPress support look like as freelance engagements.