Refresh, redesign, or rebuild? Fix the right layer

Start with the layer

A website project often gets called a redesign before anyone checks what needs changing.

The logo feels dated, so the team asks for a redesign.

The CMS feels painful, so the team asks for a redesign.

The homepage gets traffic without enough leads, so the team asks for a redesign.

Those problems sit at different layers.

A refresh updates the presentation while the core structure stays useful.

A redesign changes how people understand and move through the website.

A rebuild changes the technical foundation, platform, or delivery setup.

The right scope starts with the failing layer.

For a refresh, the site already works. The main issue sits in visual age, weak imagery, dated typography, inconsistent spacing, or old brand presentation. Page structure, URLs, CMS, forms, and core journeys still make sense.

For a redesign, the problem runs deeper. Messaging feels unclear. Navigation grew without a plan. Important proof sits in the wrong place. Service pages overlap. Mobile flow feels weak. The current site still has a usable technical base, but the experience needs a new structure.

For a rebuild, the technical base has become part of the problem. The platform blocks required features. The content model creates constant workarounds. Performance problems come from the underlying setup. Security, integrations, deployment, or product logic require deeper engineering.

Know what changes

A refresh usually touches visual direction, copy edits, imagery, spacing, component polish, and selected sections.

A redesign often touches information architecture, sitemap, page hierarchy, messaging, navigation, proof placement, forms, responsive behavior, and visual design.

A rebuild touches the implementation layer as well. The project now includes migration planning, redirects, CMS decisions, new technical architecture, integration work, deployment, and deeper QA.

Search risk changes with scope.

Google's site move guidance treats URL changes as migration work. When a rebuild changes existing URLs, the project needs a URL map, permanent redirects, updated internal links, updated canonical signals, and an updated sitemap.

A visual refresh rarely needs the same migration plan.

This difference matters before a quote gets approved.

A team might ask for a full rebuild when the current platform still supports every business need. Another team might keep repairing an old setup even though every new page creates more technical debt.

Both decisions waste budget.

Choose the smallest scope

Start with five checks.

Does the current structure match the way buyers search and decide?

Does the current platform support the next two years of expected work?

Do important URLs already receive search traffic?

Does the team struggle with editing, publishing, tracking, or integrations?

Does the main problem sit in presentation, experience, or technology?

If presentation is weak and everything underneath works, start with a refresh.

If buyer understanding and page flow are weak, scope a redesign.

If the technical foundation blocks the business, plan a rebuild.

Some projects sit between categories.

A redesign might keep the existing CMS.

A rebuild might keep much of the visual system.

A refresh might include one new landing page for a priority offer.

Labels matter less than a clear scope.

I would rather define the failing layer, protect what already works, and spend the budget where the problem lives.

A bigger project creates more work, more migration risk, more review cycles, and more room for accidental damage.

The smallest scope which solves the real problem is usually the strongest starting point.