Start with what is not working
A redesign changes how a website looks and communicates. A rebuild can also change its platform, page structure, content management, performance, tracking and integrations. If customers cannot understand the offer or your team cannot safely update the site, a visual refresh alone may leave the central problem in place.
A redesign is enough when the foundation still works
Keep the existing foundation when it supports the content the business needs, produces acceptable Core Web Vitals, remains accessible, gives the business dependable ownership and can support clearer journeys without fragile workarounds. The scope can then focus on hierarchy, interface, copy, navigation and conversion detail.
Rebuild when the current system blocks progress
A rebuild is usually safer when the platform prevents necessary information architecture, produces persistent performance or accessibility debt, hides ownership across suppliers, makes measurement unreliable or cannot support the integrations and publishing workflow the business now requires.
Check what must survive the change
List the domain, DNS, hosting, email, analytics, search verification, forms, redirects and third-party tools before work begins. For each one, record who owns the account and what the website change might affect. This checklist protects services that customers rely on but cannot see in the new design.
Choose the smallest scope that resolves the real issue
Do not rebuild for novelty, and do not redesign to avoid necessary structural work. The useful choice is the least disruptive scope that removes the verified constraint and leaves the business with clearer ownership.