A website redesign changes the experience, while a rebuild replaces substantial technical or content foundations. Many projects need parts of both, so diagnose before naming the scope.

Keep the existing foundation when it reliably supports the new goals. Rebuild when the CMS, components, integrations or technical constraints prevent responsible improvement. Do not replace working systems only to make the project feel new.

The question is a scale, not a binary

Framing this as two options forces a choice that rarely matches the evidence. There are at least four levels of intervention, and the correct answer usually sits in the middle: keep the content and URLs, replace the component system and content model. Knowing the full range prevents a project being scoped at an extreme because only extremes were offered.

  • Repair: a few targeted fixes inside the existing system.
  • Restructure: same platform, reorganised information architecture.
  • Re-skin the front end: new interface, existing content and URLs retained.
  • Rebuild: new platform, new structure, full migration.

Choose a redesign when the foundation still works

A redesign can focus on positioning, hierarchy, interface and selected components when routes, content operations and technical delivery remain healthy. This case is more common than proposals suggest, because a smaller scope is harder to sell than a large one.

  • The CMS works and the team can publish in it.
  • URLs are sensible and hold established search positions.
  • Content is broadly current and needs editing rather than replacing.
  • Performance is adequate on mobile.

Choose a rebuild when constraints are systemic

A rebuild may be justified when templates cannot support the required experience, the CMS blocks routine publishing, integrations are fragile or the platform creates ongoing operational cost. The signal is that every change requires working around the system rather than with it.

  • Document the specific constraint.
  • Compare repair cost with replacement risk.
  • Preserve useful URLs and content wherever practical.
  • Check the constraint is systemic rather than confined to a few pages.

The migration cost a rebuild adds

Starting again feels cleaner because it avoids inheriting other people’s decisions. It carries a cost that rarely appears in the proposal: complete migration responsibility. Every URL, every piece of content and every integration must be deliberately carried across or deliberately abandoned. That work simply does not exist at a smaller scope.

  • A map of every current URL with a decision attached.
  • Risk of losing established positions through redirect errors.
  • Rebuilding integrations that currently work.
  • A longer path to launch and a wider testing surface.

Expect hybrid projects

Many projects keep valuable content and routes while replacing templates, components and CMS relationships. Describe each layer separately instead of forcing the whole project under one label. A proposal that treats content, interface and platform as three separate decisions is usually more accurate than one that offers a single package.

  • Content layer: keep, edit or rewrite.
  • Interface layer: refine or replace.
  • Platform layer: retain or migrate.
  • Each layer can move at a different level.

Decide from evidence

Audit representative pages, editor workflows, performance, accessibility, integrations and search visibility. The recommendation should connect observed problems to the minimum responsible intervention. A provider recommending a rebuild without examining the current site and its analytics is quoting, not advising.

  • Which pages actually generate traffic and enquiries?
  • What genuinely blocks the team day to day?
  • Is the constraint site-wide or limited to specific areas?
  • What is the smallest change that resolves the stated problem?

Practical decision checklist

  • Inventory what works and what fails.
  • Separate content, interface and platform issues.
  • Check analytics before deciding scope.
  • Estimate migration responsibilities honestly.
  • Choose the smallest responsible intervention.
  • Define acceptance criteria before production.

Frequently asked questions

Is a rebuild always more expensive?

It usually includes more implementation and migration work, but repairing an unsuitable foundation can also create ongoing cost.

Can I redesign without changing URLs?

Yes, and preserving useful URLs can reduce migration risk when the information architecture remains appropriate.

Should a rebrand trigger a rebuild?

Not automatically. Evaluate whether the existing system can support the new identity, content and experience.

Is a rebuild safer because everything is new?

Not inherently. A larger change means more decisions and more migration responsibility, which means more places where something can go wrong.

Who should make this decision?

Someone who can see both the traffic data and the team’s daily experience of the system. A decision based only on how the site looks almost always produces a larger scope than the problem requires.