Every SEO consultant has a version of the migration speech. Mine used to be quite good. It went through server access, plugin ecosystems, URL control, log files, page speed, ownership of the codebase, and it ended with the line that Wix is fine for a restaurant and wrong for a business that competes on search. I delivered a version of it to this client, in writing, at their request. Then they said no, and I had to decide whether they were being stubborn or sensible.
What they asked for
The company operates in healthcare services in the United States, with two sites. The one that customers see is built on Wix and has been for years. A second site, aimed at recruiting and the offshore side of the business, runs on WordPress. The chief executive wanted three things from me in one engagement. A plan for visibility in Google’s ordinary results. A plan for visibility in the AI answer engines, which the company’s prospects had started using to shortlist vendors. And a written case for moving the main site from Wix to WordPress, because the WordPress site had been easier to work with and the assumption was that the platform was holding the main site back.
The third request is the one this piece is about, because it is the request that arrives on my desk most often from businesses of this size, and because the honest answer turned out to be different from the speech.
The case for WordPress, as I made it
I did not soften it. These are real limitations and the client deserved to see them in one place.
On Wix you do not control the server. You cannot read access logs, so you cannot see what Googlebot actually fetched and when. You cannot tune caching or compression beyond what the platform offers. You cannot install anything the App Market does not carry, and the App Market’s SEO tools are shallow compared with what a WordPress site can run. URL structure is constrained, and the blog in particular lives under a path you do not choose. Custom code is possible through Velo, but that is a proprietary environment with a small pool of developers, and the work does not travel if you leave. The site’s performance ceiling is set by Wix’s infrastructure, not by you. Export is partial, and if the platform changes its pricing or its terms, you absorb it.
WordPress reverses every one of those. You own the files, the database, the server if you want it, the log files, and the choice of every component, and there are more WordPress developers in any city than Wix developers in most countries. Performance is bounded by your budget and your engineer, not by a shared platform.
That was the argument, and on paper it wins.
What it would have cost
Then I put numbers against it, because a migration is not a decision about which platform is better. It is a decision about whether the difference is worth the transition.
The site had several hundred indexed URLs, a decade of inbound links, and rankings that, while not what the company wanted, were paying for a meaningful share of its inbound enquiries. [VERIFY: page count and the share of leads from organic at the time.] A migration of that size, done properly, runs three to five months from decision to launch when you include design, content transfer, redirect mapping, staging, QA and a post-launch monitoring window. During the move, the marketing team loses the ability to publish on the old site without doing the work twice. After the move, even a clean migration with a complete redirect map produces a period of ranking noise while Google recrawls and re-evaluates every URL, and a healthcare services company selling to other businesses does not have a seasonal quiet period to hide that in.
The risk column is longer than the benefit column for a reason. Redirect maps miss URLs, and internal links get rebuilt with slightly different anchors. Metadata is recreated by someone who was not there when it was written. Structured data that worked is replaced with a plugin’s defaults. A form that fed the CRM stops feeding it and nobody notices for a week. None of these is dramatic on its own. Together they are why “we migrated and traffic dropped” is one of the most common opening lines I hear from new clients.
So the honest framing to the chief executive was this. The migration would cost roughly a quarter of a year and a temporary loss of momentum, in exchange for capabilities the company would only benefit from if the lack of those capabilities was what was holding it back. Which raised the question nobody had asked yet.
What was actually in the way
I spent the first weeks of the engagement on the visibility plan rather than the platform, and the audit produced a list of things that were limiting the site. None of them required leaving Wix.
[VERIFY: replace the four items below with the actual findings from the audit, in the same order of impact. The structure stands; the specifics must be real.]
The first was coverage. The company offered a wider set of services than the site described, and the services it did describe were written for people who already knew the company rather than for people searching for the service. The pages that should have carried the commercial intent did not exist or were thin. Wix does not stop you writing pages.
The second was entity clarity. The company’s name, its parent, its locations and its leadership were described inconsistently across the site, its directory listings and its social profiles, and the structured data on the site said less than the footer did. Wix supports custom JSON-LD on every page and has for years.
The third was that the two sites, the customer site and the recruiting site, competed with each other in places and ignored each other in others. Search engines and answer engines were seeing two organisations where there was one. That is a decision about which site says what, and it has nothing to do with a CMS.
The fourth was the AI answer engines specifically. The chief executive’s instinct that prospects were shortlisting through them was correct, and the fix was not technical. Answer engines cite pages that describe a service clearly, state where and for whom it is delivered, and are corroborated by other sources. The site was short of exactly those pages, and the company had almost no third-party corroboration of what it did. Again, a content and reputation problem that a platform change would have delayed by a quarter without touching.
There was one item on the list where Wix did constrain us. [VERIFY: the specific limitation, if there was one, or delete this paragraph.] We worked around it. It was not worth a migration.
The decision
They stayed on Wix. The visibility plan went ahead on the existing platform, the recruiting site got a defined role instead of a competing one, and the migration case went into a drawer with a note to reopen it if the company outgrew the platform’s limits in a way that could be named.
I want to be precise about why this was the right call, because “stay on Wix” is not advice I give generally. It was right here because the limiting factors were content, entity consistency and corroboration, and all three could be fixed on Wix in the time the migration alone would have taken. It was right because the company’s marketing team could publish on Wix without a developer, and would have needed one on a custom WordPress build. And it was right because the chief executive asked the correct question, which was not “is WordPress better” but “will WordPress fix the problem I have”.
A rule for when the platform is the bottleneck
The platform is the bottleneck when you can name a specific thing you need to do, show that the platform prevents it, show that it cannot be worked around, and show that doing it would move a number you care about. All four. If you cannot name the thing, you have a preference, not a bottleneck. If the platform allows it but your team does not know how, you have a training problem. If it can be worked around, you have a cost question, and the cost of the workaround is almost always less than the cost of a migration. If it would not move a number, it is not worth a quarter of a year.
Migration is the most expensive way to solve a problem that is usually somewhere else. Before you pay for it, make whoever is recommending it write down which of the four conditions holds and how they know. I wrote the migration decision record I now use for this alongside this piece, and I use it on every engagement where the request arrives, because the request always arrives.
Where I could be wrong
The company may outgrow Wix. If they need server-level control for a reason that can be named, or if the platform’s pricing changes in a way that makes ownership cheaper, the migration case comes back out of the drawer and the analysis above does not argue against it. It argues against migrating before the reason exists.
I also cannot fully separate the effect of the visibility work from what the site would have done anyway. If organic enquiries rise over the following year, part of that is the content and entity work, and part may be market movement I cannot attribute. [VERIFY: whether there is a measurable before and after to cite here, and what it shows.]
Finally, my own history is a bias. I have run WordPress for most of my career and I like owning the stack. If I had a bias in this engagement it ran towards recommending the migration, which is one reason I trust the conclusion I reached against it.
Sources
- Wix, SEO features and tools
- Wix Help Center, Adding structured data markup to your site
- Wix Help Center, Managing URL redirects
- Google Search Central, Site moves with URL changes
- WordPress.org, Requirements and hosting