Migrating Your Website Without Losing Your Search Rankings: A Practical Playbook

Every website migration promises the same thing: a faster site, a better design, a platform that finally makes sense for the team running it. And almost every migration also carries the same risk, which rarely gets discussed until it’s too late — a traffic drop that shows up two to six weeks after launch, right when everyone has already moved on to the next project.

The frustrating part is that this isn’t unpredictable. Ranking losses during migrations follow a small, well-known set of causes, and almost all of them are avoidable with the right sequence of work. This isn’t about being paranoid. It’s about treating the migration as an SEO project with a design attached, not a design project with SEO bolted on at the end.

Why migrations tank rankings when they do

Search engines don’t re-evaluate a site from scratch after a redesign — they try to carry forward the trust and relevance signals your existing URLs have already earned. A migration breaks that continuity in a few specific ways: URLs change and the old ones return 404s instead of redirecting, internal linking gets rebuilt and quietly drops links to pages that used to rank well, page templates lose structured data that was feeding rich results, or the new site launches faster in theory but slower in practice once real content and plugins are loaded onto it.

None of these are exotic problems. They’re the direct result of nobody owning the technical handoff between “the old site” and “the new site” as its own deliverable, separate from the visual redesign.

Start with a URL map, not a sitemap

Before a single new template gets built, every existing URL on the site needs a home in the new structure. Not a general plan — a literal spreadsheet with one row per URL: the old path, the new path it maps to, and a note on why (same page, merged into a broader page, or intentionally retired). This sounds tedious for a site with a few hundred URLs and genuinely painful for a site with a few thousand, which is exactly why it gets skipped. It’s also exactly why skipping it is the single most common cause of a bad migration.

Pull the full URL list from your XML sitemap, your analytics property, and a crawl of the live site — not just one of those sources, since each one catches URLs the others miss. Old category pages, tag archives, paginated pages, and PDF resources are the ones that get forgotten most often, and they’re often carrying more link equity than anyone remembers.

301s at the server level, not a redirect plugin doing its best

Once the URL map exists, every single row that isn’t a 1:1 slug match needs a permanent 301 redirect, and it needs to point to the actual replacement page — not the homepage. A blanket redirect-everything-to-the-homepage approach is a common shortcut that looks fine in a spot check and quietly tells search engines that none of your old pages had a real replacement, which is the opposite of what you want them to conclude.

Where the redirects live matters too. A redirect handled at the server or CDN level is faster and more reliable than one handled entirely through a WordPress plugin sitting behind a full page load, and it holds up better under crawl volume. If the new site is also changing platforms, confirm redirects fire before any client-side routing or JavaScript redirect logic runs — a redirect that only works after a page has already loaded and executed a script is a redirect a crawler may never see.

Crawl the old site in full before it disappears

Once the old site is gone, so is your best record of exactly what existed on it. Run a full crawl of the live site before launch and keep the export: every URL, its status code, its title tag, its meta description, and its outbound internal links. This becomes the source document for the URL map above, and it’s also the thing you’ll want on hand three weeks after launch if a specific page’s rankings vanish and nobody can remember what used to be there.

Content consolidation is fine — content deletion without a plan isn’t

Migrations are a natural moment to clean up an old site’s sprawl, and consolidating five thin, overlapping blog posts into one comprehensive page is often a genuine improvement. The mistake isn’t the consolidation itself — it’s doing it without redirecting each of those five old URLs to the new combined page. Deleted content that returns a plain 404 forfeits whatever ranking signal it had built up. Redirected content passes that signal forward to whatever now covers the same ground.

If a page is being retired with no real replacement anywhere on the new site, let it 404 or use a 410 deliberately — don’t force a redirect to a loosely related page just to avoid a 404. A forced, irrelevant redirect confuses search engines more than a clean 404 does.

What actually changes under the hood, not just what it looks like

A redesign usually touches structured data, canonical tags, and internal linking patterns whether or not anyone planned for that to happen, simply because the new templates are built from scratch. Before launch, check that the new templates still output the schema markup the old ones had — article schema, breadcrumbs, FAQ markup, whatever was earning rich results before. Check that canonical tags point to the correct new URLs and not, as sometimes happens with a staging-to-production copy, to the staging domain. And check that the new internal linking structure still links into the pages that were ranking well, since a redesign that reorganizes navigation can accidentally orphan a page that used to get most of its authority from internal links alone.

The staging-site mistake that quietly tanks a launch

This is the single most common self-inflicted wound in a migration, and it has nothing to do with strategy. Staging environments are almost always set to block search engines, either through a site-wide “Discourage search engines from indexing this site” setting or a blanket Disallow: / in robots.txt. When the staging site becomes the live site, that setting has to be turned off as part of the launch checklist — not remembered a week later when someone notices traffic looks off. Check both the WordPress reading settings and the actual robots.txt file directly in a browser right after launch; they don’t always get toggled by the same process.

The first 48 hours after launch

Submit the new XML sitemap in Search Console immediately, and keep the old domain or subdirectory property in Search Console rather than deleting it — you’ll want its historical data and its Coverage report for comparison. Spot-check a sample of redirects across different sections of the site, not just the homepage and a couple of obvious pages. Watch the Coverage and Page Indexing reports over the following two weeks for a spike in “Not Found” or “Page with redirect” errors, which is usually the first visible sign that a chunk of the URL map got missed. And keep an eye on Core Web Vitals data specifically, since a new design with heavier scripts or unoptimized images can quietly undo a page-speed win that was one of the reasons for the migration in the first place.

The bottom line

A migration that protects rankings isn’t the one with the most cautious design decisions — it’s the one with the most complete URL map and the most disciplined redirect and technical QA process behind the scenes. The visual side of a relaunch gets all the attention because it’s the part everyone can see. The technical handoff is the part that decides whether the traffic the old site earned actually survives to show up on the new one.

If a migration is on the roadmap and nobody on the team owns this checklist yet, that’s worth fixing before a launch date gets set, not after the first ranking report comes back with a drop nobody can explain.