Redesign or replatform without losing your rankings

Why redesigns tank traffic when the design is fine

The pages look better and the traffic falls anyway. The reason is that your rankings are attached to URLs, not to your brand or your design. When a redesign changes the URL structure, removes pages, rewrites content, or strips out internal links, Google sees new pages with no history rather than improved versions of pages it already trusts. It has to recrawl and reindex from a weaker starting position, and the link equity those old URLs earned has nowhere to flow.

Most redesign traffic loss traces to a short list of causes: URLs changed without redirects, pages that ranked simply deleted, body copy rewritten so it no longer matches the queries it used to win, and internal links lost when navigation and footers were rebuilt. A clean migration with everything mapped still sees a small re-indexing wobble of roughly 5 to 10 percent for a couple of weeks. A sudden 30 to 50 percent drop is not normal settling; it is a broken migration, and it almost always points back to redirects.

The trap is timing. Stakeholders judge a redesign on how it looks at launch, then traffic erodes over the following weeks while everyone assumes Google is just catching up. By the time the decline is undeniable, the staging site is gone and the original URLs are hard to reconstruct. Protecting rankings is pre-launch work, not a fix you apply after the numbers fall.

Inventory what you have before you touch anything

You cannot protect rankings you never wrote down. Before the new site exists, crawl the current site and pull a complete inventory of live URLs, then layer in the data that tells you which ones matter. Export your indexed pages and clicks from Search Console, pull rankings and backlinks from a tool like Ahrefs or Semrush, and flag every URL that earns traffic, holds a keyword position, or has external links pointing at it. These are the pages a migration must not lose.

This benchmark is also your evidence. If you never recorded what normal looked like, you cannot prove the migration succeeded, and you cannot diagnose a drop because you have nothing to compare against. Capture organic sessions, top landing pages, and keyword positions in the weeks before launch so you have a clean baseline. A redesign is a fair moment to prune genuinely dead pages, but prune deliberately from the data, not by accident because a page did not make it into the new build.

Redirect mapping is the single biggest risk

If you do one thing right, make it this. Build a redirect map that pairs every old URL with the single most relevant new URL, and serve it as a 301 permanent redirect. Google is explicit that this is safe: per its site-move documentation, 301 and other permanent redirects do not cause a loss in PageRank. A 302 is temporary and can fail to pass full equity, so use 301 for anything that has moved for good. This map is the bridge that carries your rankings from the old structure to the new one.

The most common scaling mistake is lazily redirecting everything to the homepage. Google treats mass homepage redirects as soft 404s and discards the equity you were trying to save. Map each old page to its closest equivalent: an old basement-finishing service page to the new one, an old project gallery to its rebuilt version. Where a page has no equivalent, redirect to the nearest relevant parent, not the homepage. Keep the redirects live for at least a year, since that is how long Google says it needs to fully transfer signals to the new locations.

The cheapest move of all is to change nothing you do not have to. Every URL you preserve is a redirect you do not have to build and an equity transfer that cannot go wrong. Where the new platform allows it, keep existing URL paths intact, and limit redirects to the pages whose structure genuinely has to change.

Preserve the on-page signals that earned the rankings

Redirects move the address, but the page still has to deserve the ranking when it arrives. For your top organic pages, carry over the elements that won the traffic in the first place: title tags, H1s, the core body copy, and the keywords it already ranks for. A redesign that rewrites every page for a cleaner layout can strip the exact phrasing Google matched to a query, so a "home addition contractor" page that ranked for years suddenly does not, and the ranking goes with it. Improve content deliberately and measure it, but do not let a design pass silently gut the pages that book the jobs.

Internal links are the quiet casualty of most rebuilds. New navigation, new footers, and new templates routinely drop the internal links that funneled authority to your money pages, leaving them orphaned and slower to recrawl. Rebuild the internal link structure intentionally so your important pages stay within a few clicks of the homepage and keep the descriptive links pointing at them. Treat your old internal link graph as a spec to reproduce, not something to recreate from memory.

Staging precautions and launch day

The new site gets built on a staging environment, and staging has to be hidden from Google without poisoning the live site. Block it with HTTP password protection or a noindex directive so it never gets indexed and never competes with your live pages as a duplicate. The danger is the handoff. Moz lost 33.2 percent of its search traffic when a deploy accidentally pushed a site-wide noindex from a sprint live across every page, and it took weeks to recover. The number-one launch-day check is that staging's noindex and any disallow rules did not ship with the new site.

Launch is a sequence, not a switch. The redirects go live the moment the new site does, so no window exists where old URLs return 404s. Then submit the new XML sitemap in Search Console, confirm robots.txt is not blocking anything you want indexed, and verify a sample of old URLs actually 301 to the right new pages. For a domain change, file the Change of Address tool in Search Console so Google knows the move is intentional. Change one major thing at a time where you can; stacking a domain move, a replatform, and a content overhaul into one launch makes any later drop almost impossible to diagnose.

Monitor relentlessly for the first eight weeks

A migration is not done at launch; it is done when the new site has held its rankings. Watch Search Console daily for the first two weeks, then weekly for the next two months. Track crawl errors and the index coverage report to confirm Google is discovering and indexing the new URLs, hunt down 404s from any old URL that slipped the redirect map, and watch for redirect chains that dilute equity. Compare current rankings and organic sessions against the baseline you captured, page by page, so a localized drop does not hide inside a healthy total.

Expect a modest dip and resist the urge to panic-edit on day three. Real recovery takes weeks while Google recrawls and transfers signals, and the SEJ data shows even healthy migrations can take many months to fully settle. What you are watching for is the difference between normal re-indexing and a real problem: a missed redirect, a deindexed section, a content change that broke a top page, or a Core Web Vitals regression from heavier new templates. Find and fix those in the first weeks, while the cause is still obvious and the fix is cheap.

How WellBuilt handles site migrations

We treat a migration as a managed project with the SEO work running alongside the design and build, not bolted on after launch. Before anything ships, we crawl and inventory your live URLs, pull rankings, traffic, and backlinks to flag the pages that must survive, and record a clean baseline so success and any drop are both provable. The redirect map is built and reviewed page by page, because that is where migrations fail.

Through launch we noindex staging, verify the redirects go live with the new site, submit the sitemap, and handle the Change of Address where a domain moves. Then we monitor crawl errors, 404s, rankings, and Core Web Vitals against your baseline through the settling period and act on regressions while they are still cheap to fix. Recovery timelines depend on the scale of the change and your starting authority, so we report against your own benchmark rather than promising a fixed number.