Move Your Website Without Losing Your Google Rankings

Why website migrations tank rankings — and why they don't have to

A website migration is any change big enough to alter your URLs: a new domain, a switch from HTTP to HTTPS, a platform move (say WordPress to a custom build), a redesign that renames pages, or merging two sites into one. Google sees new addresses where old ones used to be. If it can't follow the trail from the old URL to the new one, the ranking authority you earned over years has nowhere to land.

Here's the reassuring part: ranking loss during a migration is almost always self-inflicted. The pages that crater are the ones nobody redirected, the ones that got renamed with no map back to the original, and the ones stripped of the content that ranked them in the first place. Google's own guidance is that a permanent redirect passes ranking signals to the new URL — it does not treat a 301 as a reason to drop a page. So when authority disappears in a migration, it's because a redirect is missing or broken, not because moving a page is inherently risky. Do the mapping work and the rankings follow the pages to their new home.

It helps to name the specific ways migrations go wrong, because each one is preventable. Pages get left off the inventory and quietly 404. URLs get renamed and pointed at the homepage instead of their real equivalent. Redirects get set as temporary (302) when the move is permanent. Redirect chains pile up three and four hops deep. A staging-site "noindex" tag or a blocking robots.txt ships to production and tells Google to ignore the whole site. Content gets rewritten at the same time as the move, so Google can't tell whether a page still deserves its old ranking. Every item on that list is a decision someone made — or forgot to make — not an act of the algorithm.

For a Virginia service business — a Hillsville contractor, a Roanoke clinic, a Blacksburg shop — your top-ranking pages are often your single biggest source of leads. A botched migration doesn't just dent a vanity metric; it turns off the phone. A page that used to rank for "emergency plumber in your town" and now returns a 404 isn't a chart line dropping — it's calls you never get. That's exactly why website migration SEO deserves a plan before anyone touches the new site, not a scramble the week after launch. The steps below are that plan, in order, with the specific checks that keep each stage from becoming the mistake that costs you traffic.

Step 1: Crawl and inventory every URL before you touch anything

You cannot preserve what you haven't counted. Before the new site exists, build a complete inventory of every URL on your current site — every service page, blog post, location page, image, and PDF that Google might have indexed. Miss a page here and it becomes a dead end after launch, because a redirect only exists for URLs you knew to map.

Pull your URL list from several sources so nothing slips through. Any single source has blind spots; overlapping them is how you catch the orphan pages:

• A full site crawl using a tool like Screaming Frog to catch every internal page the site links to.
• Google Search Console — export the Pages report and the Performance report to see which URLs actually earn impressions and clicks. This catches indexed pages your crawler can't reach through internal links.
• Your current XML sitemap for the URLs you told Google to index.
• Server logs or analytics for pages that get traffic but aren't linked anywhere obvious — old landing pages, campaign URLs, PDFs.

Deduplicate those lists into one master inventory. Now benchmark, because this is the only chance you get to record "before." Save your current rankings for your money keywords, note your top 20 or 30 pages by organic traffic, and write the numbers down somewhere you'll find them in three months. This baseline is how you'll tell a broken redirect from ordinary fluctuation later — without it, every post-launch dip is a guess.

Then flag the high-value pages inside the inventory so they get extra care in mapping and extra scrutiny in testing. The service page that drives real calls and the town-specific landing page that ranks locally are not the same priority as a five-year-old blog post nobody reads, and your redirect map should reflect that. Everything downstream depends on this list being complete, so spend the extra hour making sure it is — it is far cheaper than discovering a missing page from a 404 report after you've lost its rankings.

Step 2: Map old URLs to new ones, one to one

This is the single most important step, and the one most often rushed. For every old URL in your inventory, decide the exact new URL it will become. The standard is one-to-one mapping: each old page points to its closest equivalent new page, not to a generic homepage or a broad category page. Google treats a redirect to an unrelated page much like a page that no longer exists, so a lazy map quietly throws away rankings even when every redirect technically "works."

