Migrating a live site without losing your rankings

A website migration SEO plan keeps rankings intact by preserving every URL that has earned links, creating one clean 301 redirect per changed address, keeping canonicals and sitemaps consistent, and watching Google Search Console for sudden drops. Skip any of those four steps and you trade years of accumulated authority for a faster launch.

Key Takeaways

• Preserve every existing URL; one 301 per changed address is the single highest-leverage task.
• Match the new sitemap and canonicals to the redirect map before launch, not after.
• Keep the old site serving redirects for weeks; Google needs to see the move, not a hard 404.
• Stage the new site behind noindex or authentication, then remove the block at launch.
• Use Search Console's URL Inspection and Change of Address tools to tell Google what moved.
• Watch indexed-page counts and crawl errors for the first two to four weeks after switchover.
• Roll back to the old DNS record if the new site cannot serve redirects within minutes.

What actually counts as a site migration?

A site migration means changing any of the signals Google uses to locate and rank pages: the domain, the URL path, the platform, the protocol from HTTP to HTTPS, or the page structure. The common thread is that the old address stops resolving, so the search engine must re-discover every page. A redesign that keeps URLs intact is not a migration and carries almost no ranking risk.

That distinction matters because it changes the work. Moving a WordPress site to custom code while keeping the same slugs is low risk if redirects are clean. Rebooting on a new domain with new slugs is a different project entirely, and most of the risk sits in the redirect map, not the new build. Treat the map as the thing you are actually shipping.

Why do rankings drop during a migration?

Rankings drop when the signals that made a page rank — its URL, incoming links, content and structured data — no longer line up. A 404 or a redirect chain dilutes link equity, and Google treats a soft 404 or a mismatched canonical as a weaker page. The drop usually appears within a week, but the cause was decided before launch by the redirect map.

A 301 redirect passes most link equity, but a chain of two or three redirects wastes crawl budget and confuses the crawler. Pointing every old URL at the homepage is worse: Google reads that as a soft 404 and drops the page-level signals. The mechanism is boring but unforgiving — if the old URL cannot find its exact new equivalent in one hop, you lose ground.

When do you actually need a migration?

You need a migration when the domain, platform or URL structure has to change for a business reason: a rebrand, a platform being retired, a move from page-builder bloat to maintainable code. You do not need one to fix a slow theme or refresh a design. If the URLs can stay the same, keep them; a rewrite with new slugs is a self-inflicted ranking wound.

Before committing, ask whether the current site can be fixed in place. Sometimes the honest answer is that it cannot — the code is fragile, the page builder is fighting you, and the costs of patching exceed the cost of a careful move. That is the moment a migration is justified. Our take on whether to rebuild or keep patching walks through that call.

The pre-migration crawl and redirect map

Before changing anything, crawl the live site and export every URL that returns a 200, including images, PDFs and paginated pages. Build a one-to-one map from every old URL to its new equivalent; any old URL without a destination becomes a 404, and every 404 discards whatever authority that URL had. Treat the map as the migration's source of truth.

1. Crawl the live site with your preferred crawler; export status codes, titles and canonicals.
2. Pull the same list from Search Console's Performance and Coverage reports, and from your XML sitemap.
3. Merge the three lists and deduplicate; mark anything that is not moving.
4. Map each old URL to exactly one new URL; avoid many-to-one redirects unless the pages are true duplicates.
5. Save the map as a reviewable file — a spreadsheet works fine at this scale.
6. Have a second person check the fifty highest-traffic URLs line by line.

The map is where we see most projects go wrong. A page that ranks for a money keyword but is missing from the map will silently 404 after launch, and nobody notices until the traffic report shows it. Spending an extra afternoon here is the cheapest insurance in the whole project.

How to stage the new site without leaking it to Google

A new site that is crawlable before launch creates duplicate content, and Google may index the wrong version while the old site is still live. Block it with a noindex meta tag or basic authentication during development, then remove the block at the moment the DNS switches. Use a staging subdomain that robots.txt disallows, not a path on the live domain.

Staging is not just a hiding place; it is where you prove the redirect map works before traffic arrives. Test the new URLs, check the canonicals point at the right addresses, and confirm the XML sitemap contains only final URLs. A staging environment that mirrors production is the difference between a rehearsed launch and a live experiment — see how a proper staging environment works.

The launch sequence: DNS, SSL and verification

Launch by lowering the DNS TTL on the old domain at least a day ahead, switching the record, and installing the SSL certificate on the new host before traffic arrives. Keep the old server serving 301 redirects for at least a few weeks, then submit the new sitemap in Search Console and use the Change of Address tool when the domain changes.

1. Lower the DNS TTL to 300 seconds at least 24 hours before switchover. This changes how quickly resolvers re-check records; back up the existing zone file first.
2. Pre-provision the SSL certificate on the new host and test it with the commands below.
3. Switch the DNS A/AAAA or CNAME record, then keep the old server running with its redirect rules intact.
4. Remove the noindex tag or authentication from the new site immediately after the switch.
5. Submit the new XML sitemap in Search Console and request validation of key URLs.

# Check the old URL redirects once, to the right place
curl -sI https://olddomain.com/old-page | grep -i '^HTTP\|^location'

# Check the new host before DNS switches, using the Host header
curl -sI -H "Host: newdomain.com" https://new-server-ip/ | head -n 1

DNS changes are state-changing and propagate unevenly. If the new site cannot serve redirects within minutes of the switch, point the record back at the old server rather than debugging live. The Google Search Console documentation is the reference for the Change of Address flow and coverage reports.

