Prepare a Wix-to-WordPress migration by inventorying content, deciding each URL’s destination and verifying the rebuilt journeys before switching visitors. Treat design, content and platform behaviour as separate migration decisions. Preserve useful addresses where practical, plan relevant redirects where they change and retain a recoverable record of the previous site.
Start by defining what is moving. Text, photographs, downloads and page purposes need an inventory. Forms, member journeys and other interactive functions need a behaviour specification. Assign responsibility for each item so the migration plan describes the intended WordPress result and the evidence needed to accept it.
Can a Wix site simply be hosted as WordPress?
Wix’s hosting explanation sets the platform boundary. Wix says its site technology needs to run on Wix servers. Wix distinguishes owning the content from hosting the Wix site elsewhere. Plan the WordPress version as a controlled reconstruction of the needed content and functions.
Record the actual route for obtaining each item from the account or approved content records. Check image originals, text versions and downloadable files with their owners. Identify material that needs a replacement or permission decision before it appears in the new site. A screenshot can help document layout, but the underlying content still needs its own migration decision.
Review interactive elements with a task-based checklist. For an enquiry form, note the information collected, the destination and the confirmation expected by the visitor. For a protected area, record the intended access rules and ownership of the user records. Ask the implementer to show how the replacement will meet those requirements.
Keep domain management, website hosting and mail configuration separately visible. The project owner should know which services are intended to change and which records support them. Use an explicit cutover checklist so a website move does not accidentally become an unexplained change to another service.
How should the content and URL map be built?
Google’s site-move documentation gives the search-facing framework. Google recommends preparing a mapping from current URLs to their new format. Its site-move guidance includes transferring images and downloads. Include these assets alongside pages so a useful linked document is not lost from the plan.
For every old address, record the intended outcome: preserve the address, move to an equivalent answer, combine into a relevant page or remove after an explicit content decision. Review proposed destinations by reader purpose. A product detail page and a general homepage may both load successfully while answering very different questions.
The original map below separates content decisions from technical verification. Replace its fictional paths with the actual inventory, then add the person responsible for checking each result.
| Existing item | Proposed WordPress destination | Verification question |
|---|---|---|
/services/site-care |
Equivalent service explanation | Does the destination answer the same need? |
/project-brief.pdf |
Retained or revised approved download | Does the link deliver the intended document? |
| Old enquiry page | Rebuilt enquiry journey | Are recipient and confirmation correct? |
| Combined advice pages | Relevant consolidated guide | Can old readers find their original answer? |
| Retired temporary page | Explicit removal decision | Does its response match that decision? |
Google recommends updating internal links to the new URLs. Use the approved map to review navigation, body links, image references and calls to action. Avoid leaving readers dependent on an old address when the new page can link directly to its intended destination.
Google recommends server-side permanent redirects from mapped old URLs to new URLs. Google advises redirecting directly to the final destination. Ask the hosting implementer to select the supported mechanism for the actual environment and retain the deployed mapping for review.
What should be verified in WordPress before cutover?
The WordPress migration guide helps with the destination environment. WordPress distinguishes the public Site Address from the location of its core files. Confirm the intended configuration for this installation rather than copying an address from an unrelated site or staging arrangement.
Its migration guide calls for a backup of the configuration file before editing it. Keep a recoverable record of relevant configuration and content, and assign the recovery decision to the responsible owner. An implementation checklist should identify the changed setting, its purpose and the observation that confirms it behaves as intended.
Test the rebuilt pages using their approved content, including headings, downloads and responsive images. Then follow the actual visitor journeys. A working homepage does not establish that an enquiry reaches its destination or that an important older link resolves to the correct answer.
Review indexing controls as part of the transition from preparation to public use. Record the intended public state and ask the implementer to verify it against the actual WordPress and hosting arrangement. Keep any staging restrictions distinct from the final site configuration in the handover.
Original old-link acceptance exercise
Use a hypothetical service site with a service page, a project-brief download and an enquiry route. Rebuild the required material in the destination environment and prepare the old-to-new mapping. This exercise is a proposed acceptance method for the project team.
Ask one reviewer to start with an old service link and another to begin from the new navigation. Each should identify the service purpose, locate the preparation document and follow the approved test enquiry route. Retain the addresses, response behaviour and destination observations with the relevant map rows.
Next, test a changed address against its mapped destination. Check both the redirect response and the content reached after following it. If the resulting page answers a different question, return the row to the content owner before accepting it as a successful migration.
Review the download separately. Confirm that it is the approved version and that its internal references still make sense in the new arrangement. Ask the enquiry owner to inspect the controlled sample record, including the recipient and the visitor-facing confirmation.
Google says significant site changes can bring ranking fluctuations during recrawling and reindexing. Keep post-move monitoring focused on observed traffic, indexing and route problems, with an owner for investigation. Use those observations to correct specific defects while preserving the migration evidence and recovery record.
Make the handover usable for someone who did not perform the move. Include the approved mapping, content exceptions, relevant account ownership and the location of the recovery records. Ask that person to follow a sample row from the old address to its current answer and explain who should investigate a problem. Record any missing instruction before closing the migration task. Keep later editorial improvements distinguishable from corrections to the move itself, so the owner can understand why a page or route changed.
For related work, see website development and SEO. Get started with your current Wix address, content inventory and the functions the WordPress site needs to retain.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.