I've written a lot about why businesses outgrow WordPress, Squarespace, Webflow and Shopify. What I've never written is the thing that actually stops people acting on it.
It isn't budget. It's the fear that they'll rebuild, launch, and watch a decade of search rankings evaporate — and everyone knows somebody it happened to.
That fear is well-founded, and it's also almost entirely preventable. Migrations don't lose rankings because the technology changed. They lose rankings because URLs disappeared and nobody made a map.
The short version
Google's rankings attach to URLs, not to platforms. Google does not know or care whether a page is served by WordPress, Astro or a stack of PHP files from 2009. It knows that example.com/services/roof-repair earned its position over several years.
So the entire discipline of a safe migration reduces to one sentence: every URL that had value must still resolve, or redirect permanently to the page that replaced it.
Everything below is how to do that without missing anything.
Step 1: Inventory every URL — from three sources
You cannot preserve what you haven't listed, and this is where most migrations are already lost. Use all three of these, because each catches what the others miss:
- Search Console → Pages report. The most important source. This is what Google has actually indexed, including pages you forgot existed. Export the lot.
- A crawl of the live site. Catches pages that are linked but unindexed, and reveals your real internal link structure.
- The existing sitemap. Least reliable — sitemaps go stale — but occasionally lists orphans the crawl won't reach.
Then pull the Search Console performance export by page and sort by impressions. This turns a flat list into a priority order. The top fifty URLs by impressions deserve individual attention; a page with four impressions in a year does not need an hour of anyone's time.
Expect a surprise here. There's usually an old blog post or a forgotten location page quietly earning a meaningful share of the site's traffic, and it is exactly the kind of page a redesign deletes because nobody in the meeting recognised it.
Step 2: Build the redirect map
A spreadsheet. Old URL, new URL, and a note. Every row in your inventory gets a decision:
| Situation | What to do |
|---|---|
| Page survives with the same address | Nothing — best possible outcome |
| Page survives at a new address | 301 to the new URL |
| Page merged into a bigger one | 301 to the merged page |
| Page genuinely retired, close equivalent exists | 301 to the closest real equivalent |
| Page retired, no equivalent | Let it 404 or 410 — deliberately |
Three rules that prevent most of the damage:
Never bulk-redirect everything to the homepage. It's the tempting shortcut and it's treated as a soft 404 — you get no benefit and you've made a bad user experience on top. A visitor looking for roof repair pricing lands on your homepage and leaves.
Use 301, not 302. Permanent, not temporary. A 302 tells search engines to keep indexing the old URL, which defeats the purpose.
Point at final destinations, never at another redirect. Chains — A to B to C — add latency and give crawlers more chances to give up. They accumulate silently across successive redesigns, so if the site has been rebuilt before, check whether your "old" URLs are themselves already redirects.
Step 3: Decide trailing slashes once, then enforce it everywhere
This one is small, boring, and causes an outsized share of real problems.
/about and /about/ are different URLs. If both resolve with content, you have duplicates competing with each other. If your canonical tags say one thing, your sitemap says another, and your internal links say a third, you've split every page's signals across variants.
Pick one convention. Enforce it at three layers: the framework's own routing config, the host's redirect rules, and every canonical tag and sitemap entry you generate. On this site the choice is trailing slashes everywhere, set in the Astro config and mirrored in the host's redirect rules — and it was worth the afternoon it took to make consistent.
Check what your current site does before you decide, because matching the existing convention means fewer redirects to write.
Step 4: Preserve the substance, not just the address
Here's the failure that redirect checklists miss entirely, and it's the one I see most often in redesigns that were technically flawless.
The URL is preserved. The redirect is perfect. And the page ranks for a query it can no longer answer, because the redesign replaced 900 words of specific, useful content with a full-width hero image, a three-word headline and a button.
The page looks enormously better. It ranks for nothing.
So for your top pages by impressions, carry across:
- The title tag and H1, or something very close in meaning.
- The actual substance of the body text. You can rewrite it — but a page that answered five questions should still answer five questions.
- Structured data, ported and re-validated rather than assumed.
- Image alt text and filenames, if image search sends you anything.
- Internal links, updated to point at final URLs rather than through redirects.
My strong preference is to migrate first with content substantially intact, confirm stability for two or three weeks, and improve the copy after. Change one thing at a time and a traffic drop is diagnosable. Change four and it's a mystery you'll be arguing about for months.
Step 5: Launch day, in order
- Check for a stray
noindexor a blockingrobots.txtfrom staging. Do this first. It is the single most common way to lose a site's entire index overnight, and it's a one-line mistake. - Test the redirect map against the live site — every row, automated. Not a sample.
- Verify canonicals point at final, self-referencing URLs.
- Submit the new sitemap in Search Console.
- Keep the old property verified if the domain changed, so you can watch both sides.
Step 6: What to watch, and when to worry
A small dip in the first fortnight is normal — search engines need to recrawl and follow the redirects. Recovery within two to four weeks is the expected shape.
What is not normal, and means something is broken:
- A dip that deepens after week four.
- Rising 404s in Search Console → a gap in your map.
- Pages dropping out of the index → check indexability before anything else.
- Impressions holding while clicks collapse → your titles and descriptions changed for the worse.
Watch the Pages report as closely as the performance graph. Performance tells you something is wrong; Pages usually tells you what.
The honest summary
Replatforming is a logistics exercise wearing a technical costume. The engineering is rarely the hard part — the hard part is the discipline to inventory every URL, decide what happens to each one, and verify the whole map after launch instead of spot-checking five and calling it done.
Done properly, you keep your rankings and get a better site. Done casually, you spend a year rebuilding what you already had. The difference is a spreadsheet and a couple of unglamorous days.
I'm Divyansh Sood. Redesigns that keep their rankings are a specific thing I do — see website development, and the honest threshold for when leaving WordPress is worth it at all. If you're weighing a rebuild and want to know what you'd be risking, the free audit covers exactly this.