How to Migrate a Website Without Losing Your Google Rankings

Losing search traffic overnight is the single biggest fear behind almost every migration conversation we have, and it is also the most preventable failure in the entire process. Rankings are not lost because a site changes platforms, they are lost because redirects are missing, content changes meaning without warning, or nobody checked what Google actually had indexed before launch.

Map Every Indexed URL Before You Touch Anything

Before any code changes, pull a full list of currently indexed URLs from Google Search Console and your existing sitemap, not just the pages in your site's navigation. Orphaned blog posts, old category pages, and even parameterized URLs can carry real search equity that a rebuild will otherwise silently drop. While you're in Search Console, check the Links report too: your highest-value backlinks are worth knowing about before launch, because a redirect protects your own rankings but does nothing for an external site's readers still clicking a link to the exact old URL — for your most important backlinks, a message to the linking site asking them to update the link directly is worth the effort a redirect alone can't replace.

Build a One-to-One Redirect Map, Not a Blanket Rule

A single "redirect everything to the homepage" rule is the fastest way to destroy years of rankings. Every old URL needs a 301 redirect to its closest actual equivalent on the new site, tested individually before launch, not assumed to work because the pattern looks similar. Redirect chains deserve the same scrutiny: an old URL that redirects to a page that itself redirects again dilutes the ranking signal with every extra hop, and it's an easy mistake to introduce by accident when a URL structure changes twice during a long project. Every redirect in the map should resolve in a single hop, verified by actually following it, not by reading the rule and assuming it does.

Preserve the On-Page Signals That Earned the Ranking

Title tags, header structure, and core body content are what Google actually matched the query to in the first place. A redesign is a good moment to improve these, but wholesale rewrites during a migration make it hard to isolate what caused a ranking change if one happens, so change deliberately and keep a record of what moved. Structured data deserves the same discipline: schema markup for articles, products, FAQs, or reviews often gets dropped entirely in a rebuild simply because nobody explicitly ported it, even when every other on-page signal survived the move intact. If the old site had schema markup earning rich results in search, the new site needs the equivalent markup live before launch, not added later as a follow-up task that quietly never happens.

Update Internal Links, Don't Just Rely on Redirects

A redirect map protects a URL from breaking, but it doesn't fix the dozens of internal links across the site still pointing at the old URL pattern instead of the new one. Every internal link that survives a migration by riding a redirect instead of pointing directly at the new URL adds an unnecessary hop to crawl budget and a small amount of diluted link equity, multiplied across every page that links to it. Before launch, the new site's internal links, navigation, footer, related-content blocks, and in-content links from other pages, should point directly at the new URL structure, with redirects treated as a safety net for external and historical links, not as the mechanism the site itself relies on.

The Staging Noindex Tag That Never Gets Removed

This is one of the most common, and most embarrassing, ways a migration destroys rankings, and it has nothing to do with redirects. Staging and development environments are almost always set to block search engines, usually with a blanket noindex tag or a robots.txt disallow rule, so an unfinished site doesn't get indexed by accident. The failure mode is launching the production site with that same block still in place, because it was set once early in the project and nobody's launch checklist explicitly says to remove it. The entire site can sit live and fully functional while quietly telling Google not to index any of it, and because the site looks completely normal to a human visitor, this often isn't caught until rankings have already dropped to zero. Checking the live production site's robots meta tag and robots.txt, not the staging environment's, needs to be the very last step before calling a launch complete.

Watch Crawl Stats, Not Just Rankings

Once live, submit the new sitemap in Search Console and watch crawl stats, index coverage, and rankings for the specific keywords that mattered before the move. Crawl stats specifically are worth checking before rankings even move, because they show whether Googlebot is actually reaching the new URLs and following the redirect map correctly, days before a ranking change would be visible. A spike in crawl errors or a redirect map that Google reports as broken is the earliest possible warning that something needs fixing, and it arrives long before the slower signal of rankings actually shifting. Recovery is usually fast when the redirect map is right, and slow, expensive troubleshooting when it is not.

If you are planning a migration and want your redirect map and SEO signals audited before launch, our Pricing page outlines what that review includes, or reach out through our Contact page for a free technical audit.