Web design for leads · The mechanics
How to redesign a website without losing your rankings.
If you’ve spent years building traffic, the scariest part of a redesign isn’t the cost or the timeline — it’s the chance you wake up on launch day with half your rankings gone. It happens. It’s almost always self-inflicted, and it’s almost entirely preventable. Here’s the migration checklist that protects what you’ve built, why traffic dips happen, and how to tell a normal wobble from an emergency.
A redesign should change how the site looks — not what Google knows about it.
The number-one fear of a business with real organic traffic is also the number-one way agencies blow a redesign: they treat the site as a blank canvas, rebuild it the way they’d build a brand-new one, change every URL, rewrite every heading, drop the pages that “look thin” — and then act surprised when traffic falls off a cliff. It doesn’t have to be like that. A clean migration is a checklist, not a gamble. Google’s ranking signals are attached to URLs, content and links; preserve those, and the rankings come along for the ride. The work is in being disciplined, not lucky.
The fear is real — but the cause is usually you
Let’s be honest about the failure mode. When traffic tanks after a redesign, it’s rarely “Google penalised the new design.” It’s that the migration broke the things rankings depend on: URLs changed with no redirects, so the equity Google had assigned to those pages now points at 404s. Or content got “cleaned up” and the page that ranked for a term no longer contains the term. Or a `noindex` tag from the staging site rode along to production. Or the internal links that fed authority around the site got rebuilt and half of them now go nowhere.
That’s the good news, oddly: a self-inflicted problem is a preventable problem. You’re not at the mercy of an algorithm. You’re at the mercy of whether whoever does the migration follows the checklist. So make the checklist non-negotiable, and ask any agency you’re considering to walk you through theirs before you sign. If they don’t have one — or it’s “we’ll set up redirects” with no detail — that’s your answer. (For the morning-after diagnostic, when something has gone wrong, see why did my traffic drop after a redesign.)
Before anyone touches anything, export your current top-performing pages — the ones with rankings and traffic — and treat that list as sacred. Those URLs either survive the redesign unchanged, or every single one of them gets a 301 to its closest equivalent. Not “most of them.” Every one.
The migration checklist
This is the whole job, in order. Skip a step and you’ve found your future traffic dip.
- Crawl and inventory the old site. Full crawl — every URL, its title, its H1, its inbound internal links, and (from Search Console and analytics) what it ranks for and what traffic it gets. You can’t preserve what you haven’t catalogued. This inventory is the spine of the whole migration.
- Preserve URLs where you can; 301 every one you can’t. The cheapest, safest move is to keep the existing URL structure. Where the rebuild genuinely needs new URLs, every old URL gets a permanent (301) redirect to its closest match — page to page, not “everything to the homepage,” which Google treats as a soft 404 and you lose the equity anyway.
- Keep the content and the headings. A page ranks because of what’s on it. If a page is performing, the new version contains the same substance — same topic, same key phrases, same H1 and heading structure (improved, not gutted). “Refreshing the copy” on a page that ranks is how you stop ranking. Improve weak pages; don’t strip strong ones.
- Rebuild the internal links. Internal links pass authority and tell Google how the site fits together. Map the old link structure, and make sure the new site links at least as well — pillars linking to supporting pages, related pages linking to each other, no orphans. (This is its own discipline — more on internal link architecture.)
- Submit a fresh XML sitemap. New site, new sitemap, submitted in Search Console on launch day so Google finds the new structure fast instead of stumbling onto it.
- Use Search Console properly. Both old and new properties verified, the sitemap submitted, the Change of Address tool used if the domain itself changes, and the coverage and Core Web Vitals reports watched after launch. Search Console is your early-warning system; have it switched on.
- Build and review on staging — then check it’s not indexable. The new site gets built on a staging URL so you can review the real thing. And then — this is the one that bites people — make absolutely sure the staging site’s `noindex` / robots block does not survive to production. A live site that’s accidentally telling Google not to index it disappears, fast.
- Launch-day verification. The moment it goes live: spot-check that redirects fire (old URL → new URL, 301, correct destination), that nothing is `noindex`, that robots.txt isn’t blocking, that the sitemap resolves, and that titles and H1s came across. An hour of checking on launch day prevents a month of recovery.
- 30-day monitoring. Watch rankings, organic traffic, Search Console coverage and crawl errors for the first month. Catch a missed redirect or an indexing problem in week one and it’s a five-minute fix. Catch it in month three and it’s a project.
That’s it. None of it is exotic. It’s just work that’s easy to half-do — which is exactly why so many redesigns go wrong, and why “we ship in 14 days” only counts as a feature if the migration is part of the 14 days, done properly. On the web design build it is: Phase 01 grades every existing page and builds the redirect map before any pixels move, and launch includes the 301s and the handover. The speed comes from a tight system, not from skipping the safety steps.
“We rebuilt the site and lost half our traffic” is almost never a story about Google. It’s a story about a redirect file that nobody finished.
When a dip is normal — and when it’s an emergency
Even a clean migration can wobble for a couple of weeks. Google has to recrawl the new site, follow the redirects, reassess. A mild, brief dip — a few positions, a couple of weeks, then recovery — is the system settling. Don’t panic-revert on day three; you’ll just create a second migration on top of the first.
An emergency looks different: a sharp, broad drop across many pages at once; rankings vanishing rather than slipping; Search Console showing a spike in 404s, a `noindex` on key pages, or a crawl block; pages dropping out of the index entirely. That’s not the system settling — that’s a step that got skipped, and it won’t fix itself. Triage immediately: check indexability first (`noindex`, robots.txt), then redirects (are the old URLs 301-ing to the right places?), then content (did key pages keep their substance and headings?), then internal links. The full triage order is on why did my traffic drop after a redesign — but the short version is: if it’s broad and sharp, act now; if it’s mild and narrow, give it two to four weeks.
If your site has essentially no organic traffic to begin with, there’s nothing to lose in the move — and the migration discipline, while still worth doing, isn’t the thing standing between you and leads. Your problem is upstream: coverage and authority. A redesign that doesn’t also add the pages people are searching for will look better and rank about the same. If “nobody’s finding it” is the real issue, that’s topical authority territory, not a migration problem. And if you’re weighing rebuild against patching, the honest decision tree is on new website, or just fixes.
Where this fits
A redesign is the middle move in this cluster — speed, copy and trust make a site that converts; this is how you get there without burning down the traffic that feeds it. Treat the migration as part of the build, not an afterthought, and a redesign is pure upside: same rankings, far better conversion. That’s how the web design service runs it — and if you want it watched after launch, the care plan covers the 30-day-and-beyond monitoring. The rest of this cluster — speed, copy, trust — is what you’re rebuilding toward.
Common questions
On migrations, specifically.
Will I definitely lose rankings if I redesign?
No — not if the migration is done properly. Rankings attach to URLs, content and links; keep those intact (or 301 every changed URL, keep the substance and headings, rebuild the internal links) and the rankings transfer. Most “we lost traffic after a redesign” stories are missed redirects or a stray `noindex`, not the design. The diagnostic for when it does go wrong is on why did my traffic drop after a redesign.
Should I keep my old URLs or change them?
Keep them, almost always. The safest migration is the one where the URL structure doesn’t change at all. If the rebuild genuinely requires new URLs — moving off a builder’s ugly URL scheme, restructuring into proper topic folders — then every old URL gets a 301 to its closest new equivalent, page to page. Never redirect everything to the homepage; Google reads that as a soft 404 and you lose the equity anyway.
How long until traffic settles after a clean migration?
Usually a couple of weeks of mild wobble while Google recrawls and follows the redirects, then it settles back. A small, brief dip is normal — don’t panic-revert. A sharp, broad drop is not normal and means something got skipped; triage it immediately. Either way, watch Search Console and your rankings for the first 30 days. If you’d rather not watch it yourself, the care plan covers post-launch monitoring.
Does moving to WordPress from Wix or Squarespace risk my rankings?
Only if the move is sloppy. A platform change is just a migration — same checklist applies: inventory the old site, 301 every URL, keep the content and headings, rebuild the internal links, sitemap, Search Console, staging, launch-day checks. Done right, you keep your rankings and gain a platform you don’t outgrow. The platform trade-offs themselves are on WordPress vs. Wix or Squarespace.
Q2 capacity · 4 builds · 2 slots remaining
New site. Same rankings.
Send us your URL. We’ll send back a free 5-minute Loom — what we’d preserve, what we’d redirect, and how we’d rebuild it without putting the traffic at risk. No call required.