Improve your existing website when the business direction is still sound, the platform remains supportable and the problems are contained. Rebuild when the site’s structure, technology or content model prevents the business from serving its audience reliably—and fixing each symptom would cost more or create more risk than replacing the foundation.

The decision should not begin with whether the design looks dated. It should begin with the job the website must do, the evidence that it is not doing that job and the scale of change required.

Improvement and rebuilding solve different problems

An improvement keeps most of the current foundation and changes selected parts. Examples include clarifying a service page, simplifying navigation, improving a form, replacing weak imagery, correcting accessibility issues or addressing specific performance bottlenecks.

A rebuild changes much more of the foundation. It may involve a new information architecture, content model, design system, platform or codebase. A rebuild can preserve the same domain and many of the same URLs, but it still requires migration planning, testing and operational change.

Neither option is automatically more professional. A focused improvement can create useful value faster when the underlying system is healthy. A rebuild can be the more proportionate choice when years of patches have made the site difficult to change, secure or understand.

Improve the current website when the foundation still fits

Incremental improvement is usually worth considering when most of the following are true.

The business proposition and audience are already clear

If the website is aimed at the right people and the main offer remains relevant, the problem may be how clearly the site communicates and supports the next step. Rewriting priority pages, improving evidence, reorganising navigation or simplifying calls to action may be enough.

Google’s people-first content guidance asks whether content serves an intended audience, demonstrates useful knowledge and leaves the reader better able to achieve a goal. Those questions are relevant beyond search: they help distinguish a content problem from a platform problem. (Google Search Central: creating helpful, reliable, people-first content)

The issues are specific and measurable

An improvement project is easier to justify when the problems can be named. For example:

• people cannot find a priority service;
• an enquiry form asks for too much information or fails on mobile;
• important pages load slowly;
• content is inaccurate or difficult to maintain;
• navigation labels do not match the language customers use;
• a key journey has an accessibility barrier.

This makes it possible to define a baseline, implement a bounded change and check whether the experience improved. It also prevents a visual redesign from becoming a substitute for diagnosis.

The platform is supportable

The current content management system, hosting and integrations should still receive appropriate support and allow safe changes. If the business can update content, maintain dependencies, back up data, manage access and test releases without unreasonable effort, there may be no need to replace the platform.

The information architecture can accommodate the next stage

The site does not need to anticipate every future idea. It does need enough flexibility to add the next likely service, market, language, campaign or content type without forcing confusing workarounds.

If a few navigation or page-template changes will create that room, improvement may be the more sensible path.

Rebuild when the constraint is structural

A rebuild deserves consideration when several problems share the same underlying cause.

The website no longer matches the business

A company may have changed its audience, offer, markets or sales process while the website still reflects an earlier version of the business. If almost every page needs a new purpose and the navigation no longer represents how customers make decisions, patching individual pages can preserve the wrong structure.

Before rebuilding, document the new audience, offer and priority journeys. A new platform cannot resolve strategic ambiguity on its own.

The content model blocks routine work

Some websites make ordinary changes unnecessarily difficult. Teams may need developer help to edit basic content, duplicate pages for each campaign or place unrelated information into one inflexible template.

When these constraints are built into the platform or data model, repeated workarounds can become more expensive and error-prone than defining a cleaner system.

Performance or accessibility problems are systemic

Performance should be assessed using real evidence, not only how a page feels on one office laptop. Google’s Core Web Vitals focus on loading performance, interaction responsiveness and visual stability. The current recommended “good” thresholds are Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less, assessed at the 75th percentile of page loads. (web.dev: Web Vitals)

Accessibility also extends across content, design, forms, navigation and implementation. WCAG 2.2 adds criteria covering areas such as visible focus, target size, consistent help, redundant entry and accessible authentication. A quick check can reveal obvious barriers, but W3C cautions that simple checks are not a complete conformance evaluation. (W3C: What’s New in WCAG 2.2; W3C: Easy Checks)

