Choosing between a website rebuild and a redesign

A website that isn't performing gets blamed on the design. Sometimes that's right — but often the design is fine and the problem is underneath it: a slow, hard-to-maintain codebase that makes every change expensive, or a content structure that was never built for how the business actually operates today.

Signs it's a redesign, not a rebuild

If the site loads reasonably fast, the codebase is current and maintainable, and the main issue is that the visual design and messaging feel dated or unclear, that's a redesign problem. The underlying system is sound; what's on top of it needs work. This is usually the faster, lower-risk path.

Signs it's a rebuild

If every content update requires a developer, the site is built on a stack that's no longer actively maintained, performance is poor regardless of what's changed on the surface, or the architecture doesn't support what the business needs now — multi-language, e-commerce, an integration that didn't exist when the site was built — a redesign alone won't fix it. The foundation itself needs to change.

The two are not mutually exclusive, and in most real engagements they overlap: a rebuild is also a chance to reconsider the design, and a redesign often surfaces technical debt worth addressing at the same time. The useful exercise isn't picking one label — it's being honest about which problems are cosmetic and which are structural before committing budget to either.

A short technical and content audit before scoping either option usually pays for itself: it turns a vague sense that 'the website needs work' into a concrete list of what's actually broken, what's outdated, and what would genuinely move the needle.