Build this as a simple two-column spreadsheet — old URL on the left, new URL on the right — and account for every single row from Step 1. If your URL structure isn't changing at all (a same-domain redesign that keeps the same paths), you may not need redirects for those pages, but you still confirm each one resolves on the new build. Where the structure changes, map deliberately, page by page.

A few rules that protect your authority:

• Never dump many pages onto the homepage. Redirecting dozens of old service pages to "/" tells Google those pages are gone, and their rankings go with them. If the old page had a topic, the new destination should share that topic.
• Consolidate honestly. If you're merging two thin pages into one stronger page, point both old URLs at the new combined page — that's a legitimate one-to-one map, just with two rows landing on the same destination.
• Retire dead weight on purpose. A truly obsolete page with no traffic and no inbound links can return a 410 ("gone"), but make that a deliberate call in the spreadsheet, not an accident of a page you forgot.
• Watch for parameters and trailing slashes. If old URLs used query strings, capital letters, or inconsistent trailing slashes, decide the canonical new form and map the variants to it so you don't ship four versions of one page.

A clean map is the backbone of a low-risk migration, and it's genuinely the work — the redirect setup in the next step is mechanical once the map is right. If mapping hundreds of URLs feels overwhelming, that's a normal point to bring in help; it's core to how we handle web development projects that touch an existing, ranking site.

Step 3: Set permanent 301 redirects — and skip the chains

Once your map is built, you implement it as redirects. Use permanent (301) redirects, done server-side. A 301 tells Google "this page moved for good, send its signals to the new address." A temporary (302) redirect says the opposite — that the old URL will come back — so Google is slow to move ranking signals and may keep the old URL in the index. For a permanent move, that hesitation costs you rankings, so getting the redirect type right is not a detail; it's the whole point of the step.

The most damaging mistake here is the redirect chain: old URL A redirects to B, which redirects to C, which finally lands on the live page. Every hop adds latency, slows crawling, and gives Google a longer trail to follow — and long or looping chains can stop Google from reaching the destination at all. Redirect each old URL straight to its final destination in one hop. If your platform or plugins generate their own redirects (a trailing-slash rule plus a www rule plus your map, for example), those can stack into a chain without anyone writing it on purpose, so test for it rather than assume.

A working checklist for this step:

• Every old URL from your inventory has a live 301 pointing at its mapped destination — spot-check the full map, not just a few.
• No chains: test a sample of URLs and confirm each resolves in a single redirect to a 200 page.
• If you're moving to a new domain or to HTTPS, redirect the www and non-www, and the http and https variants, consistently so there is exactly one canonical version of each page.
• Internal links inside the new site point directly to the new URLs, not through the redirects — otherwise you build a chain into your own navigation.
• Your new XML sitemap lists only the final new URLs (200s), never the old ones or the redirects.

This is where a lot of DIY migrations quietly break, because redirects live in server config, .htaccess, or platform settings that aren't visible on the page. Test them before launch, on staging, not after — a redirect you verify at 2 a.m. on launch night is a redirect you're verifying in the worst possible conditions.

Step 4: Keep the content, titles, and structure that earned your rankings

Redirects move a page's address; they don't recreate what made it rank. If you migrate and simultaneously gut the content — shorter pages, reworded headings, deleted sections — you're asking Google to re-evaluate every page from scratch at the exact moment it's already reprocessing the whole site. That's when even a technically perfect migration loses traffic, and it's the hardest kind of loss to diagnose because the redirects all check out.

The safest migrations change one thing at a time. If your priority is preserving rankings, move first and redesign the content later, once the new URLs have settled. On your important pages, carry over the elements Google reads for relevance:

