Redesign or Rebuild? Deciding What Your Site Needs

• A refresh: new colours, typography, imagery and some layout changes on the existing build. Cheapest, fastest, and often enough.
• A redesign: new design across the site, implemented on the existing platform and content structure. The templates change; the foundations don't.
• A rebuild: new theme or new architecture, usually keeping the content. The foundations change, and the design may or may not.
• A replatform: moving to a different system entirely. The largest, and the one that needs the strongest justification.
• These are frequently conflated in a brief, which is how a project scoped as a redesign turns out to need a rebuild halfway through.

• The site is fast, editable and secure, but the design is visibly of another era.
• Your brand changed and the site no longer matches it.
• The layout doesn't support the content you now have — you've added services the navigation was never designed for.
• Analytics show people arriving and leaving without engaging, and the content is good.
• Competitors look substantially more credible, which affects whether people trust you enough to enquire.

• Editors avoid updating the site because it's painful, so content goes stale.
• Every change needs a developer, including things that shouldn't.
• The site is slow and previous optimisation attempts hit a ceiling.
• It's built on an abandoned theme, or a page builder that's no longer maintained.
• Adding a feature means fighting the existing structure every time.
• Nobody has the code, or the code is only on the server.
• Security incidents have happened more than once.
• It isn't genuinely usable on a phone, and patching that is more work than starting over.

This is the option nobody proposes and it's often the right one.

If the site works, is reasonably fast and is editable, the highest-return spend is usually content and conversion work: better answers to the questions customers actually ask, clearer calls to action, faster pages, proper tracking so you know what's happening.

A redesign often resets whatever was working without addressing what wasn't. Sites regularly lose traffic after a redesign because content was trimmed and internal linking degraded, while the visual improvement changed no behaviour at all.

Before committing, look at the analytics. If you can't say which pages bring enquiries and which don't, you're not ready to redesign — you're ready to measure.

• Look at analytics: where do people arrive, where do they leave, which pages precede an enquiry?
• Look at Search Console: what are you ranking for, and what are you nearly ranking for?
• Ask the people who edit the site what they can't do, or avoid doing.
• Ask the people who answer the phone what customers ask that the site should have answered.
• Test on a mid-range phone on mobile data, which is how most people see it.
• Get a technical review: performance, security, code quality, maintainability.
• Write down the three problems the project must solve. If you can't, stop.

The most expensive rebuild mistake is throwing away things that were working.

• URLs. If they change, every one needs a 301 to its closest equivalent, individually.
• Content. Trimming copy during a rebuild is a separate change that will confound your ability to judge the result.
• Internal linking, at least as good as it was.
• Titles and meta descriptions that were written deliberately, rather than regenerating everything from a template.
• Pages that rank, even if they're ugly. Redesign them; don't delete them.
• Tracking and conversion measurement, which breaks silently during rebuilds more often than anything else.

A full rebuild is disruptive and expensive. Quite often it can be broken up.

Fix performance and security first, as standalone work. Then improve the content on the pages that matter. Then redesign the templates that most need it. A rebuild, if it's still warranted, comes last and with better information.

This also spreads the cost and means you get value early rather than after a six-month project that lands all at once.

Avoid launching immediately before your busiest period. Whatever goes wrong, goes wrong when it costs most.

Allow for the search dip. A rebuild with URL changes typically takes six to eight weeks to settle, so don't judge it at two and don't schedule it just before the season you depend on.

And make sure the content is ready before the build starts. Content is the most common cause of a project running over, and it's the one thing the developer can't do for you.

Write down the three things the current site fails at, in terms of what it costs you. Then ask which of the four options — refresh, redesign, rebuild, replatform — actually fixes those three.

If the honest answer is that the problems are content and speed, do that work and keep the design. If the answer is that the foundations make everything hard, rebuild and don't let a design conversation distract from it.

If you'd like a second opinion on which category your site is in, send me the URL and what frustrates you about it, and I'll tell you what I'd do.