What Actually Breaks When You Move WordPress to Your Own VPS

There are hundreds of guides explaining how to move a WordPress site from shared hosting to your own server. They all cover the same three steps: copy the files, export the database, change the DNS. Those guides are not wrong, and if you follow one carefully the site will be live on the new server that same evening.

Then, three weeks later, you look at Google Search Console and discover the site has been quietly broken the entire time in ways the migration guide never mentioned.

This is that list. I moved seven sites this way in August 2026, and everything below is something that was still wrong long after the migration “worked”.

1. Your old URLs are still in Google, and they are now errors

This was the largest problem and the slowest to notice, because the site itself looked perfect.

The previous host served the site under a path prefix — everything lived under /site/. The new server did not use that prefix, so every address Google had indexed over the years now pointed at nothing. Search Console eventually reported 595 URLs returning server errors.

Worse than the count was what those pages were. One of them carried the exact page title I was trying to rank for. So for weeks, a dead page on the old structure was competing with the live page on the new one for the same term, splitting whatever signal the site had.

The fix is one line, and the shape of it matters:

location ^~ /site/ {
    rewrite ^/site/(.*)$ /$1 permanent;
}

That strips the old prefix and sends each address to its real equivalent: /site/home/label/ becomes /home/label/, and images under /site/wp-content/ resolve too.

The tempting alternative — redirecting every old URL to the homepage — is much easier and much worse. Google treats a mass redirect to the homepage as close to a “not found”, so you keep almost none of the value those pages had accumulated. Redirect each address to its equivalent, or accept that you are discarding the history.

How to find yours: Search Console, Indexing → Pages, and read the errors rather than the successes. It is the only place this problem is visible. The site gives you no indication at all.

2. Changing DNS is two records, and one of them destroys your email

To point a domain at a new server you change its A records — the entries mapping a name to an IP address. You need two: the bare domain and the www version. Miss the second and half your visitors reach the old host.

Do not touch anything else. The same DNS panel holds the records that route your email — MX, plus entries named like mail, webmail, smtp, imap, pop. They point somewhere entirely different, and they must keep pointing there. Changing them because they look like leftovers from the old host will stop your email, and you will not notice until someone asks why you never replied.

Two records. Everything else stays exactly as it is.

3. The certificate covers the names you asked for, and nothing else

An HTTPS certificate is issued for specific names. If your certificate was issued for site.example.com and you now also serve example.com and www.example.com, those two names have no certificate — and visitors get a full-page browser security warning, which is far more damaging than an error page. An error looks like a fault. A security warning looks like fraud.

You expand the certificate to cover them:

certbot --nginx --expand -d site.example.com -d example.com -d www.example.com

But the order matters, and this is where I lost an afternoon.

The certificate authority verifies every name in the request, from its own servers. If one of your names has not finished propagating — if some resolvers still return the old address — the verification fails for that name and therefore for all of them. You get no certificate at all, not a partial one. And failed attempts are rate limited, so repeatedly retrying makes things worse rather than better.

Check what the world actually sees before running certbot:

dig +short @8.8.8.8 example.com
dig +short @1.1.1.1 www.example.com

The practical rule: if the bare domain has propagated but www has not, issue the certificate for the names that are ready and expand later. Otherwise the name that resolves to your server sits there without a certificate, showing warnings to real visitors while you wait for the other one.

4. Certbot leaves a trap for the next name you add

This one is genuinely obscure and cost me a domain that refused to be certified for two days.

When certbot configures a site, it modifies the plain-HTTP section of your web server config. In some configurations it leaves behind a blanket return 404, plus a redirect rule for each name it already knows about.

Add a new domain to that server later and it falls into the 404 — including the special address the certificate authority uses to verify ownership. The verification cannot succeed, because the config designed to be helpful is answering “not found” to the one request that must work.

The fix is to make sure the verification path is served before anything else:

location ^~ /.well-known/acme-challenge/ {
    root /var/www/html;
}
location / {
    return 301 https://$host$request_uri;
}

The symptom is distinctive: certbot fails for one new name while every existing name renews perfectly. If that happens, the problem is in your HTTP block, not in your DNS.

5. Your page builder wrote your old address into the database

If your site uses a visual page builder, this will catch you.

WordPress itself handles a domain change well. Page builders often do not: many store absolute URLs inside their content, so every image, background and internal link carries the old address in the database. The site appears to work — because the old address still resolves — and then breaks completely the day the old host goes away.

You cannot fix this with a simple find-and-replace in a database export, because the content is stored in a format where changing text length corrupts the surrounding structure. Use a tool that understands it:

wp search-replace 'https://old.example.com' 'https://new.example.com' --precise --recurse-objects

Take a database backup first, run it without committing to preview the count, and afterwards click through your most complicated pages personally. The ones built with the builder are exactly the ones that break, and they are never the ones you check.

6. If a DNS value keeps reverting, something is rewriting it

The most useful diagnostic I learned in the whole process, and it generalises well beyond DNS.

One domain refused to move. I set the A record, verified it, and hours later it had returned to the old value. I assumed caching, waited, and set it again. Same result.

Caching does not do that. A cache serves a stale value for a while and then catches up. It never moves backwards. When a value regresses, something is actively rewriting it.

In this case the domain had a “redirect” service enabled at the registrar — a feature that forwards the domain to another address — and that service owns the A records and restores them whenever you change them by hand. The fix was not technical: it was switching the domain from that service to plain DNS management, then setting the records once.

So: if a value goes backwards, stop waiting and go looking for the owner. Registrar redirect services, parking pages, and CDN proxies all do this, and none of them announce it.

7. Everything is fine and Search Console still complains for weeks

Even after all of the above, the errors do not disappear the day you fix them. Google re-checks on its own schedule, and a large site can take weeks to be fully recrawled. You can request validation of a fix, which speeds it up, but you cannot make it instant.

Fix it, request validation, and then leave it alone. Checking daily and adjusting things because the number has not moved is how you introduce new problems on top of solved ones.

Was it worth it?

Yes, decisively, but the honest accounting matters.

I gained control, considerably lower cost, and the ability to run things a shared host would never permit. I also acquired a permanent responsibility: worker limits, PHP versions, certificate renewals, and the certainty that when something breaks at an awkward hour, the person fixing it is me.

That is a genuine trade rather than an upgrade, and it deserves a real decision.

If control is what you want, providers like Contabo and Hostinger sell VPS plans cheaply — and the saving is real, as long as you accept that everything listed above is now your job.

enough that the machine is never the expensive part — your time is.

If you want the benefits without the responsibility, managed WordPress hosting like Kinsta takes that list off your hands and charges you for it: you stop owning the server, and you stop owning its failures.

exists precisely for people who read this list and thought “not for me”. Migrations are usually performed for you, which sidesteps most of what is described above. It costs several times more per month, and for a site that earns money that comparison is often shorter than people expect.

For transparency: my own sites run on neither — an Italian provider I have used for years for unrelated reasons, with no affiliate programme. Everything above happened on that machine.

The checklist I wish I had started with

• [ ] Redirect old URL patterns to their equivalents, not to the homepage
• [ ] Change only the two A records; never touch mail records
• [ ] Verify propagation from public resolvers before requesting a certificate
• [ ] Issue certificates for the names that are ready; expand later
• [ ] Make sure the verification path is served before any blanket redirect
• [ ] Search-replace the old domain in the database with a builder-aware tool
• [ ] Read Search Console → Pages → errors three weeks later, not on day one
• [ ] If a DNS value reverts, find what is rewriting it instead of waiting

---