If the same problems appear across most templates and components, repairing them one at a time may leave an inconsistent result. A rebuild can create a clearer opportunity to address shared causes—provided accessibility and performance are written into the requirements and tested throughout the project.

The technology has become an operational risk

A rebuild may be justified when the site depends on unsupported software, fragile customisations, undocumented integrations or access arrangements that the business cannot confidently maintain.

This is not an argument for replacing technology merely because it is old. The relevant questions are whether it is supportable, secure, understandable and fit for the website’s current role.

The cost of preserving the current system exceeds the value

Improvement stops being incremental when every change requires another exception. Estimate the effort to repair the current foundation, the likely remaining limitations and the cost of maintaining those limitations. Compare that with a staged rebuild that preserves useful content, URLs and data.

The estimate will be imperfect, but it makes the trade-off visible.

Use five questions to make the decision

1. What business job must the website perform in the next 12 to 24 months?

Name the priority outcome in operational terms: explain a more complex offer, support enquiries from a new market, sell products online, qualify project requests or make content easier to publish. Avoid using “modernise the website” as the goal.

2. Which current journeys work, and which fail?

Review the site from the audience’s perspective. Can visitors understand the offer, verify relevant evidence, navigate on mobile, complete important tasks and contact the business? Combine analytics and search data with form tests, content review, stakeholder interviews and direct observation where available.

Low traffic is not proof that a page is poor, and a high-traffic page is not automatically effective. Use several kinds of evidence and preserve uncertainty when the sample is small.

3. Are the problems local or shared across the system?

Local problems point towards focused improvement. Shared failures across navigation, templates, data structures, accessibility, performance and publishing workflows point towards a more foundational change.

4. What must be preserved?

List useful pages, search visibility, backlinks, analytics history, enquiry data, legal content, integrations, domain settings and internal workflows. A rebuild should not erase value simply to achieve a clean visual reset.

If URLs change, migration work becomes especially important. Google recommends preparing an old-to-new URL map, using server-side permanent redirects where possible, updating internal links and canonicals, submitting sitemaps and monitoring the move. It also advises separating major changes when practical instead of changing the domain, content management system and layout all at once. (Google Search Central: site moves with URL changes)

5. Can the change be released and tested in stages?

Even when rebuilding is appropriate, the project does not need to become one uncontrolled launch. A business may first clarify content, validate a new structure, prototype priority journeys and test templates before migrating the full site.

Staging reduces uncertainty and creates decision points. It also helps the team distinguish must-have foundations from features that can wait.

Compare the options with a simple scorecard

Use evidence and notes rather than pretending the decision can be reduced to one universal score.

The scorecard is a discussion tool, not a procurement formula. One severe security, compliance or operational constraint may outweigh several cosmetic advantages of keeping the current site.

Define the smallest responsible scope

Once the direction is chosen, write a brief that includes:

• the audience and business job;
• priority journeys and content;
• evidence behind the decision;
• what will stay, change and be removed;
• performance, accessibility and privacy requirements;
• URL, analytics and integration migration needs;
• content ownership and approval responsibilities;
• testing, rollback and post-launch monitoring;
• a clear list of later-phase ideas.

This turns “improve or rebuild?” into a scoped business decision rather than a design preference.

If the business first needs to clarify whether it needs a broad website, an online store or a focused campaign destination, read Brand Website, Ecommerce Store or Landing Page: What Does Your Business Actually Need?.

Start with diagnosis, not demolition

An existing website contains more than visual design. It carries content, search history, integrations, customer habits and internal operating knowledge. That value should be assessed before anything is replaced.

The practical choice is to improve when the foundation still supports the business and to rebuild when the foundation has become the constraint. In both cases, begin with the audience, the job, the evidence and the smallest responsible scope.

If you are deciding whether to repair, extend or replace a business website, discuss the requirement with Agent Infinite Biz. We can review the current site, intended audience and operational constraints before recommending an appropriate scope.