Website migrations without losing your rankings
A migration is a transfer of every ranking and link your site has earned, not just a build project. Here is the technical care that keeps traffic through the switch.
A migration is a transfer of authority, not a launch
When people say website migration, they usually picture the new design. What actually changes underneath is the set of URLs that search engines have spent years learning to trust. A replatform, a redesign, a move to a new domain, an HTTP to HTTPS switch, or the consolidation of several sites into one: each of these moves, renames or rebuilds addresses that already carry rankings and links. On the surface it is a build project. In practice it is a transfer of every piece of accumulated authority your site holds, and that transfer is where traffic quietly goes missing. The reason migrations are dangerous is that the damage is invisible on launch day. A site can go live looking sharp, pass every stakeholder review, and still shed a large slice of its organic traffic three or four weeks later because a batch of redirects was missed or a template dropped its internal links. By the time the fall lands in a report, the launch team has moved on and the cause is buried under a hundred other changes. Treating the migration as an SEO event from the outset, rather than a design milestone, is what keeps that gap from opening.
Start with a URL map, not a launch date
Before a single page moves, you need a complete inventory of the URLs you have today, each one weighted by the rankings, links and traffic it holds. Pull it from more than one source. Your crawl gives you what exists, Search Console shows you which pages actually earn impressions and clicks, your analytics shows what converts, and a backlink tool shows which URLs external sites point at. A page can be near-invisible in your navigation and still be the single most linked-to address on the domain. Those are exactly the ones a redesign tends to forget. Every URL on that inventory then gets a destination on the new site: keep, redirect to a true equivalent, or, occasionally, retire on purpose with eyes open. That mapping document becomes the single source of truth the whole migration is checked against. It is the difference between a controlled transfer with a paper trail and a hopeful cutover where nobody can say afterwards what was supposed to happen to a given page. If you take one thing from this article, make it this: the map comes before the launch date, not after it.
Redirect strategy is a discipline in its own right
Redirects are how you tell a search engine that the address it trusted has permanently moved somewhere specific, and how you pass the authority behind the old URL to the new one. Done well, they are unglamorous and complete: a permanent 301 from each retired URL to its genuine equivalent, one to one, so the page about a service points at the new page about that service rather than being swept into a homepage catch-all. The catch-all is the classic false economy. It technically resolves every old link, so the site looks fine, but it tells search engines those pages have no specific successor, and the rankings they held dissolve. The details are where migrations are won or lost. Redirect chains, where one URL hops through two or three others before landing, waste crawl budget and dilute signals, so they should be collapsed to a single hop. Loops need to be caught before launch, not by a user hitting an error. Old redirects from previous migrations have to be carried forward, or you break a link that was working. And the map has to be re-verified live at cutover, because a plan that is correct in a spreadsheet is worth nothing if the rules never fire on the production server. This is deliberate, checkable work, which is why we treat redirect strategy as its own dedicated discipline rather than a box ticked on the way out the door.
Keep parity: the new site has to say what the old one said
Rankings are earned by specific content on specific pages. If a redesign trims body copy in the name of a cleaner look, drops the title and meta description that were tuned to a query, or thins out the internal linking that passed authority around the site, the new page can be pointed at correctly by a perfect redirect and still rank for less, because the thing that earned the ranking is gone. Parity is the discipline of checking that the new build carries forward what was doing the work: the substance of the content, the metadata, the headings, the structured data, and the internal links between pages. Internal links deserve particular attention because they are so easy to lose in a template change. On the old site, a page might have gathered links from a dozen related articles and a navigation block. Rebuild the templates and those links can silently vanish, so a page that used to sit at the centre of a well-linked cluster is suddenly stranded. We check parity on staging against the old site as the reference, rather than assuming the two match, precisely because the losses are the kind nobody notices in a visual review. A redesign is the right moment to improve a site. It is the wrong moment to quietly delete the pages and text that pay for it.
Prove it on staging before you cut over
Almost everything that goes wrong in a migration is cheaper to fix before launch than after. That makes the staging environment the most valuable window you have. With the new build live behind a password, you can crawl it as a search engine would and check the things that decide whether rankings survive: that redirects resolve in a single hop to the right place, that content and metadata parity holds, that pages are crawlable and render their content rather than hiding it behind script that a bot never runs, and that the canonical tags and sitemap point where they should. The one thing to watch on staging is accidental blocking. Sites in development are usually walled off from search engines with a robots directive or a noindex tag, and if that protection ships to production it tells search engines to drop the entire site. It is a small setting with a total effect, and it belongs at the top of the go-live checklist. Everything you verify on staging is something you are not scrambling to diagnose on live traffic the week after launch, when the cost of every hour is measured in lost visits.
The first few weeks decide whether it worked
A migration is not finished at cutover. It is finished several weeks later, once search engines have recrawled the site, followed the redirects, and settled the new URLs into the positions the old ones held. That recrawl is not instant, which is why traffic falls so often surface two to four weeks after launch rather than on day one. The window immediately after go-live is the fragile part, and it is where close attention pays for itself many times over. So watch it deliberately. Confirm the redirects are firing on production, submit the new sitemap, and monitor indexation, rankings, crawl errors and server response codes through the risky weeks. When something slips, and on a real migration something usually does, catching it in days means a quick correction; discovering it in a quarterly review means weeks of lost traffic and a much harder recovery. If you have already migrated and lost traffic, the same diagnostic approach applies in reverse: work back through the map, the redirects and the parity checklist to find what was missed, and recover what is recoverable. The safest migration is a boring one, where the analytics hold steady, there is no scramble the week after launch, and the authority you spent years building still points where it should.