A website redesign is one of the few marketing projects that can genuinely hurt you if it goes wrong. We've been brought in more than once to fix a rankings collapse that happened the week a beautiful new site launched. None of it was necessary — every case traced back to a handful of missed steps.
Why redesigns tank rankings
Search engines don't see your new design — they see a set of URLs, links and content that either matches what they previously indexed or doesn't. A redesign that changes URL structure, cuts content, or breaks internal linking without a plan is effectively asking Google to re-evaluate your entire site from scratch, and re-evaluation periods can cost months of visibility even when the new site is objectively better.
Before you start: audit what's already working
Before any design work begins, export a full list of your current top-performing pages by organic traffic and rankings, along with their backlink profiles. This becomes your protection list — the pages that must not lose their URL, core content, or internal link equity in the rebuild, no matter how the new information architecture is organized.
If a page currently ranks well, the redesign's job is to make it convert better — not to reinvent what's already working from an SEO standpoint.
URL structure and redirect mapping
If URLs are changing — which happens often during a CMS migration or information architecture overhaul — every single old URL needs a 301 redirect to its new equivalent. Not a blanket redirect to the homepage: a one-to-one mapping. Build this spreadsheet early, since it typically takes longer than teams expect, especially on sites with hundreds of legacy blog posts or product pages.
- Export every indexed URL from Google Search Console and your XML sitemap
- Map each old URL to its new destination before development starts
- Flag any URLs with no clear new-site equivalent for special handling
- Test redirects in staging before launch, not after
Content parity, not just visual parity
Redesigns often get treated as a chance to "clean up" copy — trimming word count, removing sections that look dense. Be careful here: if a page's ranking is partly earned by content depth that answers a range of related questions, cutting that content can cut the ranking along with it. Compare old and new page content side by side for your top pages, not just the homepage.
Technical pre-launch checklist
| Check | Why it matters |
|---|---|
| Robots.txt not blocking the new site | Staging environments often carry a disallow rule into production by accident |
| Canonical tags point to the correct new URLs | Prevents duplicate content confusion between old and new paths |
| XML sitemap updated and resubmitted | Speeds up re-crawling of the new URL structure |
| Structured data carried over or upgraded | Preserves rich results and AI/answer-engine visibility |
| Core Web Vitals tested on staging | A slower new site can offset ranking gains from better content |
| Analytics and conversion tracking verified | You need clean data starting day one, not after a two-week gap |
Post-launch monitoring
The first two weeks after launch deserve daily attention, not a "check back next month" approach. Watch Search Console for crawl errors and indexation drops, monitor your protection-list pages for ranking movement, and keep the redirect map handy — issues found in week one are a quick fix; issues found in week six have often already cost real traffic.
The best redesigns are the ones nobody notices happened, from a search visibility standpoint — the traffic just kept climbing.