Website redesign without throwing away your rankings
Most redesign disasters are redirect disasters. The design was never the problem.
A website redesign should start with a crawl of the existing site, a map of every URL that has traffic or backlinks, and a redirect plan — before any design work. Redesigns lose rankings when URLs change without 301s, not because the design changed. Budget six to ten weeks, and expect a two-to-four week dip before recovery.
Key takeaways
- Crawl and benchmark the old site before you touch it; you cannot prove recovery without a baseline.
- Every URL with traffic, rankings or backlinks needs a 301 to its closest new equivalent.
- Rebuild the tracking plan too — half of redesign 'traffic drops' are broken analytics, not lost traffic.
- Expect a two-to-four week dip, then recovery. A drop that has not recovered in six weeks is a redirect bug.
We get a version of this call every few months. The new site went live last Tuesday, it looks far better than the old one, and organic traffic is down sixty percent. Nobody can explain it, and the agency that built it has gone quiet.
It is almost always the same cause. The URL structure changed, nobody mapped the old addresses to the new ones, and six years of accumulated ranking equity is now pointing at 404 pages.
What to do before any design work starts
- 01Crawl the current site and export every URL, along with its title, status code and canonical.
- 02Export the last sixteen months of Search Console data — pages, queries, clicks — so you have a baseline to measure recovery against.
- 03Pull your top landing pages from GA4 and your top linked pages from any backlink tool. These are the pages you may not break.
- 04Decide the new URL structure now, before the sitemap is designed, and freeze it.
- 05Write the redirect map as a spreadsheet: old URL, new URL, reason. Every row with traffic needs a destination that answers the same intent.
What actually needs rebuilding
A redesign is a good moment to fix the things that were never design problems in the first place.
- Tracking — GA4 events, ad platform conversions and CRM integration all break on a rebuild. Rebuild the plan deliberately and verify each event; see Conversion & Analytics.
- Schema — organisation, breadcrumb, FAQ and product markup carried across, not silently dropped with the old theme.
- Performance budget — the reason the old site got slow is that nothing stopped it. Set a ceiling and enforce it in CI.
- Content debt — pages that rank but read like 2019. Rewriting them during the migration costs less than doing it as a separate project later.
Timeline and cost
| Stage | Duration | Who is blocking |
|---|---|---|
| Audit, crawl and redirect map | 1 week | Us |
| Architecture and content plan | 1 week | Shared |
| Design | 2–3 weeks | Your approvals |
| Build and content migration | 3–4 weeks | Us, plus your content |
| QA, tracking, launch | 1 week | Us |
| Watch and fix | 2 weeks after launch | Us |
Total: six to ten weeks for most business sites. Content is the usual reason it becomes twelve — the build is rarely the thing waiting.
The two weeks after launch
Launch day is not the end of the project. For the first fortnight, someone should be checking Search Console coverage daily, watching for 404s in the server logs, confirming the sitemap is being read, and comparing GA4 landing pages against the pre-launch baseline. A dip in week one is normal. A dip still there in week six is a bug with a spreadsheet-shaped fix.