How to Migrate a Website Without Losing SEO

A website migration is one of the few SEO events that can wipe out years of hard-won rankings in a single weekend, and it is also one of the most avoidable disasters in the field. Whether you are redesigning, moving to a new platform, changing your URL structure or switching domains, the danger is the same: if search engines cannot map your old pages to their new locations, the authority you built can evaporate and your traffic can fall sharply and stay there.

The good news is that migrations rarely go wrong because of bad luck. They go wrong because of skipped steps, most often missing or incorrect redirects and a rushed launch with no proper checks. This guide sets out a practical, ordered process for migrating a site while protecting its search performance, from planning and URL mapping through redirects, testing and post-launch monitoring, so the move is a step forward rather than a costly reset.

Plan the Migration Before You Touch Anything

Every safe migration starts with a plan built while the current site is still live. Begin by defining exactly what is changing, because a design refresh on the same URLs is a very different risk to a domain change or a full replatform. The more that changes at once, the harder it is to isolate a problem later, so where possible stage the work: move platforms first, then redesign, rather than changing everything in a single launch.

Next, capture a complete picture of the site as it stands today. Crawl the whole site to list every indexable URL, export your top landing pages and their traffic from analytics, record your ranking keywords and your current indexed pages from Search Console, and note every page that earns backlinks. This baseline is what you will measure against after launch, and it tells you which pages carry the most value and therefore deserve the most care.

Finally, agree the success criteria and the rollback plan before you begin. Decide what a normal post-launch dip looks like, when you would act, and how you would revert if something serious breaks. Migrations done under time pressure with no fallback are where the worst losses happen, so building in checkpoints and the ability to step back is not caution for its own sake, it is what keeps a bad hour from becoming a bad quarter.

Build a Complete URL Map and Redirect Every Old Address

The URL map is the heart of a migration. For every URL on the old site, decide its fate: it maps one-to-one to a new URL, it merges into another page, or it is genuinely retired. The aim is that no valuable old address is left pointing at a dead end. Pay particular attention to your highest-traffic pages, your best-converting pages and the pages with the strongest backlinks, because these are the ones where a mistake costs the most.

Once the map is agreed, implement a 301 permanent redirect from each old URL to its chosen new destination. A 301 tells search engines the move is permanent and passes the great majority of ranking signals to the new page. Redirect to the closest relevant page, not lazily to the homepage, because bulk redirects to the homepage are often treated as soft 404s and lose the value you were trying to keep. Avoid redirect chains, where one URL redirects to another that redirects again, since each hop adds delay and risk.

Do not forget the supporting infrastructure. Update your XML sitemaps to list only the new canonical URLs, refresh internal links so they point directly at the new addresses rather than through redirects, update canonical tags, and check that hreflang, structured data and robots directives all reference the new URLs. If you are changing domains, keep control of the old domain so the redirects can stay in place for the long term, because they need to persist well beyond launch day.

Map every old URL to a new URL, a merge target, or a deliberate retirement
Use 301 redirects to the closest relevant page, never a blanket redirect to the homepage
Eliminate redirect chains so each old URL reaches its destination in one hop
Update sitemaps, internal links, canonicals, hreflang and structured data to the new URLs
For a domain move, retain the old domain so redirects can remain in place long term

Test on Staging, Then Launch and Verify

Before launch, the new site should live on a staging environment that is blocked from search engines, so it cannot be indexed and create duplicates. Crawl the staging site to confirm the pages, titles, headings, canonical tags and structured data are correct, and test a sample of your redirect map to make sure old URLs resolve to the right new pages with a single 301. The most damaging launch-day mistake is shipping a staging noindex or a disallow-all robots file to production by accident, so that check is non-negotiable.

At launch, verify the essentials immediately rather than assuming they carried over. Confirm the live robots.txt allows crawling and does not block important resources, confirm pages are not accidentally set to noindex, submit the new sitemaps in Search Console, and if you changed domains, use the Change of Address tool to tell Google about the move. Spot-check redirects on live URLs, including a handful of your most valuable pages, to confirm they land correctly.

Then watch the site closely. Use Search Console to monitor indexing of the new URLs and the crawling of the old ones, check the Pages report for new errors, and keep an eye on server logs and analytics for spikes in 404s or sudden drops on key pages. A short period of fluctuation while Google reprocesses the site is expected. What you are looking for is anything that does not recover, because that points to a redirect gap, a blocked resource or an indexing setting that still needs fixing.

Monitor Recovery and Fix Problems Early

