How to Migrate a Website Without Losing Your Google Rankings

Website migrations go wrong in a predictable way. The old site gets turned off, the new one goes live, and a few weeks later the client notices their Google rankings have dropped. Not because the new site is worse, but because the URL structure changed and nobody told Google where the content moved.

The fix is a redirect map. Build it before you touch the new site. Implement it before the old site goes offline.

What a Redirect Map Is and Why It Matters

A redirect map is a spreadsheet that lists every URL on the old site alongside the URL it should redirect to on the new site. When Google visits an old URL, it gets a 301 (permanent) redirect to the new location. The ranking equity attached to the old URL transfers to the new one.

Without this, Google encounters URLs it has already indexed and finds nothing. The server returns a 404. The ranking disappears. If those pages had backlinks from other sites, that link equity is also lost because the destination no longer exists.

Building the redirect map has 4 steps.

First, crawl the existing site with a tool like Screaming Frog before any migration work starts. Export every URL, including the ones you think are unimportant. A page buried in the site structure with a single authoritative backlink can still be driving ranking signals.

Second, build the new site URL structure and map old URLs to new ones in the spreadsheet. Some will be direct equivalents where only the domain changes. Others will need thought: a category page that is being removed needs to redirect to the closest relevant page, not to the homepage.

Third, flag any URLs that are being consolidated. If 3 service pages are merging into 1, all 3 old URLs redirect to the single new one.

Fourth, flag any URLs that are genuinely being removed with no equivalent. These need a redirect to the most relevant page on the new site. Redirecting to the homepage is acceptable as a last resort. A more specific destination is always better.

Implementing Redirects Correctly

For WordPress sites, redirects go in the .htaccess file at the root of the hosting account, or through a plugin like Redirection if direct file access is not available. The syntax for a 301 redirect in .htaccess is straightforward:

Redirect 301 /old-page/ https://newsite.com/new-page/

For Next.js sites, redirects are configured in next.config.js under the redirects function. Each redirect is an object with source, destination, and permanent: true.

Test every redirect before launch. Not a sample. Every one. A CSV of 40 redirect rules takes about 20 minutes to verify systematically. Finding a broken redirect before launch costs nothing. Finding it after, when Google has already crawled the 404 and dropped the ranking, costs weeks of recovery.

The Luigi's Deli Migration

Luigi's Deli was an 18-page rebuild. The old site had a URL structure that mixed underscores and hyphens, used non-descriptive page names in several places, and had some category pages that were being removed entirely in the new structure.

We crawled the old site before starting the build and got 23 URLs that needed explicit redirect handling. Some were easy: /our_products.php became /products/. Others required decisions: 2 pages covering similar content were consolidated into 1, meaning both old URLs redirected to the single new page.

We also found 4 URLs that Google Search Console showed as having inbound links. These were prioritised and we made sure their redirect destinations were as specific as possible, not the homepage.

The redirect map was implemented in .htaccess and tested completely before the domain DNS was updated. After launch, we submitted the new sitemap through Search Console and monitored for 404 errors daily for the first 2 weeks.

The Search Console Steps Before and After

Before migration: verify both the old and new property in Google Search Console if they do not share a domain. Note the current ranking positions and organic traffic for the most important pages. Export the top 50 URLs by clicks from the Search Console Performance report. These are your priority pages.

After migration: submit the new XML sitemap through the new Search Console property. Use the URL Inspection tool to request indexing of the most important new URLs. Watch the Coverage report for 404 spikes. A spike in 404s after a migration is a signal that redirect rules are missing or incorrect.

Watch the Performance report daily for the first 2 weeks. Organic traffic to key pages should hold or recover within that window if the redirect map was complete. If specific pages show a sharp drop, investigate the redirect for that URL first.

The 30-Day Hold Period

Do not declare a migration successful at launch day. Rankings can take time to update after a redirect. Google needs to crawl the old URL, follow the redirect, crawl the new URL, and update its index. For a site with moderate crawl priority, this can take 2 to 4 weeks.

The 30-day hold is the period after which you can assess whether the migration held. Look at organic traffic to the key pages compared to the pre-migration baseline. Look at ranking positions for the terms you cared about. If both are stable or recovering, the migration worked.

If you see sustained drops after 30 days, dig into the redirect map. Check whether any redirects are chains (A redirects to B which redirects to C: Google follows these but they are less efficient). Check whether any pages that should have been redirected were missed.

Migration done properly is not exciting. It is methodical. The goal is for Google to barely notice the site changed.

If you are planning a rebuild or domain change and want a migration process that actually protects your rankings, we handle this as part of every website project we take on. You can also contact us to talk through the scope before committing.