How to Migrate a Website Without Losing Rankings

Why an indexed URL inventory is the only safe starting point

You are about to move your site. Google already knows every URL it has indexed. If you miss even a fraction of those, the missing pages will 404, and their rankings will vanish overnight. A sitemap alone is not enough—it only shows what you want indexed, not what actually is.

Pull a complete list from Google Search Console (GSC) under “Indexing > Pages”. Export the CSV. Then cross-check it with server logs for the last 30 days. Server logs show every request, including those from Googlebot that GSC might miss. For sites over 10,000 pages, this can take a full day of manual review. The trade-off is clear: spend the time now or lose 20-30% of organic traffic in the first month.

A UK e-commerce site migrated without checking paginated category URLs. Their inventory only listed the first page of each category. The paginated URLs (page=2, page=3) 404’d. Within a week, their category rankings dropped from position 3 to position 12. The fix took three weeks of redirect mapping and resubmission to GSC.

For large sites, prioritise URLs with backlinks or traffic. Use Ahrefs or Majestic to filter the inventory. Redirect the high-value pages first, then handle the long tail. This keeps the immediate traffic drop to under 5% while you clean up the rest.

When preserving a URL beats redirecting it—and how to decide

A 301 redirect tells Googlebot to transfer link equity to a new URL. That transfer is not instant. Googlebot re-crawls redirected URLs 3-5x slower than originals. If the new URL is slower, has different internal links, or weaker content, the ranking may never recover.

Before you redirect, measure the link equity of the old URL. In Ahrefs, check the “Backlinks” and “Referring Domains” count. If the old URL has 50+ backlinks from authoritative sites, preserving it is usually safer. Redirect only if the new URL is a clear improvement—better content, faster load time, or a more logical structure.

A SaaS site kept their /pricing URL instead of redirecting to /plans. The /pricing page had 120 backlinks, including links from TechCrunch and The Guardian. Redirecting would have risked a 10-15% drop in rankings. By preserving the URL, they kept their position at #2 for “SaaS pricing UK” and saw no traffic loss.

What goes wrong: redirect chains. A chain happens when URL A redirects to URL B, which redirects to URL C. Each hop leaks 10-15% of PageRank. Googlebot may also give up before reaching the final URL. Use Screaming Frog to audit your redirects. If you find a chain, flatten it to a single hop.

How to implement single-hop redirects without technical debt

Server-side redirects are faster and more reliable than application-level redirects. Apache’s .htaccess or Nginx’s server blocks execute before PHP or JavaScript loads. This cuts latency by 50-100ms. For a site with 10,000 redirects, that adds up to a full second of saved load time.

The trade-off is maintenance. Server configs are harder to update than a WordPress plugin. If you use .htaccess, keep the file under 1,000 lines. Larger files slow down every request. For Nginx, split redirects into separate include files. Test every redirect before going live. Use curl or Redirect Path to verify the status code and destination.

A UK news site switched from WordPress plugins to Nginx redirects. Their old setup added 250ms of latency per redirect. The new Nginx config reduced that to 80ms. Their Largest Contentful Paint (LCP) improved from 3.2s to 2.1s, and their mobile rankings for breaking news queries climbed from position 5 to position 2.

What goes wrong: regex patterns that create loops. A common mistake is using (.*) in a regex without anchoring it. This can match the destination URL, creating an infinite loop. Always test regex redirects with a tool like Regex101. For mobile vs. desktop URLs, use separate rules with explicit conditions. Never assume the pattern will work for both.

Why your new site must be faster than the old one (and how to test it)

Google’s Core Web Vitals are ranking factors. Your new site must meet these thresholds: Largest Contentful Paint (LCP) under 2.5s, First Input Delay (FID) under 100ms, and Cumulative Layout Shift (CLS) under 0.1. If your new site is slower, rankings will drop, even with perfect redirects.

Test speed with Lighthouse CI and WebPageTest. Lighthouse gives lab data, which is useful for debugging. WebPageTest provides real-world data from different locations and devices. Run tests on the old site first to establish a baseline. Then test the new site under the same conditions. If LCP increases by more than 0.5s, fix it before launch.

A local service site migrated to a new CMS. Their old site had an LCP of 2.1s. The new site’s LCP was 3.8s. Within two weeks, their mobile rankings for “emergency plumber London” dropped from position 4 to position 11. They fixed the issue by deferring non-critical JavaScript and optimising images. Rankings recovered within a month.