Recovery from a well-executed migration is usually a matter of weeks rather than days, as search engines recrawl the old URLs, follow the redirects and transfer signals to the new pages. During this window, compare live performance against the baseline you captured before launch: are your important pages indexed under their new URLs, is organic traffic tracking back towards previous levels, and are your priority keywords holding their positions. Small movements are normal; a consistent decline several weeks on is a signal to investigate.

When something is wrong, the cause is usually mechanical and fixable. The most common issues are missing redirects for pages you overlooked, redirects pointing to the wrong destination, chains that dilute signals, pages left on noindex, blocked CSS or JavaScript that stops Google rendering the page, or orphaned pages with no internal links. Work through the list methodically, using Search Console and a fresh crawl to find the specific URLs affected, and fix the highest-value pages first.

The overarching principle is that a migration is a project with a tail, not an event that ends at launch. Keep the redirects in place indefinitely, keep monitoring until performance has clearly stabilised, and resist making further large changes while the site is still settling. If you would like an experienced pair of hands to plan the URL map, pressure-test the redirects and monitor the recovery, SEODXB runs migrations end to end and offers a free pre-migration audit, with no lock-in contracts.

Compare live indexing, traffic and rankings against your pre-launch baseline
Check first for missing redirects, wrong targets, chains and stray noindex tags
Confirm Google can render pages by ensuring CSS and JavaScript are not blocked
Keep redirects in place long term and avoid further big changes while settling

A website migration only loses rankings when the mapping between old and new URLs breaks, so the whole job is about protecting that mapping. Plan while the current site is live, capture a baseline of your URLs, traffic, rankings and backlinks, and build a complete URL map that gives every valuable old address a new home. Redirect each old URL with a single 301 to its closest relevant page, never a blanket redirect to the homepage, and eliminate chains. Test on a staging site that search engines cannot index, then at launch verify robots.txt, indexability and redirects, submit new sitemaps, and use the Change of Address tool for domain moves. Afterwards, monitor recovery against your baseline and fix the usual culprits early: missing redirects, wrong targets, noindex tags and blocked resources. Keep redirects in place long term. Done in this order, a migration is a controlled step forward rather than a reset. SEODXB plans and monitors migrations end to end and offers a free pre-migration audit, with no lock-in contracts.

Related guides and services

Frequently asked questions

Will I lose rankings when I migrate my website?

Not if the migration is done properly. Rankings are lost when search engines cannot map your old pages to their new locations, which almost always comes down to missing or incorrect redirects. If you build a complete URL map, apply a single 301 redirect from each old URL to its closest relevant new page, and keep indexing settings correct, the great majority of your ranking signals transfer. Expect a short period of fluctuation while Google reprocesses the site, then recovery.

What is the most important step in a website migration?

The URL map and the redirects that follow from it. Every old URL needs a decision, whether it maps one-to-one to a new address, merges into another page, or is deliberately retired, and every valuable old address needs a 301 redirect to the right destination. Most migration disasters trace back to this single point: pages that were missed, redirected to the wrong place, or sent in bulk to the homepage. Get the mapping right and most of the risk disappears.

Should I use 301 or 302 redirects for a migration?

Use 301 redirects for a permanent move, which a migration is. A 301 tells search engines the change is permanent and passes the great majority of ranking signals to the new URL. A 302 signals a temporary move and is the wrong choice for a migration, because it can leave the old URL indexed and slow the transfer of authority. Reserve 302s for genuinely temporary situations, not for a permanent site or domain change.

How long does it take to recover traffic after a migration?

For a well-executed migration, recovery usually takes a few weeks as search engines recrawl the old URLs, follow the redirects and transfer signals to the new pages. Larger sites can take longer simply because there are more URLs to reprocess. Some fluctuation during this window is normal. If traffic is still meaningfully down several weeks after launch and not trending back, that points to an unresolved issue such as a missing redirect or an indexing setting, which should be investigated.

Do I need to tell Google about my website migration?

If you are changing domains, yes. Use the Change of Address tool in Google Search Console to tell Google the site has moved to a new domain, which helps it process the move faster. For all migrations, submit updated XML sitemaps listing only the new canonical URLs so Google can discover and crawl them. You do not need to notify Google for a redesign on the same domain and URLs, though updated sitemaps still help.

Can I redesign and change my URLs at the same time?

You can, but it increases risk because two big changes at once are harder to isolate if something goes wrong. Where the timeline allows, it is safer to stage the work: change one major thing, confirm it is stable, then change the next. If you must do both together, be especially thorough with the URL map, the redirects and the pre-launch testing, and keep your baseline data so you can quickly see which change caused any problem.