Migrate wix to wordpress when the Wix site is earning the calls and the WordPress build is still a sketch. The risky part is not the theme. It is the URL list you fail to bring across, and the mailbox you cut over on the same afternoon.
Rankings are not a prize we can hand you at the end. Google’s own hiring note says no one can guarantee a number 1 ranking. Plan the move so you don’t throw URLs away.
Don’t plan it as a promise that positions will hold.
This is not a count of Wix sites we have migrated. Tianwen Network did move 49 sites from Cloudways onto a self-managed VPS, same specification, cost down by more than half, with a full-time operator. That was a host change, not a Wix export.
Using 49 as a Wix trophy would be a lie. It stays in this page only as a boundary. Different job.
Different number.
The URL list is the asset
Before anyone designs a header, export every public URL on the Wix site. Pages, posts, product paths, PDFs, and the odd landing URL a salesperson pasted into a deck. Put them in one sheet with the current title and the H1.
That sheet is the migration. The new theme is a container you pour the sheet into.
Transfer wix website to wordpress is the query that sounds like a file conversion. Treat it as a mapping problem. For each old URL, name the new URL, or name the 301 target if several old URLs collapse into one.
A URL with no row in the sheet will 404 on the day you switch DNS. You will not notice, because you are clicking the new menu, and the new menu never contained that URL.
Moving from wix to wordpress gets described as a rebuild because Wix will not hand you a WordPress database. Assume the templates are rebuilt and the words are placed again. Don’t assume the URLs may change “a little”.
A changed URL without a 301 is a deleted page that still has history. Keep the path if you can. Redirect it if you can’t.
Write the redirect before the DNS change, and test it from outside, not from a logged-in preview.
Collapsing ten thin city pages into one real service page can be the right edit. Do it in the sheet, with a 301 from each old city URL to the page that actually answers. Don’t leave the city URLs alive and empty.
Google’s spam policies describe doorway pages as URLs built to match similar queries and then pass the visitor to something thinner. A move is a good moment to stop operating that pattern. It is a bad moment to invent a new copy of it on WordPress because a plugin offered “locations”.
What to place, and what to leave behind
Place the words a buyer needs. Scope, specifications, lead time if you truly publish one, and a form that names the product or the project. Don’t place the Wix app widgets you cannot explain.
A chat bubble, a popup, and three review carousels can move across as scripts and then slow the first screen. On a different site, one 15 MB image in the template’s first screen made hundreds of product URLs fail Core Web Vitals. The server was fine.
A Wix design that looked light can hide a file of that class. Weigh the hero after import. The thresholds are an LCP within 2.5 seconds, an INP of 200 milliseconds or less, and a CLS of 0.1 or less.
Images need real file names and alt text that names the object. An export full of hashed filenames is normal. The damage is publishing them at original size.
Make a pass that asks, for each image over a megabyte, whether the page still needs it. Delete the ones that were decorative on Wix and are now just weight.
Internal links break quietly. A button that used to point at a Wix page ID now points at nothing, or at a staging host. Click the primary path.
Homepage to category to the thing you sell to the form. Four clicks, on a phone, not in the editor. Anything that lands on the old Wix host after DNS day is a link you missed.
The plugin-centred version of a WordPress-to-WordPress move, which this is not, lives in the WordPress migration guide. Use it when both ends are already WordPress. Use this page when the source is Wix and the sheet of URLs is the whole trick. Host-level failures after the files look fine are listed under moving WordPress to a new host.
Mail and the form, on the same afternoon
DNS day can take the sales inbox if the domain’s mail records were never written down. Before you change the website’s records, copy the MX, SPF, DKIM, and whatever else the mailbox provider documents. A website cutover that also “cleans up DNS” by deleting unfamiliar rows will delete the mail.
The site comes up. The enquiries from the last three years of the address go nowhere. You notice on Monday.
Then send a real message through the new form to an outside inbox. Contact forms thank the visitor while nothing is delivered. The layers are in why WordPress stops sending email.
Check that path after the domain points at WordPress, not only on the staging host. Staging and production do not share a site key. One site ran 12 days with a reCAPTCHA key registered on the wrong domain.
Two hundred and seven paid clicks hit a form that could not send. A Wix form that worked does not transfer that key. You register it again, on the production domain, and you prove it with a received message.
Whose login holds the domain, the Wix plan, and the new host? Write the names down before the weekend. A move that only one freelancer can reverse is a move you don’t control.
Tianwen Network was founded in 2017. We still want those names in the notes when we are not the ones clicking.
Backup copies are not a safety blanket
While you experiment you will duplicate theme files. On one site we found 36 files ending in .backup inside the theme directory, and every one of them could be downloaded from the public web. A Wix-to-WordPress weekend produces the same litter.
Copies of wp-config, old exports, SQL dumps dropped in a public folder because the person was tired. After the 301s work, list the web root for archives and backup suffixes. Delete them from the public tree.
Store the dump somewhere that is not a URL.
A backup you cannot restore is a souvenir. Before DNS day, restore the WordPress build onto a spare database once, even if the content is still half placed. You are proving the dump works, not admiring it.
The 49-site host move taught a staffing lesson, not a Wix technique. Someone has to be the person who can restore. If that person is the managed host, know their queue.
If that person is you, try it once while the Wix site is still the live one.
Three checks on the new site before DNS moves
Canonical tags are an easy own goal. If the new WordPress pages still announce the Wix URL as the canonical, you have built a fine site and then told crawlers the old one is the real copy. View source on the homepage, on one deep URL, and on one redirected URL.
The canonical you want is the new URL, on the new host. A plugin that “imports SEO settings” can bring the old canonicals along for the ride. Read them.
Don’t trust the import tick.
Staging has to stay out of the index. A host name like staging.example.com that is public, linked from the new theme’s footer because a kit put it there, will compete with the domain you are about to launch. Password the staging host, or send a noindex on it, and remove any link to it from the theme you are about to make live.
Do this before DNS day. After DNS day you will be busy with the form, and the staging host will sit there getting crawled.
Test a sample of redirects from outside the office. Take 10 rows from the sheet, including a PDF and a URL you almost dropped. Request each old URL with curl and read the status and the Location header.
You want 301, once, to the URL in the sheet. A 302 says temporary, which is the wrong story for a permanent rebuild. A chain of three hops usually means the sheet, the plugin, and the server each added a slash or a host.
Collapse it to one hop before you switch the domain. Ten URLs will not prove the other four hundred. They will prove the mechanism.
Then run the whole sheet when the mechanism is boring.
Blog and news URLs deserve rows too, even if you are tired of them. They are often where older links point. Deleting the blog because “we’ll write fresh on WordPress” throws away those URLs unless each one 301s to a real successor.
A successor can be the closest new article, or the service page the old post was secretly selling. It should not be the homepage for everything. A homepage that receives 200 old blog URLs looks, to a crawler, like a dump.
Rankings, said with the sentence Google wrote
The title of this page is about not losing rankings. Here is the limit on that phrase. Google writes, on the page about whether you need an SEO: “No one can guarantee a #1 ranking on Google.” The same page says to beware of anyone who guarantees rankings, claims a special relationship with Google, or advertises a priority submit.
A migration agency that adds “rankings kept” to the proposal has walked into that sentence. We won’t.
What you can do is mechanical. Keep the URL or 301 it. Keep the words that matched the query, if they were true.
Keep the internal links that helped a person, and a crawler, find the next page. Submit the new sitemap when the 301s are in place. Then wait, and look at whether the old URLs return 301 rather than 404.
That is the job. The position next month is not a deliverable.
Indexing itself is uneven, including on our own sites. A URL Inspection check on 22 September 2026 showed the waimaodulizhan.com homepage crawled on 21 September, with a new page indexed the same day it was published. On tianwenwangluo.com the homepage’s last crawl was stuck at 12 September, the sitemap’s last download was 14 September, and three pages published on 18 September were still reported as URLs Google did not know.
Same company, same week, different crawl behaviour. A Wix move does not get a calmer rule than that. Don’t read a quiet Search Console as proof the 301s failed, and don’t read a fast recrawl as proof you ranked.
Server location will not rescue a broken map. Google says the server’s IP can be an audience signal, and that a CDN, or hosting chosen for better infrastructure, means it is not a definitive signal. Pick the host for who can restore it. The country dropdown is not the migration plan.
When the sheet has a row for every old URL, the form has delivered one real message, and the mail records still match the inbox you meant to keep, the site is allowed to be called moved. Anything about “guaranteed positions” can stay out of the email. It isn’t a line we can accept, and it isn’t a line the live site will honour just because the theme looks newer.
Questions before the DNS change
Will moving from Wix to WordPress keep rankings?
Nobody can guarantee that. Google writes that no one can guarantee a number 1 ranking, and says to beware of a guarantee or a claimed special relationship. Map every old URL to a new URL or a 301, keep the words that were true, and test the redirects. Next month’s position is not a deliverable.
Is the 49-site figure a count of Wix migrations?
No. Tianwen Network moved 49 sites from Cloudways to a self-managed VPS. Same specification, the cost fell by more than half, with a full-time operator. That was a host change. This page does not use it as a Wix trophy.
What takes the mailbox down during the move?
DNS edits that delete mail records nobody wrote down. Copy the MX records and the related mail records before you change the website. After the domain points at WordPress, send one real form message to an outside inbox and confirm it arrived.
Why mention uneven indexing on your own sites?
On 22 September 2026, URL Inspection showed the waimaodulizhan.com homepage crawled on 21 September, with a new page indexed the day it was published. On tianwenwangluo.com the homepage’s last crawl was 12 September, the sitemap’s last download was 14 September, and three pages from 18 September were still unknown to Google. A quiet console after a Wix move is not, by itself, proof the redirects failed.