Do I need a new website or can I improve my old one?

Separate an old appearance from a broken foundation

A website can look dated and still have valuable pages, useful search visibility and a working contact path. Equally, a new-looking site can be slow, confusing or difficult to manage. Judge the current site against customer tasks rather than its age alone.

List the changes you need in plain language: clearer service explanations, easier mobile enquiries, updated project photos, online booking or simpler editing. Ask a provider to explain which changes fit the existing platform and which genuinely require different technology.

Check that you control the domain and can access the website, hosting and relevant accounts. Identify who maintains the platform, whether updates are supported and whether a recoverable backup exists. If access is missing, restoring it may be the first task before either a refresh or a rebuild.

When is a targeted refresh the better option?

A refresh is worth considering when the platform works and the main gaps are communication. You might rewrite the home page, improve two priority service pages, replace generic imagery with real work and simplify the enquiry path. Give the work a defined scope and judge it against the business problem.

For example, an established mechanic may already be found for its name and core services. If customers cannot tell whether it offers a particular specialist service, improving that page and adding relevant project evidence may be more useful than changing the entire site.

Ask for a staged option: essential fixes first, then content and design improvements. This lets you address the biggest issue while retaining the parts that work. It also reveals whether hidden limitations make further investment in the old system unreasonable.

When does rebuilding make more sense?

A rebuild may be justified when the platform is no longer supported, essential functions are unreliable, mobile use cannot be repaired sensibly or necessary integrations cannot be added. It can also make sense when ongoing workarounds cost more than a maintainable replacement.

Compare the full cost of both options, including content work, migration, testing, training and ongoing fees. Ask the provider to identify the specific limitation being solved. “It is old” is not a sufficient explanation for replacing a system your business depends on.

Choose the new platform around your team’s ability to use it. A system with impressive features is a poor fit if nobody can update opening hours, add a project or manage an enquiry. Include handover and access arrangements in the scope.

How do you protect what is already working?

Before changing the site, record its page addresses, useful content, search performance and contact journeys. Preserve valuable URLs where practical. If addresses must change, map each old page to the most relevant new destination and implement appropriate permanent redirects. Google’s migration guidance also recommends testing and monitoring the move; search fluctuations can occur.

Further reading: Google: site moves with URL changes.

What should you ask before agreeing to the work?

Ask for a clear recommendation with the evidence behind it, plus a smaller alternative where feasible. The proposal should say what stays, what changes, who supplies content and how launch problems will be handled.

Have a launch checklist that covers phones, links, forms, redirects and access. Confirm who will monitor problems afterwards and how you would restore service if something serious fails. Keep copies of approved content and a record of your accounts.

A new website is a means to an outcome. If the goal is more suitable enquiries, define what customers should understand and do differently. If the goal is less administration, define the workflow the new system must support. That gives you a stronger basis for judging the result than whether the design feels fresh.