Migrate a site without losing a single URL

There’s a particular kind of dread that comes with moving a website. Not the build — you know how to build. The dread is the morning after the switch, when you’re refreshing Search Console waiting to find out which URLs you quietly broke, how much traffic walked off a cliff, and which client is about to email asking why their best-ranking page now shows a 404.

A migration is one of the few jobs where the work going well and the work being verified are completely different problems. You can move every page perfectly and still lose half your SEO because fourteen old URLs don’t redirect, or redirect to the homepage instead of their real equivalent.

The migration project is built for that gap. It’s the same crawler and the same checklist workflow behind the launch companion, pointed at the riskiest moment in a site’s life: the day its address changes.

Three migrations that look the same and aren’t

“Migration” is one word doing three jobs, and the difference matters because the thing you need to verify changes each time.

Changing domain. You’re moving from old-domain.com to new-domain.com. Every URL on the site changes. Every single old address now has to 301-redirect to its new equivalent — and to the equivalent, not lazily to the homepage.

Rebuilding the URL structure. Same domain, but a redesign or a CMS change reshuffles the paths: /blog/post becomes /articles/post. The redirect problem is identical, just same-domain.

Moving host. Same domain, same URLs, new server. Nothing should change — which means the job is proving it didn’t.

The part generic tools can’t do: the before-and-after

A spreadsheet can hold a list of URLs. What it can’t do is go and check them. And checking is the entire point of a migration.

The migration project starts the same way everything else here does: with a crawl of the old site. That crawl is your inventory — every page that exists today, captured before you touch anything.

Then you do the migration. When the new site is live, the project runs each old URL and records what actually happens to it:

• It redirects to the right new page — a clean 301 to the address you expected.
• It redirects to the wrong place — a 301, but not to the equivalent page.
• It doesn’t redirect at all — still returns 200 on the old address.
• It 404s — the redirect was never set up.

A redirect map you don’t have to build by hand

The tedious half of a migration is mapping old URLs to new ones. The project gives you a running start: when it imports the old inventory, it guesses each new URL by swapping in the new site’s domain and keeping the path — so a straight domain move or a like-for-like rebuild is mostly mapped for you out of the gate.