How to Migrate a Website Without Losing Your SEO

Key takeaways

• Most migration traffic losses come from missing or sloppy 301 redirects — a complete one-to-one URL map is the single highest-leverage task in the whole project.
• Crawl and benchmark the old site before you touch anything. If you don't know what ranked and what earned links before launch, you can't prove what broke after.
• Never redirect everything to the homepage. Google treats irrelevant redirects as soft 404s and drops the ranking signals you were trying to save.
• Keep redirects live for at least a year — Google's John Mueller has said Googlebot needs to see them multiple times to fully transfer signals.
• Expect turbulence even when you do everything right. Monitor Search Console weekly for 8–12 weeks and fix 404s and redirect chains within days, not months.

Why do website migrations put your SEO at risk in the first place?

A migration changes the addresses where Google's index expects to find your content. Google stores its index page by page, so when a URL changes, every signal attached to the old address — backlinks, relevance, crawl history — has to be re-earned at the new one. If nothing forwards those signals, they're gone.

The stakes are concrete. According to BrightEdge's research, organic search drives roughly 53% of all trackable website traffic. For most small businesses, that organic half of the pie took years to build. And it's scarcer than people assume: an Ahrefs study of around 14 billion pages found that 96.55% of pages get zero traffic from Google. If your pages are in the lucky minority that actually rank, a botched migration can push them into the invisible majority overnight.

Here's the uncomfortable part: some loss is normal even in a clean migration. Rankings wobble for a few weeks while Google recrawls, follows your redirects, and reconsolidates signals. The goal of this website migration SEO checklist isn't zero fluctuation — it's making sure the fluctuation is temporary and the trend line returns to baseline within a quarter, not a year.

What kind of migration are you actually doing — and how risky is it?

Risk scales with how much you change at once. A hosting move with identical URLs is low risk; a rebrand with a new domain, new CMS, and a rewritten site architecture is the highest-risk scenario there is. Know which one you're signing up for before you plan the work.

The classic SMB mistake is stacking changes: new domain, new platform, new design, and rewritten copy all in one launch. If traffic drops, you have four suspects and no way to isolate the culprit. If you can stage the work — platform first, design later — do it. If you can't, your pre-launch benchmarking becomes even more important, because it's your only diagnostic baseline.

What should you do before the migration starts?

Before launch, you need three things: a full inventory of the old site's URLs, a performance benchmark, and a staging environment that's blocked from search engines. Everything else in the pre-migration phase serves one of those three.

Start with a complete crawl of the current site using Screaming Frog, Sitebulb, or a similar crawler. Export every indexable URL along with its title tag, meta description, H1, canonical, status code, and word count. Then pull three more lists and merge them: every URL with organic traffic from Google Analytics, every URL with impressions from Search Console, and every URL with backlinks from Ahrefs, Semrush, or Search Console's link report. Pages with links or rankings get priority treatment in your redirect map — a page earning links from other sites is worth saving even if it looks unimportant.

Next, benchmark. Record current rankings for your 20–30 most valuable keywords, organic sessions by landing page for the last 12 months, and your indexed page count. Screenshot your key SERPs. This is the number you'll compare against at week 2, 6, and 12 after launch.

Then build and QA the new site on a staging server protected by authentication or a noindex tag — but keep a written note to remove that block at launch. Forgetting to lift the staging noindex is one of the most common and most humiliating migration disasters, and it happens to experienced teams.

Finally, make sure the new site's foundations are solid before it replaces the old one: clean title tags, working canonicals, an XML sitemap, fast server response, and mobile-friendly templates. If your redesign is part of the migration, run through a proper business website redesign checklist so the new site launches better than the old one, not just different. And if terms like canonicals and crawl budget are new territory for your team, our primer on what technical SEO actually covers is worth reading before kickoff — migrations are technical SEO at its most concentrated.

How do you build a URL redirect map that actually works?

A redirect map is a spreadsheet with two columns: every old URL, and the single most relevant new URL it points to with a 301 (permanent) redirect. One-to-one mapping, closest-match destinations, no chains, no mass redirects to the homepage. That discipline is what preserves your rankings.

A few rules that separate working maps from broken ones:

• Use 301s, not 302s. A 302 tells Google the move is temporary, so it keeps the old URL indexed and your new pages wait in limbo. Permanent move means 301 (or 308).
• Match by intent, not by name. If the old /services/plumbing-repair becomes /plumbing-services, map it there — not to a generic services page. Redirects to irrelevant destinations get treated as soft 404s, and the signals are dropped instead of transferred.
• One hop maximum. If old URL A points to B, and B points to C, update A to point straight to C. Chains slow crawlers and dilute the transfer.
• Don't forget the long tail. Blog posts, paginated archives, PDFs, and parameter URLs all need a decision: redirect, or intentionally let them 410 (gone) if they had no traffic and no links.
• Update internal links to the new URLs directly. Redirects are a safety net for external links and bookmarks, not a substitute for clean internal linking.

And keep the redirects live. Google's John Mueller has recommended keeping redirects in place for at least a year, because Googlebot needs to encounter them multiple times before the signal transfer sticks — and Mueller has also noted that URL changes can take several months to fully process. Our practical advice: keep them indefinitely. Redirect rules are cheap; rebuilding lost rankings is not.

