Migrating off WordPress without losing your SEO

The objection that stalls almost every migration is the same one: “what if we lose the traffic?” It is a reasonable worry. A badly executed migration can erase years of rankings over a weekend, and recovery is measured in months.

What follows is the process we use, in order, with the decisions that matter and the ones that do not.

Before you touch anything

The most expensive mistake in a migration happens on day one: starting to build without having measured what was there. Without a baseline there is no way to know whether the day-fifteen dip is normal or a problem, and no way to demonstrate afterwards that the project went well.

Four things need to be saved before a line of code gets written:

1. A Search Console export covering the last sixteen months at URL level, with impressions, clicks, average position, and CTR. Sixteen months is the maximum the tool offers and it is worth taking all of it.
2. A full site crawl with Screaming Frog or similar, capturing titles, meta descriptions, status codes, canonicals, and internal link structure.
3. A Core Web Vitals baseline, both lab and field. Chrome UX Report field data is what actually counts for ranking.
4. A complete backup of files and database, verified by restoring it somewhere else. An untested backup is a hypothesis.

Search Console only remembers sixteen months, and a crawl only sees what is linked today. The oldest URLs, the ones still earning links from other sites, can be recovered from the Internet Archive; our old URLs finder lists them, ready to cross-check against the inventory.

This step takes a few hours. After the migration it cannot be recovered.

Deciding what happens to each URL

This is where rankings are won or lost. Every URL in the inventory gets one of four decisions:

It stays. The page exists on the new site at the same address. This is the ideal case and worth pursuing wherever the new structure allows it.

It gets a 301. The page goes away but an equivalent exists by intent. The redirect must be a single hop: if URL A redirects to B and B redirects to C, fix A to point straight at C.

It gets consolidated. Several thin pages on the same topic merge into one fuller guide, and all of them redirect to it. Common in blogs with years of short posts.

Our own migration is an example of the second case. The articles in our search rankings guide used to sit at the root of the domain; today they live under /blog/ and every old URL redirects to the new one keeping its slug, which is what makes the hop a single one and keeps the signal legible.

It gets a 410. The page goes away and no equivalent is possible — a discontinued checkout flow, an expired promotion. A 410 tells Google the removal is permanent and speeds up de-indexing.

The shortcut worth resisting

Redirecting every retired URL to the homepage is fast, and it is a mistake. Google treats bulk homepage redirects as a soft 404: it concludes the destination does not answer the original intent, discards the signal, and you effectively end up where a 404 would have left you — with worse user experience thrown in.

Redirecting to the closest page by intent takes more work, because it means reviewing URL by URL, and it is the only thing that preserves the signal.

Launch week

D-7. Complete new site on staging behind noindex. Crawl staging and validate the redirects against the exported inventory: every old URL should return a 301 to a URL that returns 200.

D-1. Drop the DNS TTL to 300 seconds so you can revert quickly. Freeze changes on the old site.

D-0. Deploy, remove noindex, verify robots.txt, submit the new sitemaps in Search Console, and confirm SSL plus www-to-apex resolution in a single hop.

D-0 plus two hours. Manually walk the twenty highest-traffic URLs from the inventory and confirm each lands via one 301, with no chains. It takes half an hour and catches most serious errors. The redirect checker shows the full chain for each URL, hop by hop, with its status code.

D+1 to D+30. Check the coverage report and the 404 report daily through the first week, then weekly. Any URL that shows up as a 404 gets added to the matrix and redirected.

D+30. Compare rankings and traffic against the baseline.

What is normal and what is not?

A 10 to 20 percent dip over two to four weeks is expected in any migration: Google needs to reprocess the site, follow the redirects, and update its index. Seeing that dip and panicking into a rollback is the worst possible outcome, because it stacks a second migration on top of the first.

What is not normal is a drop over 30 percent, or one that has not started recovering by week four. In those cases check, in this order: 404s in the coverage report, redirect chains, robots.txt blocks, and noindex tags left over from staging.

That last one is more common than you would think, and explains a surprising share of migrations that go wrong.

Redirects are not temporary

A year minimum, and in practice indefinitely if the cost of keeping them is low. Inbound links from third-party sites point at the old URLs and will not update themselves. Every redirect you remove turns those links into 404s.

On a static architecture served from the edge, keeping forty redirects costs nothing — it is a config file. There is no operational reason to retire them.