How to Migrate From Wix to WordPress Without Losing Rankings
The single most useful thing to know before starting is that this is closer to a rebuild than a transfer. Scoped that way on day one it is entirely manageable. Scoped as a content move and discovered in week six, it is the kind of project that overruns and cuts corners at exactly the wrong end.
What This Move Involves
Three things happen at once here: the content moves, the addresses change and the pages are rebuilt. That combination is what makes this a larger exercise than the phrase migration suggests.
What makes it a rebuild. The layouts.
Pages assembled with a visual editor exist in that editor's own arrangement. There is no equivalent to transfer them into, so the pages are constructed again on the new system. That is not a failure of the export. It is a consequence of two systems having no shared way of describing a layout.
What makes it a mapping exercise. The addresses.
The two systems express addresses differently, so most of them change. Every one needs a destination recorded before anybody launches anything, which makes the mapping a task running alongside the build rather than a step at the end of it.
What is genuinely straightforward. The words.
Text almost always survives in some form. Getting the writing across is rarely the difficulty, which is why an early check on a few pages gives a falsely encouraging impression of how much work remains. The words arriving is the easy part of this project rather than evidence that the rest went well.
Where the general trade is covered. The other page.
What you gain and take on by moving from a managed platform to an assembled one is the same discussion regardless of which managed platform. It is covered on our Squarespace to WordPress migration guide rather than repeated here.
Address Structures And What Survives
Assume every address changes and then check whether any can be kept. That order is deliberate, because assuming preservation and discovering otherwise is the expensive version.
Why they differ. Different conventions.
Each system has its own way of expressing pages, sections and dated content in an address. Where those conventions differ, the addresses differ. No configuration reconciles two systems that were never designed to agree.
What can sometimes be preserved. Simple pages.
Straightforward top-level pages sometimes translate directly, because there is less structure to express in the address. It is worth asking whoever is building whether the destination can reproduce the pattern before assuming it cannot. Every address preserved is one that needs no mapping, no testing and no monitoring afterwards.
What rarely survives. Anything organised.
Dated content, categorised items and anything generated by a feature of the old system. Those are where the conventions diverge most. They are frequently also the pages that have accumulated the most external links.
What to produce. A complete inventory first.
Every address that resolves, gathered while the old site is still live rather than after the account closes. That inventory is the one artefact this project cannot be run without, per URL mapping for a site migration.
Content Export
Getting content out of this kind of system is more constrained than getting it out of an open one. That is a consequence of the design rather than a criticism of it. The distinction is worth holding onto.
Why the design works that way. It is the point of the product.
A system built so that somebody without technical skills can create and run a site themselves has to be self-contained. Everything held in one place, nothing requiring outside knowledge, nothing that breaks because a component was not updated. That is the feature, which it succeeds at.
Why the same choice constrains extraction. Self-contained cuts both ways.
A system holding everything in its own arrangement has less reason to express that arrangement in a form something else could read. The two properties are the same property viewed from different ends, which is why this is worth planning around rather than complaining about.
What we will not tell you. What is currently available.
Export facilities change, so a specific claim written today would be wrong within a year. Establish what actually comes out before anybody agrees a budget, because that answer is the thing the estimate depends on.
What to do with the answer. Scope accordingly.
Whatever does not come out has to be recreated by somebody. That work belongs in the quotation rather than in a difficult conversation later, once both sides have different recollections of what was agreed.
What Tends To Break
Four things go missing repeatedly on this move. None produces an error and none is visible on a page, which is why they need checking rather than noticing.
Page layouts. The largest by volume.
Arrangements built visually rarely survive, because the new system has no equivalent structure to receive them. The content arrives without its shape, which means somebody has to decide what each page should look like again.
Descriptions written for search results. The quiet one.
Held separately from the content and frequently omitted from an export. Nothing reports their absence and nobody sees it on a page, so they simply stop existing. Every page then presents itself in results using whatever can be inferred from it instead.
Image handling. Both the files and their descriptions.
Images may need retrieving and re-uploading individually. The alternative text attached to them frequently does not travel with the file, so it has to be written again or looked up from the record.
Anything a built-in feature provided. The forgotten one.
Forms, galleries, booking tools and similar. Each was part of the old platform and each needs an equivalent chosen, configured and tested on the new one, which is work nobody counted because the feature was simply there before.
The Redirect Problem
Redirects have to be served by something. During this move the thing that used to serve them is being switched off. Establishing who handles them, plus when responsibility transfers, is the sharpest planning question on this page.
Why it is different here. The old platform goes.
On a move between two systems you keep, either could hold the redirects for a while. Here the old one is being cancelled, so everything has to be served by the new arrangement from the moment the domain points at it. There is no period of overlap to fall back on.
What that requires. The map, ready before launch.
The redirects cannot be added afterwards in a leisurely way. They have to exist on the new site on day one, which means the mapping has to be finished before launch rather than during the settling period. That is a scheduling consequence rather than a technical one. It changes when the work has to happen.
The specific trap. Cancelling too early.
Closing the old account before the domain has fully moved, else before the inventory is complete, removes the only remaining record of what addresses existed. That is unrecoverable.
What to agree in writing. The order of operations.
Who cancels what, when, plus what has to be verified before each step. A migration is a one-off project rather than a monthly arrangement, so the handover points need naming while everybody is still engaged. The mechanism is in WordPress CMS migration SEO.
What A Realistic Project Looks Like
Scoped correctly this is a straightforward piece of work. Scoped as a content transfer it becomes a difficult one. The difference is entirely in what was assumed at the start.
What a realistic scope includes. Rebuilding, not importing.
Time to reconstruct pages rather than transfer them, time to choose and configure replacements for built-in features, plus time to produce a complete address mapping. Three tasks, none of which appears in the word migration.
What an unrealistic one assumes. That it is a copy.
A project priced as an import, discovering in week six that most pages need rebuilding, has a committed budget, an announced date, no good options. Something gets cut. It is usually the mapping.
Why the mapping is what gets cut. It is invisible.
Nobody can see it. Cutting it produces no visible change to the new site, which makes it the easiest thing to sacrifice and the most expensive thing to lose. The consequences arrive weeks later, once the project has been declared finished and everybody has moved on to something else.
The one question to settle first. What actually exports.
Everything else in the estimate follows from that answer. It can be established in an afternoon before anybody commits to anything.
What To Check After
The general launch checks apply as anywhere. Five things are worth verifying because of what tends to go missing on this particular move.
That page content is complete. Against the record.
Compared with the pre-migration crawl rather than looked at, since a rebuilt page that lost a section still reads perfectly well to anybody who never saw the original.
That descriptions for search results exist. They often will not.
Invisible on the page and absent without any error, so this needs deliberate checking rather than waiting for something to flag it.
That every redirect resolves. Especially the priority list.
Because the old platform is no longer there to catch anything that was missed, which removes the usual safety net entirely.
That replacement features work. Forms and anything transactional.
These were provided before and are now assembled from parts, which makes them new rather than moved. New things need testing properly.
That nothing is telling crawlers to stay away. Within the hour.
The check that outranks everything else. The full series is on the website migration guide.
Scope it as
a rebuild.
Then it works.
What actually exports established before anybody agrees a budget, the address inventory gathered while the old site is still live, the mapping finished before launch because the old platform will not be there to catch anything, replacement features treated as new rather than moved, with the old account cancelled last rather than first.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
