The fear is justified. A site that ranks well has years of work behind it, and a badly handled migration can wipe its results out overnight. The good news is that almost everything lost in a migration is lost for the same handful of reasons, and every one of them can be prevented.
This article is about what to check before, during and after moving a site off WordPress onto something new — whether that is a static export, another CMS or a full rebuild.
It is not the content that gets lost, it is the URLs
The first confusion is that people worry about their text. In reality, Google does not rank your text in the abstract: it ranks it at a URL. The URL is what collected the links, what shows up in the results, what somebody has in their bookmarks.
So the question is not "will the content move?", it is "will every URL that exists today still answer tomorrow?". If the answer is no, you have lost exactly what that URL was worth.
The URL inventory comes from the live site, not from the CMS
This is where it goes wrong most often. You open the admin panel, count 40 pages, and assume those are all the URLs.
They are not. A WordPress site that has been alive for a few years accumulates URLs nobody remembers any more:
- old slugs, changed at some redesign, which WordPress has been redirecting silently ever since;
- theme-generated URLs, such as a template's portfolio pages, which have a structure of their own;
- date archives, if the posts used to sit under
/2024/03/; - category and tag pages, sometimes indexed as well.
The inventory is built properly from the outside: the current sitemap, the pages report in Google Search Console, a crawl of the live site, and the link list in your own footer.
The trap that is on no checklist
Here is one that costs real money and that the usual guides do not mention.
Some of the redirects on your site are not on the server, they are inside WordPress. An old URL the platform has been redirecting for years is a WordPress setting — and the day you switch WordPress off, that setting goes with it.
The result: a URL that answers with a clean 301 today becomes a 404 on launch day, without anybody having deleted anything.
The check is simple, and it has to happen before: take every old URL you suspect and look at what it returns right now. If it returns a 301, write down where it goes — that redirect has to be recreated on the new host. Otherwise you lose it without ever finding out.
301s, and why not every redirect will do
A redirect tells the browser where the page has moved. But the status code matters:
- 301 — moved permanently. Google transfers the ranking to the new URL. This is the one you want.
- 302 or 307 — moved temporarily. Google keeps the old URL in the index and does not move the ranking.
- 308 — permanent as well, but some checking tools report it as an anomaly.
On some platforms, the option labelled "permanent" actually produces a 308 rather than a 301. Where you get to choose, write the code out explicitly.
One more detail that breaks redirects silently: the trailing slash. Many hosts normalise the URL before they look for a redirect rule. A rule written without the slash will never match a request that has one, and the result is a 404 — even though the config file looks perfect.
DNS: the part where something unrelated to the site breaks
When you move the site, you also move the DNS record that says where it lives. The problem is that on many domains the email is tied to that same record.
If the domain's MX points at the domain itself — rather than at a mail server with a name of its own — then mail is delivered to whatever holds the A record. Move the A record to the new host and the mail follows it, to a server that does not accept mail. The contact addresses stop working, without anybody having touched them.
The fix belongs before the move: give the MX a name of its own (mail.your-domain.com), wait out the TTL, send a test message, and only then move the site.
One more detail: if the DNS zone has a wildcard record, a new subdomain will look like it resolves correctly even though you never created a rule for it — until you notice it leads somewhere else.
Canonical, hreflang and the sitemap
Once the URLs are settled, three more things tell search engines how to read the site:
- canonical — every page declares which URL is its real one. If the site is served both with and without
www, one of them has to be the canonical one and the other has to redirect to it; - hreflang — if you have more than one language, every page has to declare its counterpart. Otherwise the versions compete with each other as duplicates;
- sitemap — regenerated on the new URLs and submitted in Search Console.
A well-built site generates all three automatically, out of its own content. Written by hand, they fall behind the first time a page is added. We have written about what a structure that holds itself together looks like on our SEO page.
What to check after the move
On launch day, do not just look at whether the homepage loads:
- Every old URL returns a 301 — not a 302, and not a 200.
wwwand the version without it both end up where they should.- The sitemap answers, and lists the new URLs.
- Email works — send a real test, do not assume.
- Search Console does not report a wave of 404s over the following days.
This is worth automating: a checklist you can run with one command catches in two minutes what you would otherwise find out about a month later, from the error report.
How long until the rankings come back
Honestly: it depends, and anybody who gives you an exact number is guessing. What can be said is that if the URLs answer correctly and the content stayed the same, Google reprocesses the site over the following weeks, not years.
What drags it out is exactly the mistakes above: missing redirects, chains of redirects one after another, or content rewritten "while we are at it" at the same time as the move. If you move and rewrite at once, you will never know which of the two was the cause.
In short
A migration does not lose rankings because the new platform is weaker. It loses them because a URL stopped answering, because a redirect is temporary instead of permanent, or because a setting that lived inside the old platform disappeared along with it.
If you have a site that brings in traffic and you are thinking about rebuilding it, the URL side gets planned before the first line of code. You can also read about how we build sites, or about what goes into monthly maintenance after launch — and if you would like an opinion on your own case, write to us.
