SEO-Safe Migrations & Rebuilds

Website Migration SEO: Change Platforms Without Losing Rankings

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.

URL-for-URL by defaultZero URLs changed is the goalSince 2004

What Website Migration SEO Is

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

The Six Failures That Quietly Bleed Rankings

Nearly every post-migration ranking loss I get called to fix traces back to one of these. Every one is preventable before launch.

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.

Lost trailing slashes

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.

Redirect chains

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.

Hotlinked asset breakage

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.

Canonical host conflicts

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.

Analytics and call-tracking loss

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

40 Plugins In. 3 Scripts Out.

One client rebuild, drawn to scale: the old WordPress stack on one side, what actually shipped on the other.

The old stack40 plugins

  • Page builder
  • Builder add-on
  • Slider
  • Gallery
  • SEO meta
  • SEO redirects
  • XML sitemap
  • Schema markup
  • Breadcrumbs
  • Table of contents
  • Cache
  • Cache purge
  • Minify CSS
  • Minify JS
  • Lazy load
  • Image compress
  • CDN helper
  • Database cleanup
  • Contact form
  • Form spam filter
  • Form entries
  • Multi-step forms
  • Duplicator
  • Backup
  • Backup scheduler
  • Migration wizard
  • Popup builder
  • Cookie banner
  • Analytics inserter
  • Heatmaps
  • A/B testing
  • Security scanner
  • Firewall
  • Login limiter
  • Anti-spam
  • Related posts
  • Social share
  • Social feed embed
  • Email opt-in
  • Custom fields

The rebuild3 scripts + native code

Script 01
Script 02
Script 03
Everything else: native code, no plugins
From a real client migration: a 40-plugin WordPress stack became about 3 scripts plus native code. Same content, same URLs, a fraction of the moving parts.

The 5-Step Migration Protocol

The same five steps, in the same order, on every migration. The calendar bends to the checklist.

01

Equity Map

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.

02

Content Extraction

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.

03

URL Engineering

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.

04

Parity QA

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.

05

Post-Cutover Monitoring

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.

Receipts From This Protocol

40 → 3

plugins in, small scripts out, on one client replatform

39

legacy PDFs mirrored at identical paths for a manufacturing client, because other sites linked to them

0

URLs changed: the standing goal on every migration I run

The site you are reading ran this same protocol when it left WordPress.

Who Migration SEO Is For

You are leaving WordPress, or any platform

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.

A redesign is in flight and nobody owns the SEO risk

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.

Traffic already fell after the last migration

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.

Frequently Asked Questions

Straight answers about migrating without losing rankings.

Will I lose rankings during a website migration?
Not if the equity is mapped first. Rankings are lost when URLs change without redirects, when metadata gets rewritten in transit, or when nobody compares the new build against the old baseline before launch. On a URL-for-URL migration with parity QA gating the cutover, the target is zero movement, and zero URLs changed is the standing goal on every migration I run.
How long does a website migration take?
It depends on how many URLs carry equity and how complex the templates are, so I scope it against your actual sitemap on the first call rather than quoting a number blind. What I can promise is the order of operations: the equity map comes first, and cutover waits until parity QA passes. The calendar bends to the checklist, not the other way around.
Do my URLs have to stay the same?
No, but every one of them has to be accounted for. Keeping the same paths is the default because it removes an entire class of risk. When a URL genuinely must change, it gets a single one-hop 301 and its backlinks are checked afterward. What never happens on my watch is a blanket redirect of everything to the homepage.
What happens to my backlinks during a migration?
They get inventoried before anything moves. Every linked URL either keeps its exact path or gets a single 301, and linked files are mirrored rather than dropped. For one manufacturing client that meant 39 legacy PDFs carried over at identical paths, because other sites had linked to those files for years and every link was equity worth keeping.
Can you migrate me off WordPress?
Yes. Moving off WordPress onto a faster, simpler build is the most common migration I run, and this site is one of them. If you want the rebuild itself handled as well, that is my web development service, run under the same protocol so the SEO side is never an afterthought.
My traffic already dropped after a redesign. Is it too late?
No. Post-migration drops are usually mechanical, which means they are traceable: lost redirects, changed metadata, soft 404s, a stack rendering empty to crawlers. The later the diagnosis starts, the longer the comeback takes, so treat it as urgent rather than hopeless. That work is SEO recovery, and it starts with dating exactly what broke.

Planning a Replatform or a Redesign?

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.