How to verify the migration worked

Verification is a watching job, not a one-time check. In Search Console, watch the Indexed pages and Crawl errors reports daily for the first two weeks; a steep fall in indexed pages means redirects are failing or the sitemap is wrong. Also spot-check the ten highest-traffic URLs with a manual fetch to confirm each resolves and redirects once, with no chain.

• Curl the top twenty old URLs and expect exactly one 301 followed by a 200.
• Crawl the new sitemap and expect every listed URL to return 200.
• Confirm every canonical tag now points at a new-domain URL, not the old one.
• Check the Coverage report for a spike in 404s or soft 404s after launch.

A useful habit is to export the indexed-page count the morning before launch and compare it daily. Small fluctuations are normal; a slide that continues past the first week is a signal the redirect map missed something. A handover checklist helps you capture these checks so the next person is not reverse-engineering your launch notes.

Failure modes and what to check first

The common failure is not the server; it is the redirect map. Check the old URLs first: if a previously ranking URL now returns a 404 or a 200 on the wrong template, that single page is losing its position. Second, check for redirect chains and loops with a crawl. Third, look for a canonical tag still pointing at the old domain after launch.

1. Curl the top twenty old URLs; expect one 301 then a 200, not a 404 or a homepage bounce.
2. Crawl the new sitemap; a 200 on every URL rules out most serving problems.
3. Compare canonicals against the new URLs; a stale canonical undoes the redirect work.
4. Review Search Console coverage for unexpected 404 or soft-404 spikes in the first week.

When something does break, resist the urge to add more redirects on top of broken ones. Fix the underlying map, then re-crawl. A chain of three redirects is a bug, not a workaround.

Cost and operational overhead of a migration

The financial cost of a migration is driven by engineer time, not infrastructure: a careful crawl, redirect map and verification pass takes days on a mid-sized site, and shortcuts multiply that. Ongoing overhead is low once the redirects are in place, but the old DNS record and redirect rules must be kept for months. Treat the redirect map as a permanent asset, not a launch checklist.

The size of the URL set, the platform change and whether content is being rewritten all move the effort. A domain-only move with the same CMS is mostly redirect work; a rebuild that also restructures content is two projects wearing one coat. If the new site needs to handle more traffic afterwards, that is a separate hosting decision — the trade-offs are covered in what a scalable website actually means.

Security considerations during a migration

A migration is a credential handover moment. SSL certificates must be issued for the new domain and any www or apex variant before traffic switches, and the old hosting should stay locked down with its redirect rules read-only. If a third party manages the DNS, confirm ownership and access before you lower TTLs; losing control of DNS mid-migration is the worst failure mode.

Keep all accounts — registrar, DNS, hosting, Search Console — in the client's own name, not the agency's. That is not just good practice; it is the thing that lets you roll back at 2 a.m. without waiting on a vendor. Our team can help you audit access and ownership before a move, and keep it that way after.

Common mistakes that erase rankings

The most damaging mistake is launching the new site with new URLs and no redirects, then submitting a fresh sitemap and hoping. The second is leaving a noindex tag on the new site after launch. The third is pointing every old URL at the homepage, which reads as a soft 404 and throws away page-level authority. Each is cheap to avoid and expensive to undo.

• Forgetting trailing-slash variants, uppercase paths, or http:// versions of old URLs.
• Changing URLs during the migration for cosmetic reasons that add no business value.
• Taking the old server down before Google has re-crawled the redirects.
• Not tracking Search Console from day one, so the first sign of trouble is a revenue report.

A realistic migration scenario

Picture a WordPress site with four hundred blog posts and thirty landing pages, moving off a page builder to custom code on the same domain. The slugs can mostly stay the same, so the crawl and map focus on the forty URLs the page builder generated with ugly query strings. Those get exact 301s to clean equivalents; everything else stays untouched.

The site is staged behind basic auth for three weeks while the team checks templates and canonicals. On launch day, DNS TTL was lowered the day before, SSL was already tested, and the switch takes an hour. The old server keeps serving redirects for six weeks. Indexed pages dip for four days, then recover as Google re-crawls — the rankings hold because the URLs that mattered never went dark.

Alternatives compared

Not every move needs the same playbook. The table maps the main approaches to the risk they carry and when each one fits.

Approach	Ranking risk	When it fits	Key trade-off
In-place rebuild, URLs unchanged	Low	Same domain, same slugs	Limited structural change
Platform migration with 1:1 redirects	Moderate	Must preserve URLs	Redirect map effort up front
Domain change	High	Rebrand	Needs Change of Address plus updated backlinks
Full redesign with new URL structure	High	Rarely justified	Most authority at risk in one move
Incremental fix, no migration	None	Site works but is slow	Slower improvement over time

In short: a ranking-safe migration is a URL preservation project with a launch attached. Crawl everything, map one old address to one new address, stage behind noindex, switch DNS with the old server still serving redirects, then watch Search Console until the curve flattens. The ranking you save is usually the page you almost forgot to map.

People also search for

• Should I rebuild my website or migrate it?
• What should I check when taking over a website after a migration?
• How do I test a new site before it goes live?
• Does a migration make a website more scalable?
• Which hosting should a migrated site use?
• Website migration SEO basics

If a migration is on your roadmap, our team can help you audit the current site, build the redirect map and run the launch without betting your rankings. See how we approach SEO and migration work, or tell us what is moving.