Supported scope
- Wix Blog posts, categories, tags, authors, and accessible attachments
- Supported static pages and navigation from the legacy extraction path
- WordPress posts, pages, taxonomies, authors, media, slugs, and publication state
Wix → WordPress
Wix to WordPress Migration
Move supported Wix content into a prepared WordPress site through one controlled workflow: analyze the source, confirm mappings, run a dry run, validate the result, and complete the full transfer.
Self-service migration path
Start with your actual Wix data
Source and target connectors are available. wix: Available. wordpress: Available. Review system status and directions. Available migration objects and capabilities depend on the selected source and target systems.
Create an account, connect a staging destination, and let the app analyze the supported scope for this direction.
No credit card required to analyze the migration and run a free sample.
Scope
What can move and what needs review
The app confirms available entities after connection. Final coverage depends on source access, downloadable assets, and the destination model you prepare.
Confirm after connection
- Author identity, target menu support, SEO field implementation, and media acceptance
- Multilingual content, dynamic collections, source access mode, and destination custom fields
Separate or custom work
- Page-builder layout reconstruction
- Custom WordPress post types, ACF relationships, or bespoke adapters
Before you connect
Access requirements
Use a staging destination and the least-privilege access supported by each platform. Do not send credentials through a public form.
Wix REST access
Provide the Wix site details and an OAuth access token with the required Blog and Members read permissions. REST is the preferred path for current blog data.
Wix legacy access
Provide a public Wix site URL whose supported public payload remains accessible. This path is reviewed for static pages and menus before it is accepted.
WordPress staging access
Provide the staging site URL and an Application Password. A compatible Migranetix Bridge may be required for broader destination entity coverage.
How it works
From connection to full migration
You control each stage in the app. Optional expert assistance is available for custom data or destination requirements.
01
Choose Wix and WordPress
Start in the app and select the real source and target.
02
Connect both systems
Authorize read access to Wix and connect a prepared staging WordPress destination.
03
Analyze the source
Review detected records, available entities, media, URLs, and anything that needs a decision.
04
Confirm the mapping
Choose where supported Wix data belongs in the prepared WordPress model.
05
Run a free sample migration
Move a small set of real records to staging and inspect the result before purchasing the full migration.
06
Validate and launch
Review counts, records, media, links, warnings, and exceptions, then purchase and start the full migration when ready.
Technical detail
Platform-specific migration notes
Open only the detail you need for planning, mapping, or validation.
Current app compatibility
This page is synchronized with the Wix source and WordPress destination capability snapshots. Wix is currently enabled as a source platform only; WordPress is enabled as both a source and target.
Wix source adapter
REST mode reads Wix Blog records through OAuth. Legacy mode can additionally read supported static pages and navigation when the required public Wix payload is available.
WordPress destination adapter
Authenticated REST and versioned Bridge adapters support a prepared WordPress destination model. Wider entity coverage still depends on target authorization and configuration.
Wix to WordPress compatibility matrix
Standard means the current adapters expose a direct path. Review means the data is mapped but depends on source mode, destination authorization, or implementation choices. Custom means it is not a standard configured Wix entity.
| Wix source | WordPress target | Status and boundary |
|---|---|---|
| Blog posts | Posts or a prepared custom post type | Standard: REST and legacy source paths are supported. |
| Blog categories | Categories or another taxonomy | Standard: source IDs are resolved to destination term IDs. |
| Blog tags | Tags or another taxonomy | Standard: relationships are rebuilt after term creation. |
| Wix members used as authors | WordPress authors | Review: identity and email matching are supported; passwords and full membership behavior are not promised. |
| Post attachments | WordPress media | Standard with validation: each source file must remain downloadable and be accepted by WordPress. |
| Static pages | WordPress pages | Review: available through the legacy Wix extraction path, not the current REST adapter. |
| Menus and menu hierarchy | Menus and menu items | Review: requires legacy Wix extraction plus supported WordPress target authorization. |
| Page slug and SEO fields | WordPress slug, SEO fields, and redirect plan | Review: legacy page extraction supplies supported metadata; target SEO storage depends on the destination setup. |
| Old Wix URLs | WordPress or hosting redirects | Delivery artifact: redirects are generated from the approved URL map rather than treated as a Wix entity. |
| Blog comments | WordPress comments | Not standard: the app has no configured Wix comments source entity. |
| Stores, products, orders, bookings, contacts, or plans | WooCommerce, plugins, or custom records | Custom: these are not standard configured Wix source entities. |
| Design, forms, apps, and Velo logic | Theme, blocks, plugins, or custom code | Rebuild: visual design and application behavior do not transfer as content records. |
Example mapping rules
The approved mapping workbook becomes the migration contract. It records source identity, destination fields, transformations, dependencies, and exception handling.
| Wix value | Migration rule | WordPress result |
|---|---|---|
| Post ID | Preserve as source identity in the migration dataset and ID map | Stable post ID lookup for updates and delta runs |
| Title, body, status | Normalize content and translate publication state | Post title, content, and status |
| Category and tag IDs | Load terms first, then resolve dependency IDs | WordPress category and tag relationships |
| Member ID and email | Match or create an approved author identity | WordPress author assignment without password migration |
| Attachment URL | Download, validate, upload, and record failures | Media attachment and rewritten asset reference |
| Page slug and metadata | Build the URL map and approved SEO transformation | Destination slug, SEO metadata, and redirect requirement |
SEO and URL cutover
A platform move changes templates, internal links, media paths, and often URL patterns. The migration keeps those changes visible and testable.
URL inventory and redirects
Crawl the live Wix site, pair every indexable source URL with its approved WordPress destination, and flag gaps before launch.
Metadata and canonicals
Carry supported titles, descriptions, slugs, and source references into the destination model, then verify the WordPress SEO implementation.
Links, media, and sitemap
Rewrite internal references, validate downloadable assets, generate the destination sitemap, and test redirects in staging and after cutover.
Post-launch monitoring
Watch crawl errors, indexation, redirect chains, analytics, and high-value landing pages during the agreed stabilization window.
Validation and acceptance
A completed import is not automatically an accepted migration. Sign-off is based on reconciled records and documented exceptions.
Counts and samples
Compare source, extracted, loaded, skipped, and failed totals, then inspect representative simple and complex records.
Relationships and assets
Verify authors, categories, tags, parent-child links, menu hierarchy, featured media, inline media, and documents.
Rendering and SEO
Test content rendering, internal links, metadata, canonical rules, sitemap entries, old-to-new redirects, and key conversion paths.
Exception register
Classify every unresolved item as corrected, accepted, deferred, or custom scope before final approval.
Before purchase
Verify real output in staging
The free sample migration creates a limited set of records in staging. Check fields, relationships, media, URLs, rendering, and reported exceptions before paying for the full run.
Pricing
One migration, one-time payment
Package fit depends on supported record volume and complexity. Analyze the source first, then review the fixed package or dynamic estimate shown for the migration.
Compare migration packagesPlan the move
Wix to WordPress guides
Wix migration cost
See what affects the price before starting.
Open guide →Export Wix content
Prepare the source and understand Wix access limits.
Open guide →Wix SEO checklist
Protect URLs, redirects, metadata, and tracking.
Open guide →WordPress migration guide
Prepare the destination content model and access.
Open guide →Clear answers
Frequently asked questions
No. The standard app scope covers configured blog entities plus supported legacy pages and menus. Stores, bookings, contacts, plans, app records, and custom behavior require separate discovery and scope.
OAuth is required for the current Wix REST path. A legacy public-site path may be available for supported pages and menus, but it must be tested against the source site.
Not as portable content data. The WordPress theme, blocks, templates, forms, interactions, and responsive behavior are rebuilt or implemented separately.
They are not standard configured entities in the current Wix adapter. First inventory the business data and then define a custom extraction and destination model if feasible.
No password migration is promised. The app exposes Wix members as author identities for blog ownership, while WordPress authentication and membership behavior require separate scope.
No provider can guarantee rankings. Reduce migration risk with URL mapping, redirects, metadata transfer, internal-link updates, sitemap checks, analytics, and post-launch monitoring.
Yes. Representative data is loaded into staging, systematic issues are corrected, results are reconciled, and the approved rules are reused for the final or delta run.
Next step
Assess your Wix to WordPress migration
Create an account, select Wix and WordPress, and use the app to analyze scope before committing to the full migration.