How to migrate a website without losing your rankings
Treat it as the rare project where the goal is for nothing to change from your customer’s or Google’s point of view, even though everything underneath has changed. The one deliverable that decides the outcome is the redirect map: every old URL with any value — traffic, an indexed status, or a backlink — gets a clean 301 to its closest equivalent, never a 302 and never a blanket redirect to the homepage, which Google reads as a soft 404 and drops entirely. Build that map during the architecture phase, and migrate like-for-like: copy your top pages’ titles, descriptions, H1s and body content verbatim, and port the same schema to the same URLs, because “improving” a page that already ranks is the most expensive mistake in the playbook. Baseline your rankings and traffic before you touch anything, test the whole thing on staging to catch a leftover noindex or a canonical pointing at the old site, then submit your new sitemap at launch and monitor for thirty days. Expect a normal 10-20% dip for a few weeks. And if the migration is painful, notice why — the difficulty of leaving a platform is the lock-in tax you paid for not owning your site.
Why is migration so risky for SEO?
A website migration is the rare project where the goal is for nothing to change from your customers’ perspective, and nothing to change from Google’s perspective, even though almost everything underneath has changed (Kosmoweb, 2026). You want Google to understand that you’ve moved while concluding that nothing important is different — you’re the same trustworthy site with the same content people wanted (Influize, 2026). That’s a narrow target, and a botched replatform can wipe out years of accumulated SEO in a matter of weeks (Flyn, 2026).
The discipline that hits the target is unglamorous — audit thoroughly, map every URL, preserve on-page elements, validate schema, monitor relentlessly — and it starts before anything moves (Kosmoweb, 2026). The reason so many migrations fail is that teams treat the move as a design project and discover the SEO consequences after launch, when they’re expensive to reverse.
The redirect map is the one thing you must get right
If you do only one thing well during a migration, get the redirects right. Every URL on the old site that has any value — organic traffic, an indexed status, or an internal or external link pointing at it — needs a 301 redirect to its closest equivalent on the new site, built as a three-column spreadsheet of old URL, new URL and status during the architecture phase rather than at the end (Kosmoweb, 2026). Independent guidance treats one-to-one redirect mapping, backed by a full URL inventory, as mandatory, because it preserves link equity and gives you a baseline for spotting losses (Baslon Digital, 2026).
The mapping has to be deliberate, not mechanical. The best redirect maps are boring: a service page redirects to the equivalent service page, a product to the equivalent product or its category, a blog post to the equivalent post (Baslon Digital, 2026). And a subtlety many guides skip: capture the old site’s existing redirects first, because legacy redirect chains and forgotten old URL versions create post-launch problems that are painful to diagnose (Baslon Digital, 2026).
301 or 302 — and never redirect everything to the homepage
Two redirect mistakes account for a large share of lost rankings. The first is the status code: use a 301, a permanent redirect that passes the vast majority of link equity, and avoid the 302, which is temporary and tells Google to keep the old URL indexed — many CMS interfaces default to 302, so a stray one on a high-value page can cost you months (Flyn, 2026). Google has confirmed that properly implemented 301s pass most link equity, which is exactly why they’re the tool for the job (EarlySEO, 2026).
The second is redirecting everything to the homepage, one of the most damaging things you can do. Google treats a redirect to an irrelevant page as a soft 404 and drops the ranking entirely, as if there were no redirect at all — relevance is what allows the equity to transfer, so each old URL must point to its closest topical match (Flyn, 2026). If a page has no close equivalent, decide deliberately whether to send it to a parent category or retire it, rather than shovelling everything to the homepage.
Migrate like-for-like: copy, don’t “improve”
The most counterintuitive rule of migration is restraint. For every URL in your top pages, copy the existing title tag, meta description, H1 and main body content into the new site verbatim, unless you have a specific reason to change them — because “improving” the title of a page that ranks second for a high-value keyword is one of the most expensive optimisation mistakes there is (Kosmoweb, 2026). If a page is already performing, the goal of the migration is to preserve that performance, not to reinvent it.
Schema is the second on-page liability to watch. If the old site carried Article, FAQPage, BreadcrumbList, Organization or LocalBusiness markup, the new site must implement the same types on the same URLs, validated with Google’s Rich Results Test before launch (Kosmoweb, 2026). This is why a migration and a redesign should be separate projects: doing both at once means you can’t tell whether a traffic change came from the move or the redesign. Our guide on website redesign cost covers the redesign side; the safe sequence is migrate like-for-like, confirm rankings hold, then optimise as measured steps.
Baseline everything before you touch anything
Migrating without baseline data is guesswork with no reference points, so before changing anything, record your current keyword rankings, organic traffic, technical performance and conversion rates (Influize, 2026). Crawl the entire site with an SEO crawler and export every indexable URL — this dataset is both the foundation of your redirect map and the benchmark you’ll measure against afterward (EarlySEO, 2026).
Pair that with a content audit, evaluating every page to decide what to preserve, update, consolidate or remove, so you don’t carry outdated or low-quality pages into the new site and dilute its authority (EarlySEO, 2026). Give special attention to your high-performing and heavily-backlinked pages, which you can identify in Google Search Console by clicks and engagement — those are the pages whose rankings you most need to protect (Influize, 2026).
The tiny mistakes that hide in staging
The most expensive migration mistakes often look trivial in staging: one noindex tag, one blocked folder, one canonical rule copied from the old environment — and then launch happens and the site politely tells search engines to go away (Baslon Digital, 2026). The usual suspects are robots.txt blocking important folders, noindex directives left on templates from testing, canonicals still pointing at old URLs, internal links referencing staging paths, and redirects that aren’t active when DNS switches over (Baslon Digital, 2026).
The defence is to run multiple staging crawls before launch, auditing the staging site thoroughly so the live site exposes exactly the right pages when you flip the switch (EarlySEO, 2026). Also watch the edge cases that bite every team: query strings, trailing slashes, case sensitivity, and locale paths, each of which can silently break a redirect (Kosmoweb, 2026).
Launch is the start, not the end
The biggest mistake after all that preparation is treating launch as the moment to relax — the first weeks are when you confirm whether redirects behave and Google indexes the right URLs (Baslon Digital, 2026). In the first 48 hours, submit the new XML sitemap to Google Search Console, use the URL Inspection tool to request indexing of your most important pages, verify redirects with a checker, and watch for DNS propagation issues, which can take the full 48-hour window (Wix SEO, 2026). Confirm every redirect resolves in a single hop, since chains dilute link equity and slow the site (Influize, 2026).
One thing that isn’t SEO but will ruin your week if you miss it: email. A platform move touches DNS, and if you don’t treat your MX, SPF, DKIM and DMARC records as critical infrastructure, you can lose orders and leads the moment the domain switches (DCHost, 2026). Test contact forms, checkout and every critical flow on day one.
The lock-in tax: why leaving a builder is hard
Here’s where the difficulty itself tells you something. Moving off Wix means manually rebuilding most pages, because Wix exports only blog content via an RSS feed — static pages, images, apps and SEO metadata don’t transfer automatically (WP Services, 2026). That friction isn’t an accident; it’s the shape of lock-in. The reason people leave in the first place is that the platform limits design to a proprietary editor, hides the underlying code, and pushes advanced features into third-party apps with recurring fees that become walls as you grow (WP Services, 2026).
Read that back and the lesson is plain: the harder your exit is, the more the platform was effectively renting you your own content. A closed builder charges its highest price on the way out, when you discover your pages were never portable data you owned but display inside a system you licensed. That is the exact risk our pillar on the best website builder, or the site you own weighs — convenience now against a costly, manual extraction later.
The payoff: once you own it, the next move is trivial
The flip side is the reward for owning your site. When your content lives as portable data and your redirects live in a configuration file you control, a future move is a straightforward transfer rather than a hand rebuild — you never pay the exit tax again. Moving away from a builder also means you finally control the whole stack: domain, DNS, hosting, SSL and often email (DCHost, 2026).
None of this makes a first migration easy, and honesty is part of the advice: if you’re running a redirect map manually for the first time, the cost of a mistake is usually higher than the cost of expert help, because the teams that get migrations right are the ones that have run the same playbook many times (Kosmoweb, 2026). Choosing that partner is its own decision, and our guide on how to choose a web design agency covers the migration-specific questions to ask. Do the move once, carefully, onto something you own — and make sure it’s the last forced migration you ever run.
Frequently asked
- Will I lose my Google rankings if I migrate my website?
- Not if it's done correctly. With a complete 301 redirect map, on-page elements preserved, and the same content quality, ranking loss should be minimal — a temporary 10-20% traffic dip for two to four weeks is normal as Google reprocesses the site, and rankings usually recover, and often improve, within four to eight weeks. Lasting losses are almost always caused by specific mistakes: missed redirects, content that was 'improved' during the move, or technical errors like a leftover noindex tag. A botched migration can take three to six months to recover and may never fully regain what was lost.
- What is a redirect map and why does it matter so much?
- A redirect map is a spreadsheet pairing every old URL with its closest equivalent new URL, and it's the single most important migration deliverable. Every old URL that has any value — organic traffic, an indexed status, or an internal or external link pointing at it — needs a permanent 301 redirect to the most relevant new page. It's built during the architecture phase, not bolted on at the end, and it's what preserves your accumulated link equity. Get it wrong and users, backlinks and search engines all start walking into 404 walls.
- Should I use a 301 or a 302 redirect?
- For a migration, almost always a 301. A 301 is a permanent redirect that passes the vast majority of link equity to the new URL; a 302 is temporary and tells Google to keep the old URL indexed because the move isn't permanent, which means your new pages may never rank. The trap is that many CMS interfaces default to 302, so a stray one on a high-value page is a common and costly bug. Audit the status codes on your top URLs after launch to confirm they're all 301.
- Can I redesign my site at the same time as migrating it?
- You can, but it multiplies your risk, and the safer discipline is to migrate like-for-like first and optimize afterward. During a migration you should copy your top pages' title tags, meta descriptions, H1s and body content into the new site verbatim, because 'improving' a page that already ranks well is one of the most expensive mistakes possible — if a page performs, the goal is to preserve it, not reinvent it. Do the platform move as a clean transfer, confirm rankings hold, then make design and content changes as separate, measurable steps.
- Why is it so hard to move off a website builder like Wix?
- Because closed platforms make your content hard to take with you. Moving off Wix means manually rebuilding most pages, since Wix exports only blog content via an RSS feed — static pages, images, apps and SEO metadata don't transfer automatically. That friction is the lock-in tax: the harder your exit is, the more the platform was effectively renting you your own content. It's also the strongest practical argument for building on a site you own from the start, where your content is portable data and the next move, if there ever is one, is straightforward.