A Wix to WordPress migration usually combines content transfer with rebuilding. Pages, blog posts, images, business records, and app features do not all move through one universal export, and a Wix design does not become a WordPress theme automatically.
Start by inventorying what the existing website does and which addresses customers use. Choose a transfer method for each content type, rebuild the necessary features on a protected WordPress site, verify media and URLs, and plan the final domain change separately from email and account ownership.
This guide focuses on a business website moving to WordPress, including the differences between self-hosted WordPress and WordPress.com’s hosted import options. It does not promise an exact visual clone, automatic transfer of every app, or unchanged search rankings.
Decide what the migration should improve
Write down why the business is moving. You may want more control over content structure, a custom integration, different commerce capabilities, or a maintenance arrangement that fits the business.
Keep those goals specific. “Use WordPress” is a platform choice; “staff can edit service pages without changing the layout” is an operational outcome. “Add a booking workflow with the required calendar connection” is another outcome that can be tested.
Separate required continuity from optional redesign. You can retain useful content and addresses while improving the design. If the project also changes branding, navigation, copy, and business tools, identify that broader scope before estimating the work.
Choose an owner for content approval, a technical migration operator, and a launch decision-maker. The person who approves colors may not be the person who can confirm how leads should enter the CRM.
Understand the destination before choosing an importer
WordPress software can run on many hosting platforms. WordPress.com is a hosted service with its own features and plan-dependent capabilities. A tutorial for its dashboard does not establish that the same importer exists on every self-hosted installation.
The current WordPress.com Wix import guide describes a hosted import of selected pages, images, menus, and site information, while noting compatibility limits and separate work for blog content and design. Verify that option directly if WordPress.com is your chosen destination.
For self-hosted WordPress, plan the supported tools and manual work available in that environment. You may use selected exports, a reviewed third-party service, or structured reconstruction. Do not purchase a tool solely because its name suggests it can transfer the whole site.
Choose hosting around the application
List required plugins, custom code, storage, backups, staging, and support. Confirm the intended host supports those needs and provides appropriate recovery access.
Avoid selecting infrastructure only by the smallest introductory price. Check the actual renewal terms and who maintains the application. A migration is a useful moment to establish business ownership of hosting, DNS, backups, and licenses.
Keep access under the business’s control and use delegated accounts for contractors where practical. Credentials belong in the approved password manager, not in a shared migration document.
Inventory content and functionality separately
Content is the information people read or download. Functionality is what the site does with their actions. A page containing a booking widget can have transferable text while its booking system requires a separate implementation.
Create two lists. The content list should include pages, posts, categories, images, downloads, metadata, and important URLs. The functionality list should include forms, bookings, store operations, memberships, search, languages, automations, and external integrations.
| Existing element | Migration question | Evidence needed |
|---|---|---|
| Service page | Transfer content or rebuild manually? | Copy, media, URL, title, and final rendering |
| Blog archive | How will all posts be captured? | Source inventory and imported post reconciliation |
| CMS collection | How will fields and relationships map? | Export sample and destination data model |
| Contact form | Which behavior must be rebuilt? | Validation, storage, delivery, and CRM result |
| Booking or store feature | Which records and integrations are supported? | Tool-specific scope and end-to-end tests |
| Domain and email | What changes and what stays? | Account ownership and DNS/service map |
Do not use a page count as the entire project estimate. A small site with complex bookings can require more planning than a larger collection of straightforward articles.
Preserve the source before rebuilding
Keep authorized access to the Wix dashboard and the public site during preparation. Save available exports and original media in a protected project location, and record when they were captured.
Capture important page layouts and interactions for reference. Screenshots can guide reconstruction, but they do not preserve working forms, dynamic data, or every responsive state. Record the behavior as well as the appearance.
Preserve domain, DNS, email, and billing ownership information. Canceling the source subscription too early can remove access or assets still needed for the move. Confirm the actual service dependencies before ending anything.
Keep private contact or customer exports protected. A migration archive should not become a public download folder containing personal information. Restrict access to the people who need the data and define its retention after launch.
Plan blog migration around the actual available content
Wix’s blog-export request page documents the platform’s current export limitation. Its RSS documentation describes a feed limited to the most recent 20 posts at the time of this research.
An RSS route can therefore help with a small recent set, but it is not evidence that an older archive moved completely. Compare the source post inventory with the destination rather than counting only what an importer found.
For a larger archive, choose a documented service, authorized extraction process, or manual content workflow that covers the missing material. Confirm its handling of titles, dates, authors, categories, links, media, and duplicate detection.
Reconcile posts by identity, not only totals
Two sites can show the same post count while containing different posts or duplicates. Keep a mapping from source URL or stable source identifier to the destination record.
Check the oldest posts, recent posts, posts with galleries, posts with unusual formatting, and posts with downloads. Review representative content types rather than only the first imported article.
Preserve publication dates and authors accurately when they are known. Do not assign invented dates or credentials to make the new archive appear complete. If author mapping is needed, have the owner approve the legitimate destination account.
Inspect internal links inside the articles
Imported text may still link to old platform URLs, temporary domains, or image endpoints. Update the links that should point to the new site through a reviewed process.
Distinguish links to your own pages from legitimate external citations. A blanket replacement of every occurrence of a domain or brand can alter material that should remain unchanged.
Test anchored links, downloadable files, and related-post references. A post that looks correct in the editor can still send readers to an obsolete destination.
Map CMS collections to a deliberate WordPress structure
Wix provides CSV export for CMS collections. That export preserves selected data; it does not by itself recreate dynamic templates, permissions, relationships, or front-end behavior in WordPress.
Decide how each collection should be represented. A directory, team list, property catalog, or service database may need custom post types, fields, taxonomies, or a purpose-built plugin. Choose the model before importing thousands of rows.
Create a field map with source field, meaning, destination field, type, transformation, and validation. Preserve identifiers needed for relationships and later reconciliation. Pay attention to time-zone interpretation for exported time values.
Test a representative sample first
Use a small sample containing ordinary records and edge cases: empty optional fields, long text, multiple images, linked records, and unusual characters. Verify how those values appear and behave in the destination.
Do not convert every value to plain text simply to make an import succeed. Dates, numbers, links, and relationships have different responsibilities. A destination that displays the text may still fail filtering, sorting, or access rules.
After mapping is verified, run the broader import through the supported process and reconcile records. Keep the original export unchanged so transformations can be reviewed and repeated.
Rebuild design through a maintainable system
Choose a WordPress theme and editing approach that supports the required pages and the staff who maintain them. Recreate the useful design language—typography, colors, spacing, navigation, and image treatment—without assuming a Wix template can be installed directly.
Build a small set of reusable page patterns before reconstructing every page. A service-page pattern, article template, and landing-page layout can provide consistency while reducing repetitive manual styling.
Preserve meaningful headings, readable content, descriptive links, and mobile navigation. A visually similar page can still differ in accessibility or search interpretation if its structure changes carelessly.
Keep custom code and purchased assets legitimate and documented. Check the licenses for fonts, photographs, icons, and templates instead of assuming every item visible on the old site can be reused under the same terms.
Treat forms, contacts, and automations as separate work
A form’s visible fields are only part of its behavior. Record required inputs, validation, attachments, consent choices, confirmation messages, stored records, notifications, and downstream integrations.
Choose the destination form system according to those requirements. Rebuild the form on the protected WordPress environment and use controlled recipients and fictional test details.
Confirm the actual result in the receiving mailbox or CRM. A browser success message does not prove that the business received the lead. If the form stores submissions, inspect that record and its access controls as well.
Preserve contact data without inventing consent
Wix documents contact export options. Review which fields and statuses the selected format includes before importing the data into a new CRM, form system, or mailing service.
A contact record is not automatically a WordPress login or permission to receive marketing. Preserve the meaning of subscription status, labels, and relevant source information. Have the business decide how those records should be used under its existing policies and obligations.
Do not send a bulk welcome or password-reset campaign merely to see whether the import worked. Use controlled test records, coordinate any customer communication, and avoid changing the relationship represented by the source data.
Recreate automations deliberately
List each trigger and action: a form creates a lead, a booking sends a reminder, a purchase changes access, or a tag starts a sequence. Identify which system owns the action and what prevents duplicates.
Rebuild the necessary paths in the selected WordPress and external tools. If the old automation remains active during transition, decide which system is authoritative so one customer action does not produce two records or messages.
Test success, validation failure, and a relevant retry path. A reliable integration should not create duplicate work simply because a network response is delayed. Record the behavior your chosen tools actually support.
Give bookings, memberships, and commerce their own plan
If the Wix site sells products, accepts appointments, or grants paid access, confirm what data can be exported and what the destination tool can import. Do not treat a page-content importer as a transactional migration service.
Inventory products or services, customer records, open orders or bookings, payment relationships, refunds, inventory, membership rights, and recurring obligations. Map each to a supported destination or an explicit transition procedure.
Customer authentication and recurring billing deserve separate verification. Do not promise that passwords, payment tokens, or subscriptions transfer automatically. Coordinate the supported process with the actual application and payment providers.
Decide which system handles existing obligations
A future booking, unfulfilled order, or active membership must remain serviceable after launch. The business may retain source access for historical or operational needs while new activity starts in WordPress, but that boundary must be documented.
Identify who handles refunds, cancellations, rescheduling, and customer questions for pre-migration records. A new storefront does not erase obligations created in the old system.
If a specialist migrates transactional records, test the relationships and next actions, not only the visible list. Imported history should not trigger unwanted receipts, fulfillment, access changes, or duplicate charges.
Move media into an owned and verifiable destination
An image can appear on WordPress while still loading from a Wix-hosted URL. That is not proof that the asset has been transferred to storage the business controls for the new site.
For important images and downloads, record the source, legitimate rights, destination file, and page usage. Obtain originals through authorized means where available and preserve meaningful filenames and descriptions.
Verify that the destination media exists and is served through the intended storage route. Test representative images at mobile and desktop sizes and confirm that downloadable files remain accessible to the intended audience.
Rebuild galleries and responsive behavior
A gallery is more than a list of images. Record ordering, captions, links, lightbox behavior, crop choices, and mobile presentation. Recreate the useful behavior through the selected WordPress component.
Avoid uploading the largest original everywhere without checking delivered dimensions. A new theme can accidentally request oversized images or crop important content. Confirm actual requests and visible output.
Write alt text that describes the image’s purpose in context. Preserve useful existing text where accurate, and avoid filling every image description with the same keyword. Mark decorative images appropriately in the final implementation.
Verify files after the source is no longer needed
Before canceling the source service, inspect asset URLs and test the destination’s own files. A browser cache can conceal dependence on the old storage, so use an appropriate fresh request and examine the actual destination.
Keep the original archive protected until the content and media acceptance is complete. A missing downloadable guide may not be noticed during a homepage review but can affect a valuable landing page later.
Preserve URLs and useful search signals
Build a source URL inventory before changing public routing. Include pages found in navigation, sitemaps, analytics, search data where available, and important external campaign links.
Choose destination URLs deliberately. Keep existing paths where practical, and map changed addresses to equivalent content. Google’s site-move guidance explains the role of permanent redirects and related signals when URLs change.
Recreate important titles, descriptions, headings, canonical behavior, and structured data using accurate destination content. Do not copy misleading or obsolete metadata simply because it existed before.
Put redirects where requests will arrive
When a custom domain moves to WordPress, the new serving environment can handle appropriate old-path redirects on that domain. Confirm that the selected host or application can match the actual source paths.
A free platform subdomain is different because you may not control the server that receives those old requests. Investigate the source platform’s current options and avoid promising control you do not have.
Test redirects using real representative old addresses. Confirm the final page, status, and absence of loops or unnecessary chains. A spreadsheet map is a plan until the serving system actually implements it.
Avoid broad homepage redirects
If an old page has a close replacement, send visitors there. If it has no appropriate replacement, decide how it should retire through the site’s content and search plan.
A blanket redirect to the homepage can confuse readers and search engines. It also hides the distinction between missing content and a deliberate consolidation.
Update internal links to the final addresses. Navigation, article links, image links, and downloadable references should not rely indefinitely on a redirect chain to reach the intended destination.
Keep domain and email decisions separate
You can often connect an existing domain to new hosting without transferring the registration at the same moment. Confirm the available process with the registrar, DNS provider, and chosen host.
Record the current DNS zone and the specific web changes required. If nameservers change, recreate all required records, including mail and verification records, before delegation changes.
Do not assume that moving a website transfers Google Workspace, another mailbox service, or transactional email settings. Confirm account ownership, billing, DNS, and delivery independently.
Test both employee email and site notifications
Send and receive controlled messages through the business’s actual mailbox service. Then submit a controlled WordPress form and check its separate notification path.
The new application may use a transactional provider, authenticated SMTP, or another supported route. Verify sender identity and the intended receiving system. A working employee inbox is not a test of WordPress sending.
Keep renewal and billing ownership clear. A source account can sell several services, and canceling the wrong subscription may affect more than the old website. Review the actual dependency before ending service.
Prepare a launch that preserves final changes
The source site can change while WordPress is being built. Record which content and records may continue changing and how the final differences will be captured.
For a simple content site, a short coordinated editing pause and final review may be enough. For bookings or commerce, identify every writer, including staff, APIs, webhooks, and scheduled actions. A public holding page may not stop them all.
Keep one authoritative system for each operational responsibility. If old bookings remain in Wix while new bookings begin in WordPress, make that distinction clear to staff and customers where necessary.
Preserve the final source exports and the prelaunch WordPress backup. Do not overwrite the only copy of newer data with an earlier import simply to make the destination look familiar.
Review production settings before routing traffic
Confirm the final domain, secure certificate, intended payment mode, actual mail route, role permissions, and public indexing configuration. Test environments often contain restrictions that should not be copied blindly to the public site.
Google’s noindex documentation explains why an indexing directive is different from access protection. Keep staging private while allowing intended production pages to become discoverable.
Check that temporary domains and source URLs do not remain in canonical links, sitemaps, navigation, or customer messages. Review the rendered output rather than only the editor fields.
Test the rebuilt business workflows
Use a short acceptance record tied to the final candidate. Include the page, role, action, expected result, observed result, and any blocked or untested external step.
For a service site, test mobile navigation, phone links, contact forms, downloads, and the receiving mailbox or CRM. For a booking site, check availability, time zones, confirmation, and the intended calendar.
For a store or membership application, use supported test facilities and representative conditions. Coordinate any necessary live payment with the business and fulfillment staff. Check allowed and denied access where the feature grants rights.
The WooCommerce conflict-testing guide provides a useful isolation approach if a rebuilt commerce workflow fails. Diagnose the specific combination rather than changing many unrelated settings together.
Check editing and maintenance, too
Have the person who will maintain content perform a controlled edit. Confirm they can update the intended fields without breaking reusable layout or gaining unnecessary administrative access.
Verify a fresh backup and the recovery route. The WordPress file-backup and database-backup guides describe separate parts of the new recovery plan.
Record licenses, custom code, integration owners, and support responsibilities. A successful launch should leave the business with a maintainable application, not only a finished screenshot.
Audit imported data before declaring completion
Use a reconciliation table that compares source identity, destination identity, transfer method, and verification status. Keep the source export unchanged and document transformations separately.
Counts are helpful for spotting omissions, but they do not establish correctness. Review representative records and relationships. A directory with the right number of entries can still have images attached to the wrong entries.
Check formatting, special characters, date interpretation, and links. Spreadsheet tools can change identifiers or values if data types are not handled deliberately. Preserve source identifiers as identifiers, not as numbers that can be reformatted casually.
Classify exceptions instead of hiding them
Mark each unresolved item as missing content, unsupported feature, intentional retirement, or pending verification. Assign an owner and next action.
If a feature cannot transfer, document the replacement or transition plan. The business may accept a different implementation if it meets the requirement, but that decision should be explicit.
Do not mark an unsupported item complete because a new page contains similar text. Functional equivalence requires the relevant action and result, not only a visual resemblance.
Use a realistic migration handoff
The handoff should identify the live hosting and DNS owners, final URL map, transferred content, rebuilt features, known limitations, backup arrangements, and maintenance responsibilities.
Include a short release record with the final data boundary and completed acceptance checks. Keep private exports and credentials out of a broadly shared owner guide.
Give staff instructions for handling pre-migration records that remain in the source system. They should know where to find an old booking, refund, contact, or document and who can authorize changes.
Remove temporary access when work ends. Retain the source account only as long as its real dependencies and record needs justify it, with an owner and review date.
Use content-specific acceptance checks
Different content types need different evidence. A generic “looks good” approval can miss important details that only appear outside the homepage.
Service and landing pages
Compare the final text, headings, calls to action, images, contact routes, and mobile layout with the approved content. Check links from advertisements, business profiles, and email campaigns that point directly to the page.
Review the action associated with the page. A service page may lead to a form, booking tool, phone number, or downloadable guide. The page is not complete if that next step still points to an obsolete Wix route.
If copy changes during the move, distinguish an approved editorial change from an import omission. Keep the owner involved so useful information is not lost under the assumption that a shorter new layout must contain everything important.
Blog and resource content
Check representative posts across the archive, including older entries and unusual layouts. Confirm author attribution, dates, categories, images, downloadable files, and links to other resources.
Pay particular attention to embedded content. A copied embed may refer to a service account that remains active independently of Wix, or it may depend on platform-specific behavior. Record which condition applies and rebuild the integration where necessary.
Review the new archive and category navigation. Imported posts can exist while remaining difficult to discover because menus, category pages, or related links were never reconstructed. Content preservation includes a useful route for readers to reach the material.
Directories and dynamic collections
Test filtering, sorting, detail pages, relationship links, and empty states. A successful CSV import does not prove the new template uses the fields correctly.
Check a record with several related items and one with optional fields missing. Verify that the layout does not display raw identifiers or broken placeholders when a value is absent. Keep the source identifier in a controlled mapping so exceptions can be traced without relying on similar names.
If the collection has access rules, test an allowed and a denied role. Do not infer permission correctness from the fact that a maintainer can see every item in the dashboard.
Plan the editorial workflow after migration
A platform change affects the people who publish content. Decide which fields they can edit, which patterns they should reuse, and who approves larger design changes.
Create a short owner guide using the actual destination setup. Explain how to edit a service page, add a post, replace an image, update navigation, and recognize the staging environment. Avoid giving staff generic instructions for a different theme or editor.
Give each person an appropriate role. Someone who updates business hours does not necessarily need plugin installation or user-management access. Keep emergency administration available to the business through a controlled account.
Practice one routine update before handoff
Ask the future editor to make a harmless draft change and preview it on mobile and desktop. Observe where the interface is confusing and improve the instructions or page pattern.
This is useful acceptance evidence. A site that only its builder can edit may fail the original business objective even if the public design is attractive. The migration should establish a practical publishing process, not just a different technical platform.
Record how changes reach production and how mistakes are recovered. If staff use staging, explain whether content should be recreated, selectively imported, or published through another supported process. An unreviewed database push can replace newer live records.
Evaluate a migration service before sharing access
Ask a prospective provider to describe the supported content types, export limits, rebuilding work, URL plan, media ownership, and final acceptance. Give it a representative sample of the site rather than asking it to price an unknown application from the homepage alone.
Clarify whether forms, CMS collections, bookings, memberships, and commerce are included. A quote for page reconstruction may reasonably exclude transactional data, but the boundary should be visible before work begins.
Ask how missing or unsupported items will be reported. A useful service produces an exception list and a proposed resolution, not just an importer success message. Confirm who approves substitutes and what happens if a required feature cannot be reproduced as planned.
Use individual temporary access where possible and the business’s normal secure process. Do not send account passwords in an unprotected document. After the migration, remove unnecessary access and retain a clear ownership record for the new services.
Three illustrative Wix migration projects
These examples explain planning choices and are not customer cases or performed tests.
A local contractor has twelve pages and one quote form
The team preserves useful URLs and rebuilds the page patterns in WordPress. It copies approved content, transfers owned images, and recreates the form with controlled delivery tests.
The launch changes website routing while preserving the existing mail service. Acceptance includes a real receiving-system check, mobile navigation, and an editable service-page pattern. No unnecessary commerce migration is added to the project.
A publisher has an archive larger than the RSS feed
The source inventory reveals posts outside the recent feed. The team chooses an authorized process for the full archive and maps source posts to destination records.
It checks older posts, media-heavy posts, dates, authors, and internal links. Completion depends on reconciled content and owned media, not merely the number of posts returned by the first importer.
A booking business needs a different workflow
The project separates page reconstruction from appointment data and calendar integration. The owner defines how existing appointments remain serviceable while new appointments begin in the destination system.
The team tests time zones, availability, confirmation, and staff access. The handoff explains the operational boundary so a platform change does not leave the business guessing where a customer’s reservation lives.
Record the final transfer decision for every required feature
Use four statuses: transferred and verified, rebuilt and verified, intentionally retained elsewhere, or unresolved. This makes the handoff understandable without implying that every feature followed the same path.
For a retained external booking service, record the account owner and the final integration route. For a rebuilt form, record the controlled test and receiving system. For an unresolved historical record, name the person who will choose the supported next step. Keep the underlying private data out of the summary.
Review this list with the business owner before ending source services. The value is not the number of green cells; it is a shared understanding of where the business’s information and customer responsibilities now live.
Common mistakes that increase rework
Do not start rebuilding every page before selecting reusable content patterns and the destination data model. Early structure decisions affect both editing and import work.
Do not confuse a contact export with a user-account or consent migration. Preserve the meaning of each record and verify the destination’s supported behavior.
Avoid canceling the source before media, downloads, old records, and domain-related services are verified. A page can look complete while still depending on the old platform.
Finally, do not promise preserved rankings or an exact template clone. Offer a clear content, URL, functionality, and acceptance plan that the business can review.
Frequently asked questions
Can I export my entire Wix site as a WordPress theme?
Do not plan the move that way. Content-transfer options and design reconstruction are separate. Confirm the current tools for your chosen destination and expect to rebuild the WordPress theme, styles, and relevant features.
Does the WordPress.com Wix importer work on any host?
Its documentation describes a hosted WordPress.com feature. A self-hosted installation may use different tools and workflows. Confirm the actual destination capability before estimating the transfer.
Will RSS move every blog post?
Not necessarily. Wix’s documented feed limit at the time of research covered the most recent 20 posts. Reconcile the full source archive and choose another authorized process for content outside the available feed.
Can I keep my domain and email?
Often, yes, but domain registration, DNS, website hosting, and mail service need separate planning. Preserve required DNS records and confirm billing and account continuity. Test employee email and WordPress notifications independently.
Will my forms and bookings transfer automatically?
A content importer should not be assumed to recreate application behavior or operational records. Inventory the requirements, verify supported data paths, rebuild the necessary features, and test the completed workflow.
Can I preserve existing URLs?
Often many paths can be retained or mapped, depending on the source and destination structures. Build a URL inventory, choose final paths, and implement appropriate redirects where requests will arrive. Do not promise redirect control over a platform subdomain you do not administer.
How do I know images actually moved?
Confirm that the files exist in the intended destination storage and inspect the URLs the page requests. An image that still loads from Wix is not proof of a complete transfer to the new site’s storage.
When should I cancel Wix?
After checking transferred content and media, rebuilt workflows, final records, domain and mail dependencies, and any retained operational needs. Use evidence about those dependencies rather than a universal countdown after launch.
Keep the accepted feature list with the final release record. It gives the owner and next maintainer a clear distinction between the new WordPress application, intentionally retained external services, and any unresolved transition work.
Build a destination the business can operate
A useful Wix migration preserves information and customer paths while establishing a maintainable WordPress application. Treat content, design, data, integrations, and domain services as coordinated work with explicit acceptance.
Web Expert Solutions provides Wix-to-WordPress migration, website development, hosting support, and troubleshooting. Share the current site, required features, and any active bookings or commerce so the proposed move can distinguish supported transfer from the rebuilding and verification the business actually needs.
