Almost every major site update is a migration: a domain change, a move to HTTPS, a new platform, or a full redesign with new page addresses. And nearly half the migrations we see in an audit are done in a way that quietly costs the site traffic. The cause is almost always the same — something Google already knew and valued didn’t get carried over, or got broken. Here’s the plan we follow on migrations so rankings stay put.
What a site migration is and why it’s risky
A migration is any change that puts your pages at new addresses or on a new technical foundation. For a search engine, that means a re-evaluation: it has to map old URLs to new ones, recrawl the pages, and confirm the content and signals carried over. While it does that, rankings can wobble. If the mapping is broken, some pages simply drop out of the index — and take their traffic with them.
The risk grows when one release bundles several changes at once: a new domain plus a new URL structure plus a redesign. Then, if traffic dips, it’s hard to tell what caused it. So the first rule is to change as little as possible at a time.
Types of migrations: from protocol to full redesign
The easiest moves are technical ones with no address change: switching to HTTPS, changing servers or hosting. The URLs stay, so the risk is minimal. Harder ones are a domain change or merging several sites into one. The riskiest is a redesign with a new URL structure, where the addresses, the layout, and often the content all change at once.
A CMS change (say, a move to WordPress) is its own case. Here it’s critical that the new platform serves the same addresses or correct redirects, and keeps the site fast and cleanly structured. If you’re rebuilding anyway, it’s worth getting the technical foundation right from the start — we cover that in our piece on SEO-friendly web development.
The main rule: keep your URLs where you can
The safest migration is one where page addresses don’t change at all. If you’re redesigning but can keep the URLs the same, keep them. Every changed address is one more redirect, one more place something can break, and a little more diluted signal.
When a change is unavoidable (say, the old structure was chaotic), map out a clean new URL scheme ahead of time and lock it before launch. For online stores, plan separately for filters and parameters — a big topic we covered in our article on store filters and indexing.
A 301 redirect map with no chains or losses
The heart of any migration that changes addresses is the redirect map — a table pairing each old URL with a new one. Build it one-to-one: each old page points to its closest new equivalent, not everything to the homepage. A blanket redirect to the homepage tells Google the page is gone, and the traffic disappears with it.
| Step | Do this | Common mistake |
|---|---|---|
| Redirect type | 301 (permanent) | 302 (temporary) or JS redirect |
| Mapping | 1:1 to a relevant page | everything to the homepage |
| Chains | old to new directly | old to interim to new |
| Lost pages | redirect to the closest topic | serving a 404 with no replacement |
| Internal links | update to the new URLs | leaving old ones that route through a redirect |
Use a 301, not a 302, and avoid redirect chains. A 302 tells the engine the move is temporary and not to transfer signals, and a chain (old to interim to new) loses a bit of weight at each hop and slows down crawling.
What else to carry over one-to-one
Redirects are just the transport. It’s just as important to preserve the page content: copy, H1s, titles and descriptions, image alt text, structured data. If you rewrite half the content while you’re at it during a redesign, you stack two changes on top of each other — and you won’t know later whether a dip came from the technical move or the new copy. It’s better to change content in a separate release, after the migration has settled.
Check separately that the support files moved and updated: robots.txt, the XML sitemap, and canonical tags. An old sitemap full of old URLs will only confuse the crawler after the move.
A technical checklist before launch
Before you go live, run through a basic checklist on staging. That’s the cheapest moment to catch a mistake — before Google sees it.
- The 301 redirect map is built and tested on the staging domain.
- Every internal link points to the new URLs directly, with no redirects in between.
- Titles, descriptions, H1s, and canonicals are carried over for every page.
- robots.txt isn’t blocking indexing (a classic mistake is leaving Disallow from staging).
- The XML sitemap is updated and contains only the new URLs.
- Tracking is in place: GA4 and Search Console work on the new version.
- Speed is checked, so the new design doesn’t break Core Web Vitals.
Launch day: the order of operations
On moving day the order is: turn on the redirects, open the site to indexing, and immediately spot-check a few key pages by hand (do they load, is the redirect right, is the title in place?). Then add the new property and the new sitemap to Search Console, and use the change-of-address tool if you moved domains. Don’t remove the old redirects for at least a year — Google keeps coming back to old URLs long after the move.
A store moved to a new platform with a new URL structure. Before launch we built a map of several thousand 1:1 redirects, updated the internal links, and left the sitemap with only the new addresses. The dip was about 8% of traffic for two weeks, after which rankings recovered and passed the old levels. Without a 1:1 map, the loss would have been several times larger and longer.
After launch: monitoring in Search Console and GA4
The first two to three weeks matter most. In Search Console, watch the indexing report (are errors rising?), coverage, and 404s. In GA4, compare traffic by section against the period before the move, so you can spot exactly where it dipped. A spike in 404s means some old URLs weren’t covered by redirects — add them to the map. It’s also worth running a technical audit on the new version to catch small issues that are easy to miss by hand.
If the move is complex, bring in a technical SEO team at the planning stage, not after a dip — fixing is always costlier than preventing.
What not to do during a migration
Over years of moves we’ve collected a short list of what most often breaks traffic. Don’t launch a migration on a Friday evening or right before peak season — if something goes wrong, you’ll notice it late and at the worst possible moment. Don’t change the domain, the URL structure, and the design all at once when you can split them into separate releases. And don’t lean on temporary 302s for now — they have a habit of staying forever, and they don’t move signals to the new address.
One more piece of advice: don’t switch off the old redirects right after the move, and don’t delete the old sitemap in the first week while the new one isn’t fully indexed yet. Give the search engine time to recrawl calmly — rushing at this stage costs more than any other migration mistake, because you’re cutting the bridge between the old and new site while Google is still using it.
The takeaway
A good migration is invisible to the user and nearly invisible to the search engine: addresses lead where they should, the content is intact, and speed hasn’t dropped.
A migration isn’t scary if you prepare for it: change as little as possible at once, build a one-to-one 301 map, keep your titles and content, update internal links, and monitor closely for the first few weeks. Rushing — and redirecting everything to the homepage — is what actually costs you traffic.
Frequently asked questions
Does traffic always dip after a migration?
A small ranking wobble is normal while the search engine recrawls the site — usually a few days to a few weeks. If everything is carried over correctly, traffic returns and often passes its previous level.
Which redirect should I use — 301 or 302?
For a permanent move, only a 301. It tells the search engine to move the signals to the new address. A 302 is temporary, used only when the old page will actually come back.
Can I redirect all old pages to the homepage?
No. A blanket redirect to the homepage reads to Google as the page being gone, and the traffic disappears. Each old URL should point to the closest relevant new page.
How long should I keep the old redirects?
At least a year, and ideally for good. Search engines return to old URLs long after a move, so removing redirects early leads to 404s and lost traffic.
Can I update content and design at the same time as the move?
Better not to. Several changes in one release make it hard to diagnose a dip. Stabilize the migration first, then handle content updates as a separate step.
What should I check first if traffic doesn't come back?
The 301 redirect map, canonicals, and robots.txt. In most cases that's the cause: uncovered old URLs, temporary redirects, chains, or indexing accidentally blocked from staging.
Web developer at heleum.studio. Builds fast WordPress sites that pass Core Web Vitals and don't need a rebuild six months later.