The trade-off is functionality. Deferring JavaScript can break interactive elements like forms or chat widgets. Test these elements thoroughly. If they break, prioritise the ones that drive conversions. A fast site with a broken chat widget is better than a slow site with a working one.

How to monitor rankings during migration without false alarms

Google Search Console’s “Performance” report lags 2-3 days. For real-time data, use a rank-tracking tool like Ahrefs or SEMrush. Set up tracking for your top 20% of keywords—they drive 80% of your traffic. Track daily, but don’t react to single-day fluctuations. Rankings can swing 10-15% in a day due to normal SERP volatility.

The trade-off is cost. Tracking 100% of keywords is expensive and noisy. Focus on the keywords that matter. For a site with 1,000 keywords, track the top 200. Use GSC to monitor the rest. If you see a drop in GSC, cross-check it with your rank-tracking tool.

A B2B site panicked when their rankings dropped 15% on day 3. They considered rolling back the migration. By day 7, rankings had recovered. The drop was temporary volatility, not a permanent loss. If they had rolled back, they would have wasted a week of development time and risked further instability.

What goes wrong: misinterpreting data. A drop in rankings can mean many things—crawlability issues, indexing delays, or algorithm updates. Don’t assume the migration is the cause. Use GSC’s “Coverage” report to check for crawl errors. Use the “site:” search operator to verify indexing. Only act if the data confirms a problem.

What to do when rankings drop after migration (a 72-hour checklist)

If rankings drop, start with crawlability. Check GSC’s “Coverage” report for errors. Look for spikes in “Crawled – currently not indexed” or “Discovered – currently not indexed”. These indicate Googlebot is struggling to access your pages. Next, verify indexing with a “site:” search. If pages are missing, resubmit your sitemap in GSC.

Googlebot may take 48-72 hours to re-crawl redirected URLs. Even with a sitemap update, it can take this long. Don’t panic if rankings don’t recover immediately. Monitor GSC’s “Indexing > Pages” report. If the number of indexed pages stabilises, the issue is likely temporary.

An agency site lost 30% of organic traffic after migration. They checked GSC and found 40% of their pages were “Crawled – currently not indexed”. They resubmitted their sitemap within 24 hours. By 72 hours, indexing had recovered, and traffic returned to normal.

The trade-off is manual intervention. You can wait for Googlebot to self-correct, or you can request re-indexing via GSC. For high-value pages, request re-indexing. For the rest, wait. Over-submitting can trigger rate limits and delay the process.

How to avoid the ‘new site penalty’ from Google’s algorithm

Google’s “site move” classifier processes migrations. It can take 1-2 weeks to recognise your new site as a continuation of the old one. During this time, rankings may fluctuate. To help the classifier, signal the move using GSC’s “Change of Address” tool. This tells Google your domain has changed, if applicable.

Keep your internal linking structure identical. If your old site linked to /about from the homepage, the new site should do the same. Changing internal links confuses Google’s classifier. It may treat the new site as a separate entity, not a continuation of the old one.

An e-commerce site changed their URL structure, navigation, and content during migration. Their rankings dropped 40% and never recovered. A competitor kept their internal linking identical and saw no traffic loss. The difference was clear: Google’s classifier could not map the new site to the old one.

What goes wrong: simultaneous changes. If you change URLs, navigation, and content at the same time, Google can’t isolate the cause of ranking drops. Make changes in stages. Migrate the site first, then update content, then tweak navigation. This way, if rankings drop, you know which change caused it.

Next steps

You have the safeguards. Start with the URL inventory. Pull the list from GSC and server logs. Cross-check it with Ahrefs or Majestic to prioritise high-value pages. Then map your redirects. Preserve URLs where possible, redirect where necessary. Test speed with Lighthouse CI and WebPageTest. If the new site is slower, fix it before launch.

Set up rank tracking for your top 20% of keywords. Monitor GSC for crawl errors. If rankings drop, follow the 72-hour checklist. Use the “Change of Address” tool if you’re changing domains. Keep internal linking identical to avoid confusing Google’s classifier.

If you need help, we offer a migration audit. We’ll review your URL inventory, redirect map, and speed tests before launch. The audit costs £1,200–£2,500, depending on scope. Email hello@fugenservices.com to schedule one.