A migration is the most dangerous thing you can do to a healthy website. Nothing about the content has to change, yet a single botched redirect map can erase years of earned rankings in a fortnight. The work that protects your traffic is almost all invisible, which is exactly why teams under pressure skip it.
This is a guide to running a migration that keeps the rankings and traffic you already have. It is opinionated, because every step here exists to stop a specific failure we have watched otherwise-careful teams walk into.
Know which kind of migration you are running
“Migration” covers several different jobs, and they do not carry the same risk. Naming yours first tells you where to spend your attention.
- Domain change. You move from one hostname to another. Every URL changes, and you are asking search engines to transfer reputation across domains.
- URL structure change. The domain stays, but paths change: a new information architecture, cleaner slugs, a different folder scheme. This is where most rankings get lost, because it hides inside a redesign.
- Platform or CMS change. You move from one system to another. The danger is that the new platform generates URLs, markup, and metadata differently than you expect.
- Site merge or split. Two sites become one, or one becomes several. Now you are consolidating or dividing authority, and many old URLs map to the same new page.
Most real projects are two or three of these at once. A replatform usually drags a new URL structure along with it. That combination is the one that bites hardest, so treat a redesign and a migration as the same risk surface. The website redesign process and the migration plan are one piece of work, not two.
Map every URL before you touch anything
The first artifact of a migration is not a design or a schema. It is a complete list of every URL that currently exists and earns something: traffic, links, or both.
Build that list from more than one source, because no single source is complete:
- A full crawl of the live site, to catch what is actually linked.
- Search Console and your analytics, to catch the pages that get traffic and impressions.
- Server logs, to catch the URLs that get requested even when nothing links to them anymore.
- Existing XML sitemaps and any old redirect rules already in place.
Deduplicate those into one master inventory. Then, for every old URL, decide its new destination. One old URL maps to one new URL, as close in intent as you can get. Pages with no equivalent get a deliberate decision, not a default: consolidate into the nearest relevant page, or let it 410 if it genuinely should die.
A redirect map is not a spreadsheet you make at the end. It is the spec the whole migration is built against.
If you write the map last, you will discover too late that the new IA has no home for a page that quietly earns a third of your organic traffic. Write it early and the structure has to answer for every URL it drops.
Redirects: the few rules that actually matter
Most redirect problems come from ignoring a short list of rules.
Use a 301, a permanent redirect, for anything that has moved for good. A 302 tells search engines the move is temporary and the old URL should keep its standing, which is rarely what you mean during a migration.
Redirect in a single hop. Old URL goes straight to the final new URL. Chains (A to B to C) leak signal and slow crawling, and they pile up across successive projects until a page sits behind four hops. While you are in the file, flatten any old chains you find.
Redirect to the closest equivalent, never a blanket redirect to the homepage. Sending a retired product page to / looks tidy and tells search engines the old page is gone with no successor. You lose the ranking instead of transferring it.
Keep the redirects in place. A year is the floor; treat them as permanent infrastructure. External links and search indexes take months to catch up, and the day you remove a redirect is the day someone’s old bookmark turns into a 404.
Preserve the signals search engines already trust
A ranking is the sum of many signals attached to a URL. Move the URL and keep the signals identical, and rankings tend to follow. Change both at once and you are running two experiments you cannot tell apart.
Hold these constant through the move unless you have a deliberate reason to change them:
- Page titles and headings.
- On-page copy and its structure.
- Internal links, updated to point at the new URLs directly rather than through redirects.
- Canonical tags, structured data, and image alt text.
This is also the moment teams try to “improve everything” while the site is already torn open. Resist it. Migrate first, holding content steady, confirm rankings survive, then optimise from the stable new baseline. A clean technical SEO checklist tells you which signals to verify, and an on-page SEO guide covers what to refine once the dust settles. Doing those edits during the cutover only muddies the cause when a number drops.
Stage it, test it, then cut over
A migration should never be tested in public. Stand the new site up on a staging environment behind authentication, and make sure that environment cannot be indexed. Block crawlers, and drop the block the instant you go live so you are not accidentally hiding the real site.
Before launch, run a parity pass:
- Crawl staging and compare it against the production crawl. Look for missing pages, broken internal links, and titles or metadata that changed without intent.
- Run the full redirect map against staging and confirm every old URL lands on the right new URL in one hop with a 301.
- Spot-check the highest-traffic and highest-link pages by hand. Automated crawls miss things a person notices in five seconds.
Then cut over deliberately. Launch during a low-traffic window so a problem touches fewer people. Submit fresh XML sitemaps for the new URLs. If the domain changed, use Search Console’s change-of-address tool and keep both the old and new properties verified so you can watch the handoff from both sides.
Watch the right numbers after launch
The first week after a migration is noisy. Rankings wobble, crawl rates spike, and panic is a bad advisor. Watch the signals that tell you something real:
- Server logs and Search Console for 404s and unexpected redirect behaviour. Fix broken redirects the day you find them.
- Index coverage, to confirm the new URLs are getting picked up and the old ones are dropping out cleanly.
- Rankings by individual URL, not site-wide averages. An aggregate number hides the one cluster that fell off.
Give it time. A clean domain or structure migration often dips for two to four weeks before it recovers, and full settling can take a couple of months. A dip is expected. A cliff that does not recover is a redirect map with holes in it, so go back to the inventory and find the URLs you missed.
How Strynal approaches website migration
We treat the redirect map as the center of the project, not a chore at the end. Before any new page is built, we know every URL that earns something and where it is going. The same senior people who scope the migration build it, so the person mapping a high-value page to its successor is the person who understands why it ranks. That continuity is what keeps the invisible work from being skipped under deadline pressure.
If you are planning a redesign, a replatform, or a domain move and the traffic you already have is worth protecting, that is exactly the kind of work our websites and apps practice is built for. Tell us what you are moving and we will tell you where the risk actually sits.