Redesign when the underlying platform, URLs and content can still support the business. Rebuild when security, maintainability, mobile behaviour, performance or structural limitations make targeted improvements unreliable or more expensive than replacement.
Redesign, repair and rebuild are different decisions
| Option | Best when | Main risk |
|---|---|---|
| Targeted repair | A few technical or content problems are isolated | Hidden platform problems may remain |
| Focused redesign | The website works but looks dated or converts poorly | Changing visual appearance without fixing content or journeys |
| Complete rebuild | The platform is obsolete, insecure or structurally limiting | Migration errors, lost URLs or unnecessary replacement |
Signs a focused redesign may be enough
- The content is accurate and the page structure is broadly useful.
- The CMS or codebase is supported and can be maintained safely.
- Core URLs can be preserved without complex migration.
- The main problems are visual hierarchy, mobile usability, calls to action or content clarity.
- Forms, analytics and integrations are still reliable.
Signs a rebuild may be safer
- The website depends on obsolete software or unsupported plugins.
- Security incidents repeat because the underlying stack cannot be maintained.
- Mobile layout and accessibility require extensive structural work.
- The navigation and URL structure cannot support current services or search intent.
- Performance problems come from architecture rather than a few assets.
- Ownership, source files or administrative access are missing.
Protect search visibility during a redesign
Record existing URLs, traffic pages, titles, headings, internal links and conversions before changing anything. Preserve valuable content, map every changed URL to the closest replacement, implement permanent redirects, update canonical tags and sitemaps, and verify analytics and forms after launch.
Use evidence before choosing
A visual preference alone is not enough. Review mobile usability, Core Web Vitals, search-console data, enquiry paths, server condition, security, content gaps and the ability of staff to maintain the site. The correct choice may be a smaller repair followed by staged improvements.
Questions to ask a redesign provider
- Which existing URLs and content will be retained?
- What evidence justifies a rebuild?
- How will redirects, analytics, forms and tracking be verified?
- Will the current website remain online during staging?
- Who owns the final code, content, domain and accounts?
- What is the rollback plan if launch problems occur?