Soft 404s from SPA fallbacks
Single-page-app routers happily return a 200 and an empty shell for URLs that no longer exist. Google sees thin duplicates instead of clean 404s, and trust erodes across the whole domain.
Redesigns do not kill rankings. Sloppy migrations do. I map every URL, redirect, and backlink before a single template changes, so the site you launch keeps the equity the old one earned.
Website migration SEO is the work of moving a site to a new platform, design, or domain without losing the rankings and backlinks the old site has earned. It treats every URL as an asset with measurable equity, maps where that equity goes before anything launches, and verifies after cutover that Google still finds everything it expects. Done right, a migration is invisible to search engines.
Redesigns get blamed for ranking losses, but a redesign never killed anything by itself. What kills rankings is URLs changing without a map: paths that quietly move, metadata rewritten in transit, files that vanish. My default position is that URLs do not change at all, and zero URLs changed is the standing goal on every migration I run.
I have been doing this work since 2004, and the site you are reading is itself proof: it left WordPress under this exact protocol. If you want the rebuild handled alongside the launch protection, that is my web development service. If you only need the migration kept safe, this page is the service that does it.
Where migrations go wrong
Nearly every post-migration ranking loss I get called to fix traces back to one of these. Every one is preventable before launch.
Single-page-app routers happily return a 200 and an empty shell for URLs that no longer exist. Google sees thin duplicates instead of clean 404s, and trust erodes across the whole domain.
To a human, /page/ and /page are the same address. To a crawler they are two URLs, and when the new platform flips the convention without redirects, every link's equity splits in half.
Old redirects stacked on new ones. Every hop leaks signal and slows crawling, and three migrations later half the legacy backlinks resolve through four hops or die in a loop.
PDFs, images, and files that other sites link to directly. Rebuilds rarely carry them over, and every broken file is a backlink quietly turning into a 404.
www and non-www, http and https, a staging domain left crawlable. When several hosts serve the same content, Google picks a winner, and it is not always the one you built.
Tags and tracking numbers that never make it into the new templates. Rankings might survive while the evidence disappears, and nobody can prove what the migration did.
From a real migration
One client rebuild, drawn to scale: the old WordPress stack on one side, what actually shipped on the other.
The old stack40 plugins
The rebuild3 scripts + native code
The same five steps, in the same order, on every migration. The calendar bends to the checklist.
Before anything moves, I inventory every backlink and pull a Search Console baseline: every URL that earns impressions and every query it earns them for. This map is the contract the rest of the migration answers to.
Every page, title, meta description, heading, and image alt comes out of the old CMS verbatim. Rewrites are a separate project. Migration day is the wrong day to change what already ranks.
Exact paths preserved wherever possible, and legacy assets, the PDFs and files other sites link to, mirrored at identical paths. Redirects are the fallback, not the plan.
Before cutover, a script checks every URL in the old sitemap against the new build: a 200 response, an exact title match, an exact meta match. Launch waits until the diff is clean.
Search Console watched against the baseline, with tiered fixes for anything that slips. Never a blanket redirect to the homepage. That is how equity dies.
plugins in, small scripts out, on one client replatform
legacy PDFs mirrored at identical paths for a manufacturing client, because other sites linked to them
URLs changed: the standing goal on every migration I run
The site you are reading ran this same protocol when it left WordPress.
Replatforming is the classic migration: same content, same URLs, new engine underneath. It is also where stacks get simplified, which is how 40 plugins become 3 scripts. The SEO work rides alongside the rebuild so the launch date and the safety checks are never in conflict.
An agency is building the new site, IT will point the DNS, and everyone assumes someone else checked the redirects. I sit on your side of the table: the equity map and parity QA gate the launch, whoever is doing the building.
If the damage is done, the job changes from prevention to diagnosis, and that is SEO recovery: date the break, trace the cause, direct the fix. The sooner it starts, the shorter the comeback.
Not sure the migration plan is sound in the first place? A pre-migration SEO audit scores the risk before you commit, and migration is one piece of my broader SEO services if you need more than launch protection.
Straight answers about migrating without losing rankings.
Book a call before the first template changes. I will tell you plainly what your migration risks, what the equity map will cover, and whether your URLs can stay exactly where they are.