• Title tags and meta descriptions — keep them or improve them, but don't erase them or let the new platform overwrite them with defaults.
• H1 and heading structure — the words in your headings signal what the page is about; keep the language that matched what people searched for.
• Body copy and internal links — the substance that ranked the page should survive the move, including the internal links that pass authority between your pages.
• Structured data — if you had LocalBusiness, Service, or FAQ schema, confirm it comes across intact; new templates often drop it silently.
• Canonical tags — make sure each page's canonical points to itself on the new URL, not back to an old address or a staging domain.

For a local Virginia business, pay special attention to your name, address, and phone number and your service-area language. Consistency there feeds your local SEO and your map presence, and a redesign is a common place for an old phone number or a dropped city name to sneak in. Also confirm the new site is genuinely faster and mobile-friendly, since page experience remains a ranking factor as of 2026. A migration is a fine moment to improve speed and structure — it is a terrible moment to blow up the content that's already working for you.

Step 5: Launch, tell Google, and verify everything resolves

Launch day is a verification day, not a walk-away day. The moment the new site is live, work through a tight sequence so Google learns about the move quickly and cleanly, and so any leak shows up in minutes instead of weeks.

• Confirm the site is crawlable. Check that a stray "noindex" tag or a blocking robots.txt from the staging site didn't ship to production. This is a shockingly common migration killer — the whole site goes live perfectly and tells Google to ignore it.
• Submit a fresh XML sitemap in Google Search Console listing your new URLs. Leaving the old sitemap available briefly can actually help Google discover the redirects faster, but your primary sitemap should be the new one.
• Use the Change of Address tool in Search Console — but only if you moved to a new domain. It asks Google to transfer signals from the old property to the new one and speeds up recovery alongside your redirects. For a same-domain redesign, you skip this tool entirely and rely on your 301s and sitemap.
• Verify both properties in Search Console. Keep the old domain's property verified so you can watch its coverage drain and its redirects register, not just the new one.
• Spot-check your redirects live by loading a sample of old URLs and confirming each lands on the right new page in a single hop.
• Test forms, tracking, and phone links so leads actually reach you from day one — a migration that keeps every ranking but breaks the contact form still costs you business.

Then leave the old domain and its redirects in place for the long haul — at least a year, and ideally indefinitely — because links, citations, and bookmarks pointing at old URLs keep passing value only as long as the redirects answer them. Turning them off early throws away the authority you just worked to preserve. If any of these steps sit outside your comfort zone, they're a reasonable thing to hand off as part of the migration itself.

Step 6: Monitor for months, and know what's normal

After a well-executed migration, expect some movement — Google has to recrawl the old URLs, process the redirects, and re-index the new pages, and that isn't instant. A modest, temporary dip in the first few weeks is common and not a sign of failure. What matters is the trend line over the following weeks and months, measured against the baseline you saved in Step 1 rather than a vague memory of "how it used to be."

Watch these in Google Search Console and your analytics:

• Index coverage / Pages report — are new URLs getting indexed, and are the old ones showing as "page with redirect" rather than errors? A pile of old URLs still marked "indexed" weeks later can signal Google hasn't processed the redirects yet.
• 404 and "not found" errors — every one is a page you missed in mapping or a redirect that broke. Fix each by adding the correct 301 as it surfaces; this is the single most useful report in the months after a move.
• Rankings and organic traffic against your baseline — compare to the benchmark you saved, keyword by keyword, so you can tell a specific broken page from general noise.
• Internal broken links and redirect chains — re-crawl the live site to catch any links still pointing at old URLs.

On timing, be honest with yourself rather than anxious. Google typically acknowledges the move within a week or two, rankings tend to fluctuate for several weeks after that, and a clean migration generally stabilizes over the following couple of months — larger and slower-crawled sites take longer. These are patterns, not promises; nobody can guarantee an exact recovery date, and anyone who does is selling certainty that doesn't exist. Plan to actively monitor for a few months before you call the migration finished.

If traffic is still down well past that window and 404s keep appearing, something in the redirect map is broken. That's a fixable problem, not a permanent loss — a structured SEO review will find the gap and close it. Handled with care, a migration costs you a few weeks of noise and nothing of lasting value.