Test the map before launch by crawling the staging site with the redirects applied (or by running the old URL list against a redirect-testing tool). Every old URL should return a 301 to a live 200 page — not a 404, not a chain, not a loop.

What does launch day and the first 90 days look like?

On launch day you flip the DNS, remove the staging noindex and robots blocks, upload the new XML sitemap to Search Console, and spot-check your highest-value redirects. The 90 days after that are a monitoring job: watch indexation, rankings, and 404 reports, and fix problems within days.

Here's the post-launch checklist in order:

1. Day 0: Confirm the noindex is gone, robots.txt allows crawling, the sitemap is submitted, analytics are firing on the new templates, and your top 25 old URLs redirect correctly.
2. Day 0 (domain changes only): Use the Change of Address tool in Google Search Console to formally tell Google the site moved.
3. Week 1: Crawl the new site. Fix broken internal links, missing titles, and any old URLs returning 404 that should have been redirected.
4. Weeks 2–4: Watch Search Console's indexing report. Old URLs should drop out and new ones should replace them. Check rankings for your benchmark keywords twice a week.
5. Weeks 4–12: Compare organic sessions by landing page against your pre-migration baseline. A page down 15–20% is turbulence; a page down 60% with a clean redirect is a real problem — check the redirect target's relevance and content parity.
6. Ongoing: Reach out to your most valuable backlink sources and ask them to update links to the new URLs. Redirects pass the signals, but a direct link is cleaner.

Monitoring is also where most small teams fall down — nobody has time to manually check rankings across Google, let alone how the new site shows up in AI answers. This is exactly the kind of ongoing visibility tracking we built AutoRankFlow to automate, so ranking or AI-visibility drops get flagged while they're still fixable instead of discovered in a quarterly report.

What are the most common migration disasters — and how do you avoid them?

The disasters that actually kill traffic are boring and preventable: the staging noindex left on, robots.txt blocking the whole site, redirects pointed at the homepage, and content quietly dropped during the redesign. Every one of them is caught by a checklist and a crawler.

The hall of fame, ranked by how often we see them:

• The noindex that launched. The site goes live still telling Google not to index it. Traffic falls off a cliff within two weeks. Catch: check the live homepage source on day zero.
• The homepage catch-all. Three hundred old URLs redirected to the homepage. Google reads them as soft 404s; rankings evaporate. Catch: spot-check that redirect targets are topically equivalent.
• The content haircut. The redesign "cleans up" the blog — deleting posts that individually looked weak but collectively drove thousands of visits and held valuable backlinks. Catch: the merged crawl-plus-analytics list from your pre-migration phase. Nothing with traffic or links gets deleted without a redirect to an equivalent page.
• The metadata wipe. The new CMS launches with default or missing title tags across the site. Catch: compare the old crawl's titles against the new crawl before launch.
• The slow new server. The fancy new stack responds in 2.5 seconds instead of 800 milliseconds, and conversions drop even where rankings hold. Catch: load-test the new environment before DNS flips.
• The analytics blackout. The new templates ship without the analytics tag, so nobody can even measure what happened. Catch: confirm real-time analytics on launch day.

Notice the pattern: none of these are exotic algorithm problems. They're process failures. A migration done with a crawler, a spreadsheet, and a 90-day monitoring habit recovers in weeks. A migration done on vibes can take a year to claw back — and some sites never fully do.

Frequently asked questions

How long does SEO take to recover after a website migration?

For a well-executed migration, expect 4–12 weeks of turbulence before rankings stabilize near baseline. Google's John Mueller has noted that URL changes can take several months to fully process, especially on larger sites. If you're not back to baseline by week 12, something specific is broken — audit redirects and content parity page by page.

Should I change my URL structure during a migration?

Only if you have a strong reason. Every URL you change adds redirect risk and reprocessing time. If the current structure works, mirror it on the new platform and save restructuring for a separate project after the migration has settled.

Is a 301 or 302 redirect better for a migration?

Use a 301. It signals a permanent move, tells Google to index the new URL, and transfers ranking signals cleanly. A 302 says "temporary," so Google keeps the old URL indexed — exactly what you don't want during a permanent migration.

Can I redirect all my old pages to the homepage?

No, and it's one of the most damaging shortcuts. Google treats redirects to irrelevant pages as soft 404s, so the old pages' ranking signals are discarded. Map each URL to its closest equivalent, or let genuinely dead pages return a 410.

Do I need to tell Google about my migration?

If the domain is changing, yes — verify both properties in Search Console and use the Change of Address tool. For same-domain migrations, submitting the new XML sitemap and letting the 301s do their job is enough.

What happens if I remove the redirects after a few months?

Old backlinks and bookmarks suddenly hit 404s, and any residual signals still attached to the old URLs are lost. Keep redirects for at least a year per Google's guidance — and honestly, keep them forever. The cost of leaving them in place is essentially zero.

How do I know if my migration went wrong?

Compare organic sessions by landing page against your pre-migration baseline at weeks 2, 6, and 12. A broad 10–20% dip that trends back up is normal. Specific pages down 50% or more, a collapse in indexed pages, or a spike of 404s in Search Console means you have a fixable technical problem.