When to Redesign Your Website — And When Not To

Most redesigns begin with a feeling rather than a finding: the site looks dated, a competitor launched something slick, a new marketing lead wants their own version. Six months and a substantial budget later, the numbers are often unchanged — or worse.

That is not an argument against redesigns. It is an argument for knowing which problem you are solving.

Signals that justify a rebuild

Some problems genuinely cannot be fixed with patches, because they are structural.

• The information architecture no longer matches the business — services have changed, and the navigation is a museum of what you used to do.
• The platform blocks the team: nobody can publish a page without a developer, so nothing gets updated.
• Performance and mobile experience are poor at a foundational level, not because of a few heavy images.
• The site cannot integrate — no clean way to connect a CRM, booking, payments or an AI layer.
• Accessibility failures are systemic rather than incidental.
• The brand has genuinely changed: new positioning, new audience, new offer.

Signals that do not

Other complaints feel urgent and are almost always cheaper to fix directly.

Low conversion on one page is a page problem — new copy, better CTA placement, clearer proof. Ranking decline is usually a content and technical issue, not a design one. Slow load times are typically images, fonts and third-party scripts. 'It looks dated' can often be resolved with typography, spacing and colour refinement on the existing structure.

The test: can you name the metric that will move, and the mechanism by which the redesign moves it? If not, you are buying a new look and hoping.

The hidden risk nobody plans for

The most expensive redesign outcome is a traffic collapse caused by an unmanaged migration. URLs change, redirects are missed, metadata is regenerated by a template, and six years of accumulated search equity disappears in a fortnight.

• Export the full URL inventory and the top pages by traffic before anything starts.
• Map every old URL to a new one, with permanent redirects, and test them after launch.
• Preserve titles, descriptions and structured data unless you are deliberately improving them.
• Keep the highest-traffic content intact rather than 'refreshing' it into something new.
• Benchmark performance and rankings before launch so you can detect a regression quickly.

A better sequence

Where a rebuild is justified, the lowest-risk path is rarely a single big-bang launch. Fix the highest-value pages first, in place. Rebuild in sections where the platform allows. Ship the new structure with the proven content rather than rewriting both at once.

That way, if the numbers move the wrong way, you know which change caused it.

Redesign as a system decision

The strongest reason to rebuild is not appearance at all: it is that the current site cannot participate in the business — cannot capture context, cannot connect to your tools, cannot support automation or an assistant.

That is a capability gap, and it is the one case where a rebuild reliably pays for itself.