Should you refresh your website or rebuild it?

Start with the problems customers encounter

Before choosing a solution, write down the problems you can observe. “It feels old” is worth exploring, but “the enquiry form fails on a phone” gives the work a much clearer purpose.

Try these checks:

• Find a service without using the homepage's main button.
• Complete the contact process on a phone.
• Read the opening as someone who has never heard of the business.
• Try changing an opening time or replacing a photograph yourself.
• Check whether your current services and contact details are accurate.

For each problem, note its impact and where it occurs. A contact form failing across the site deserves different attention from an old image on a rarely visited page. Use any real enquiry feedback or analytics you have, while keeping assumptions separate from evidence.

A refresh is worth considering when the foundation works

A focused refresh may be suitable when you can edit the site reliably, the platform is maintained, and the important customer paths work. Perhaps the offer has changed, the photography is dated or the page hierarchy makes useful information hard to find.

The work might include rewriting the opening, clarifying service descriptions, replacing images, simplifying navigation and improving the contact process. It can still involve substantial design work. What makes it a refresh is that useful parts of the existing site can remain in place.

Ask the designer to identify those parts. Keeping a working booking tool, useful service pages or a familiar editing workflow can be a deliberate decision. Reusing them should be reflected in the scope and the checks performed before launch.

A rebuild becomes more reasonable when the limits are structural

Consider a rebuild when the current setup cannot support important requirements without repeated workarounds. Examples include a platform that cannot deliver a usable phone layout, an editing system nobody can maintain, or templates that prevent you from organising the services sensibly.

Security problems also need investigation. An unsupported plugin may have a straightforward replacement; a compromised installation may require specialist recovery. A cosmetic refresh does not resolve either by itself, and a new design should not be used as evidence that the underlying issue is fixed.

New requirements can change the decision too. Adding a real booking system or a product catalogue is different from changing the colours. Establish what the site needs to do, then assess whether the current setup can support it reliably.

Match the scope to the problem

For each issue, write down what fails, where you saw it, what should happen instead and how you will check the repair. For example: “On the contact page, a phone user cannot reach the send button. The revised form must show every field and the button, then confirm a successful test submission.”

Keep the scope proportionate to the findings. If content is inaccurate but the platform and contact route work, start with the content. If routine updates, phone layouts and essential connections all require workarounds, ask for a comparison of repairing the current setup and rebuilding it.

An example from Digital Upstream

The Digital Upstream homepage had a decorative SVG sculpture that continuously recalculated its paths and gradients. The visual identity was useful, but the rendering work was expensive. Project images also needed more appropriate delivery sizes.

The change retained the artwork as a standalone SVG, replaced the continuous geometry work with a short transform animation and enabled responsive image delivery. It addressed the implementation while preserving the design's recognisable feature.

In the recorded before-and-after PageSpeed runs on 26 October 2026, mobile performance rose from 39 to 87 and desktop from 59 to 99. Mobile largest contentful paint, a measure of when the largest visible content is rendered, fell from 7.7 to 3.7 seconds. Baseline report · After report.

These laboratory runs measured my own site on that date, before a later font-loading cleanup. Scores vary between tests. The mobile result still left room for improvement, and these runs do not establish a real-user Core Web Vitals pass or an increase in enquiries.

The decision was to keep the visual idea and change how it was delivered. Rebuilding the same expensive animation in a new template would have carried the problem into the replacement. Ask what causes the issue before agreeing how much of the site to replace.

Protect what the existing site already does well

Before a rebuild, make an inventory of important pages, images, downloads, forms and integrations. Include the pages receiving relevant search traffic or enquiries where you have that evidence. Record who controls the domain, hosting, email and editing accounts, and agree how they will be handed over.

Where possible, keep useful page addresses. If an address must change, map the old page to its closest replacement and test the permanent redirect. Google recommends a URL mapping, permanent redirects and checks of links, canonical URLs and sitemap details during a move. It also advises against sending unrelated old pages to the homepage. Google's site-move guidance.

After launch, test the forms, phone links, booking tools and any payments involved. Check page titles, crawl settings and important redirects as well as the appearance. A launch checklist should describe these checks explicitly.

Questions to ask before accepting a proposal

1. Which observed problems will this work resolve?
2. What will you preserve, and why?
3. What makes the current platform suitable or unsuitable?
4. Which pages, URLs and integrations will change?
5. Who provides copy, photography and approvals?
6. What happens to hosting, email, access and maintenance?
7. How will the contact process and launch be tested?
8. What is excluded, and how are extra requirements priced?

A useful proposal makes the decision understandable. It should explain why the proposed amount of change fits your business and the condition of the site you have.