Preserve, improve or rebuild a website: how to decide

Does your website need renewing, or can you make use of what you already have? Learn to evaluate its value, identify the real problems and decide what to preserve, what to improve and when rebuilding is justified.

Your company has had a website for years.

At the time, it represented a significant investment. It was designed, its content was developed and it became part of business activity.

Since then, many things have probably changed.

Perhaps you have added services, customers search for different information or you need functions that did not exist before.

The design may no longer represent your company properly.

Or the problems may be technical: the website is slow, difficult to update, uses old tools or every modification seems more complicated than the last.

An inevitable question then arises:

Is it worth improving the website we have, or is it time to build a new one?

The answer is not always obvious.

An old website may retain valuable content, well-ranked pages and processes that work properly.

A visually modern website, meanwhile, may rely on technologies that are difficult to maintain or have problems invisible at first glance.

Nor should we assume rebuilding will automatically solve every difficulty.

We could spend considerable money and discover we still fail to explain our value proposition or respond properly to customer requests.

But clinging to a foundation that no longer works is no solution either.

We may accumulate repairs, incompatibilities and maintenance costs that make every improvement harder.

The decision needs more than an opinion about design.

We need to understand what value our website retains, what limits its usefulness and which intervention makes most sense for the business’s future.

That is this guide’s purpose.

Not to help you justify a new website.

But to provide criteria for deciding whether to preserve the current one, improve it in parts or rebuild what really needs to change.

1. Before changing your website, understand what you have

When a company decides to renew its website, the conversation often starts with what it wants to modify.

The design, colours, photographs, menu or functionality.

These are legitimate matters.

But first we should ask another question:

What would we lose if we replaced this website tomorrow without first investigating what deserves preservation?

An existing website is more than files and pages.

It can represent years of knowledge, digital presence, commercial relationships and business decisions.

Some contributions are visible.

Others less so. In the guide to websites as digital assets, we explain how this value is created and preserved; here we focus on deciding which intervention it needs.

Value may lie where we least expect it

Imagine your company has a service page published six years ago.

Its design is dated and photographs need renewing.

Yet that page appears for relevant searches and receives visits from people interested in your offering.

It may also have links from local media, associations or partner companies.

Removing it without studying its purpose could affect visibility the business has built.

Now consider a website with a rarely updated blog.

At first glance, it may seem dispensable.

But it may contain articles answering common customer questions or explanations the sales team regularly shares.

That content can still provide value even if it needs review.

We should also consider less obvious elements: a form properly connected to a commercial process, a structure familiar to customers, a working integration or historical information that helps us understand demand.

Not everything deserves preservation.

But we should not discard something simply because it belongs to a previous version.

Inventory before intervention

The first step is identifying what exists and its function.

We should recognise working content and processes, relationships that have accumulated value, current difficulties and capabilities we need to develop.

We need not begin with an endless inventory.

We need a sufficiently complete view to avoid losing important information.

For SEO, for example, Google Search Console shows which pages and searches generate impressions and clicks from Google. It also provides indexing information and possible discovery problems. [1]

These data are useful, but do not by themselves reflect a page’s commercial profitability.

We must complement them with business knowledge, commercial data and customer needs.

Before deciding what to replace, we must recognise what deserves to survive.

2. Do not confuse symptoms with causes

One common mistake is recommending a solution based on superficial observation.

“The website is slow. We need to rebuild it.”

“We receive few requests. We have to change the design.”

“The page looks old. We need new technology.”

These statements may lead to correct decisions.

But they do not yet contain a diagnosis.

They describe symptoms or propose solutions.

They do not necessarily explain what causes the problem.

A slow website does not always need rebuilding

Slowness can have different origins.

Images may be too heavy.

Hosting may be configured inadequately.

Some extensions may load unnecessary resources.

Or the site’s technology and dependencies may have deeper limitations.

In the first cases, relatively local solutions may exist.

In the last, we may need to study a structural intervention.

The symptom is similar.

The response is not.

Core Web Vitals help observe specific experience aspects through three indicators: LCP, related to loading; INP, to interaction responsiveness; and CLS, to visual stability. [2]

But these indicators help investigate difficulties; they do not automatically determine that a website should be rebuilt.

Few requests do not necessarily mean poor website design

Imagine a page receives visits but generates few business enquiries.

We might suspect its visual presentation is insufficiently attractive.

Yet visitors may not be the right customers.

The value proposition may be unclear.

The form may have a technical error.

Or the offering may simply not address what those people need.

Each situation requires a different intervention.

Rebuilding without identifying the cause could leave us with the same problem and a new design.

Outdated design does not prove the technology is exhausted

A website may need a substantial visual renewal while having a perfectly valid technical foundation.

We can improve typography, components, mobile experience and service presentation without necessarily replacing the whole system.

The opposite can also occur.

A visually impeccable website may use incompatible components, accumulate hard-to-maintain dependencies or present significant risks.

We should therefore distinguish three concepts.

Redesigning means modifying all or part of the visual presentation and user experience.

Improving means correcting, optimising or extending particular site elements.

Rebuilding means replacing a substantial part of the website’s foundation, whether technology, architecture, functionality or a combination.

These interventions can be combined.

We can redesign without rebuilding. We can improve technology while preserving design. We can rebuild a system while reusing content, URLs and visual identity.

The question is not which intervention looks most attractive. It is which resolves the causes identified.

An exception: critical incidents

Not every problem can wait until a strategic evaluation is finished.

If there is an active intrusion, an exploited vulnerability or exposed sensitive information, the priority is containing risk and taking appropriate response measures.

We can then investigate causes and decide whether to repair, recover or rebuild.

The OWASP Application Security Verification Standard (ASVS) provides requirements to guide verification of web application security controls. Stable version 5.0.0 is a technical reference, although it does not replace a system-specific assessment. [3]

A security incident does not by itself demonstrate that the entire website needs replacement.

But neither should we minimise critical risk while debating improvement versus rebuilding.

3. Eight areas for evaluating an existing website

A website may be in good condition from one perspective while presenting important limitations from another.

For example, it may work technically but explain the offering poorly.

It may attract relevant visits but make purchasing difficult.

Or it may fulfil commercial objectives while depending on access and tools the business does not adequately control.

We should therefore evaluate the whole.

Diagnostic matrix for an existing website

Different companies need different depths of investigation.

A simple corporate website may require a relatively compact review.

An online shop or booking platform needs broader analysis of functionality, data, integrations and risks.

What matters is avoiding a decision about the entire website based on an isolated observation.

Future purpose changes the evaluation

Imagine a company whose website was built years ago to present a single service line.

It has worked properly for a long time.

The company now has three commercial lines, operates in several territories and needs to manage different requests.

The website need not be technically broken.

But its structure may no longer represent the business adequately.

In this case, age is not the problem.

It is the gap between what it was designed to do and what we now need it to do.

The reverse can also happen.

A simple website may continue fulfilling its purpose perfectly for many years.

If no new needs justify substantial change, preserving it can be the right decision.

Evaluation is not only about asking whether the website works today. We must also check whether it can reasonably respond to what the business needs next.

4. When to preserve, improve or rebuild a website

Once we understand the situation, we can compare alternatives.

None is superior by definition.

The best depends on future purpose, identified causes and the relationship between value, cost, risk and maintainability.

Preserve: when the website remains suitable

Preserving does not mean abandoning the site or giving up improvement.

It means recognising that its foundation continues to fulfil the required purpose properly.

The design may still represent the company adequately.

Content answers customers’ questions.

Functions work.

Maintenance needs are reasonable.

Under these conditions, rebuilding could consume resources without proportional improvement.

We can continue ordinary tasks: update information, maintain components, check essential functions and correct minor incidents.

But we need not turn every review into a new project.

Preservation can be an active, informed and financially responsible decision.

Improve: when problems can be solved without replacing the foundation

Improvement makes sense when we identify specific difficulties and the existing structure allows safe, sustainable correction.

We may need to rewrite certain pages, improve mobile navigation, optimise images, fix forms, update an integration or replace specific components.

These interventions can have substantial impact without rebuilding the entire website.

But there is a risk to watch.

When improvements start becoming patches

Imagine every new change requires another extension, modifications to several components and checks that no previous function has broken.

Initially, solutions seem inexpensive.

But the system gradually accumulates exceptions.

One tool needs another to work.

An update creates incompatibilities.

Certain operations depend on knowledge nobody documented.

A point arrives when a simple improvement takes too much time or involves risks that are difficult to control.

This does not mean progressive improvements are a bad decision.

It means checking whether they still reduce limitations or increase complexity.

Improvement makes sense while interventions solve problems without making the website increasingly fragile.

Rebuild: when the foundation is no longer suitable

Rebuilding begins to be justified when limitations affect fundamental elements and cannot be resolved proportionately.

For example, architecture that can no longer organise the current offering.

Technology with persistent security or compatibility problems.

A set of dependencies seriously hindering maintenance.

Or a structure preventing important functionality without unstable workarounds.

It may also be justified when the cost and risk of retaining the current foundation are clearly unfavourable compared with a technically viable alternative.

But we must avoid automatic conclusions.

An old website does not need rebuilding simply because it is old.

Nor does missing documentation necessarily require replacement.

We may be able to recover access, review components and document operation.

Before recommending rebuilding, we must check for a reasonable improvement alternative.

When rebuilding is justified, we need to define precisely which part of the foundation must be replaced.

A fourth possibility: intervening in layers

In many projects, the decision does not affect the whole website equally.

We can preserve one part and rebuild another.

For example, retain content and URLs while replacing technology.

Renew design while preserving architecture.

Rebuild a booking system while maintaining the rest of the site.

Or substantially reorganise pages using technical components that still work properly.

We can call this selective rebuilding or recovering existing value.

It is not a compromise chosen to avoid deciding.

It is a more precise definition of what needs to change.

We do not always need to decide whether to preserve or replace the entire website. We can decide what to do with each relevant part of the asset.

5. Practical example: a website with SEO value and a weakening technical foundation

Let us apply the method to a specific business situation.

Imagine a company in the Pyrenees specialising in technical installations for homes and establishments.

Its website was developed in WordPress eight years ago.

Since then, the company has expanded its services and published informative content.

Some articles and commercial pages receive search visits. There are also links from other websites and references used by regular customers.

However, the current template depends on old components and each modification requires complex checks.

The company wants to renew its image, present services better and simplify maintenance.

Its first intention is to remove the previous website and build a completely new one.

But is that the best decision?

This case is hypothetical. The situations, costs and recommendation explain the decision process. They do not represent a diagnosis or actual PhiStudio results.

Step 1. We investigate what deserves preservation

We begin by reviewing existing assets.

Suppose we find content explaining common technical problems and receiving relevant search queries.

We also identify commercial pages with visibility, external links, original photographs of completed projects and knowledge from years of experience.

This suggests indiscriminate removal could destroy existing value.

We do not yet know whether to preserve the technology.

But we already know some information and relationships deserve protection.

Step 2. We identify current difficulties

Then we analyse operation.

These findings are not equally serious.

Content and search visibility represent value.

Design and commercial organisation need improvement.

Technology presents uncertainty requiring investigation.

Step 3. We determine the cause of technical problems

This is where superficial review could lead to a poor decision.

Noticing old plugins is not enough.

We need to check which are actually necessary, whether support exists, their incompatibilities and their operational effects.

We must also investigate whether the template and problematic components can be replaced without destabilising the system.

Imagine tests confirm that several functions depend on old extensions closely linked to the template.

Replacing them requires reworking substantial page content and checking numerous interactions.

Future modifications would also continue depending on hard-to-maintain components.

We now have a more specific structural cause.

We are not saying WordPress is unsuitable.

We are saying this particular installation, with these dependencies, has limitations we must resolve.

Another well-maintained WordPress installation could continue working perfectly.

Step 4. We define what the company needs

The company does not simply need a new website.

It needs three capabilities.

An updated commercial structure able to present its services properly.

A coherent visual and functional experience that explains the offering and receives enquiries.

A maintainable technical foundation with proportionate dependencies, clear access and sufficient documentation.

We also need to protect content and digital relationships that remain valuable.

These objectives allow comparison of alternatives.

Step 5. We evaluate the options

Preservation without significant changes seems insufficient.

The company needs to represent new services and the system has maintenance difficulties.

We could retain the website temporarily while preparing an intervention, but that would not resolve the detected limitations.

Improving the existing installation deserves evaluation.

We could replace components, correct incompatibilities, renew part of the design and reorganise services.

But tests should demonstrate that this is possible at reasonable cost and risk.

If the foundation still depends on fragile components, we may spend significant resources and retain the problem.

Rebuilding the foundation could be appropriate if we can develop a solution that fulfils necessary functions and reduces problematic dependencies.

However, we must consider construction cost, content migration, testing, SEO risks and subsequent maintenance.

Rebuilding should not be justified solely by the promise of more modern technology.

Step 6. We reach a recommendation

Suppose technical and financial evaluation confirms that replacing problematic components in the current installation requires substantial intervention.

We also confirm that many necessary functions can be rebuilt on a simpler, more sustainable foundation.

In that scenario, the recommendation could be:

Rebuild the technical foundation while preserving valuable digital assets

This would mean retaining the domain and relevant URLs where appropriate, reusing useful content, protecting existing SEO relationships and updating architecture to represent new services.

We would also renew the design, replace problematic technical dependencies and prepare a controlled migration.

The conclusion is not that rebuilding is always better.

It is that, in this scenario, selective rebuilding could resolve the structural cause without abandoning accumulated value.

If tests had shown that local, sustainable interventions solved the problems, the recommendation should have differed.

That is precisely the value of diagnosis.

6. How to compare costs, risks and future value

Once alternatives are identified, we need to study their financial viability.

A difficulty often emerges here.

Improving the existing website may initially be much cheaper.

But it may retain dependencies that continue generating costs.

Rebuilding may need a larger investment while providing a simpler foundation for future needs.

Or exactly the opposite may happen.

A rebuild can introduce licences, integrations and maintenance obligations that did not previously exist.

We should therefore compare more than development quotes.

Initial cost does not tell the whole story

We need to know what each alternative includes and what costs may follow.

This comparison must involve proposals pursuing equivalent objectives.

Comparing limited improvement with a rebuild including entirely new functions and concluding that the former is cheaper would make no sense.

First define the result we need.

Then compare different ways to achieve it.

An example of total cost over two years

Let us return to our installations company.

Imagine two fictional cost scenarios expressed in comparative units.

We will use a 24-month horizon.

Units are fictional and used solely to compare decisions; they do not represent euros, quotes or PhiStudio fees. They also exclude internal work and unforeseen incidents. Future costs are estimates, not commitments.

At first glance, improvement seems clearly cheaper.

Initial investment is much lower.

Yet estimated continuity costs reduce the difference.

This does not automatically make rebuilding better.

Future figures contain uncertainty.

We might discover the existing website needs less maintenance than expected.

Or rebuilding may bring unanticipated additional needs.

Such comparisons should therefore use ranges or scenarios where sufficient data are unavailable.

Future value matters too

Cost is not the only criterion.

Imagine the company wants to add a new service line in six months.

If the current website can do so easily, that favours improvement.

If each extension requires complex, risky intervention, we must consider that limitation.

There may also be opportunity cost.

Retaining a foundation that makes an important capability hard to develop can delay needed projects.

But unnecessary rebuilding also has opportunity cost: it consumes resources that could support marketing, operations or other priorities.

We do not need to pretend precision

A professional comparison should not present uncertain estimates as guaranteed outcomes.

We need to distinguish known costs, probable costs and risks that are hard to quantify.

We should also consider possible problems during intervention.

We should therefore assess expected value, investment, dependencies, risks, future capability and maintenance cost together.

The best decision will not necessarily have the lowest quote.

It will offer the most appropriate relationship between the value we need to develop and the resources and risks we assume to achieve it.

7. Rebuilding without losing value: what selective recovery means

When a company decides to rebuild its website, we often hear:

“We are starting from scratch.”

That may be an understandable description of new technical development.

But from a digital asset perspective, it needs qualification.

Rebuilding technology does not mean discarding the knowledge, content and relationships the business has already built.

The aim should be preserving what still adds value and replacing what prevents progress.

What can remain and what can change

For our installations company, we could make decisions such as:

We are not necessarily transferring every element in the same way.

An article may migrate almost unchanged.

A commercial page may need rewriting.

A function may be completely rebuilt to preserve usefulness without retaining old code.

Some content may be retired because it no longer addresses any need.

Selective preservation does not mean everything must survive.

It means each decision is considered.

Preserving URLs deserves particular attention

Imagine a service page has been published at a particular address for years.

If that URL still represents the content properly and fits the new architecture, retaining it may be appropriate.

Changing it solely for aesthetic reasons can introduce unnecessary migration work.

If we must modify it, however, we should study which new address appropriately represents its content.

In many cases, a permanent redirect may be suitable.

Google recommends permanent HTTP redirects, such as 301 or 308, for permanent URL changes where technically possible. It also recommends preparing mappings between old and new addresses. [4]

But we should not assume every redirect automatically protects all previous results.

A migration may cause visibility fluctuations while search engines discover and process changes.

Directing old pages to unrelated destinations can be counterproductive.

Not every removed page should end at the homepage

This is a mistake to avoid.

Imagine we retire a page about a service we no longer offer.

Automatically redirecting it to the homepage may be unhelpful for someone expecting specific information.

Another page may address an equivalent need.

In that case, we can assess a redirect there.

If no appropriate alternative exists and content is permanently retired, the relevant HTTP status for removal, such as 404 or 410, may be correct.

The decision depends on the case.

The aim is not artificially preserving every address.

It is maintaining a coherent relationship between what existed and what we offer afterwards.

Rebuilding also means planning the transition

A rebuild is not finished when new pages are designed and developed.

We need to prepare the move from the previous system.

As far as possible, the transition must protect functions and assets still required.

We can organise it into four moments.

Before launch

We inventory relevant URLs and content.

We check which functions must remain and which data need migration.

We prepare the new structure and page mappings.

We also identify technical and commercial dependencies that may be affected.

A company receiving website requests should not discover after launch that its form stopped sending messages.

Likewise, a company managing bookings through its site must check how necessary processes and data will be retained.

During transition

We verify that the new solution works properly before replacing the previous one.

We check navigation, forms, main functions and relevant settings.

Where appropriate, we implement redirects and update internal links.

We also need to check that pages intended for search engines do not accidentally retain testing-stage blocks.

Google identifies indexing blocks not removed, incorrect redirects and outdated sitemaps among common migration problems. [4]

After launch

Publication does not mean checking can stop.

We need to verify main journeys and correct responses from relevant URLs.

We should also observe possible errors, traffic changes and indexing issues.

Tools such as Search Console help monitor these changes, although interpretation must consider the time search engines need to process the new version. [1][4]

Continuity

Finally, we document the resulting configuration, access, dependencies and maintenance procedures.

The company needs to know which system it now has and who is responsible.

The aim is preventing the new website from repeating the control and documentation difficulties that motivated part of the intervention.

A well-prepared migration does not guarantee exactly preserving every previous result. But it identifies risks, protects relevant assets and supports better-informed responses when problems emerge.

8. Turning diagnosis into an actionable decision

So far, we have recognised existing value, identified causes and compared alternatives.

But we still need to turn that knowledge into an executable decision.

A professional recommendation should not end with a generic statement such as:

“The website should be improved.”

Or:

“We recommend rebuilding.”

It should explain what that decision specifically means.

What an informed recommendation should contain

A professional diagnosis can be organised around nine elements.

Documentation depth depends on the project.

A small intervention may need only a brief recommendation.

A rebuild involving content, integrations and migration needs more detailed analysis.

The aim is not accumulating documentation.

It is having enough information to decide and commission work properly.

An example of a final recommendation

Let us return to our technical installations company.

After diagnosis, the recommendation could read:

Situation: the website retains relevant content and URLs, but technical incompatibilities hinder maintenance and offering updates.

Future purpose: present current service lines properly, enable suitable enquiries and support sustainable technical management.

Alternatives evaluated: improve the existing installation and rebuild the foundation.

Recommended decision: selective technical rebuilding, conditional on validating the new solution’s viability and migration plan.

Assets to protect: relevant content, URLs, original photographs, commercial information and useful internal relationships.

Main work: update commercial architecture, renew design, replace problematic components, migrate content and verify functions.

Risks: SEO fluctuations, migration incidents, loss of certain functions or costs not initially identified.

Acceptance criteria: correct operation of agreed functions, verified migration, checked URLs and redirects, clear responsibilities and delivered documentation.

Limits: any unplanned new service or functionality requires separate assessment and quotation.

This formulation does not replace a complete technical project.

But it explains what we propose and why.

It also facilitates comparison of different providers’ quotes.

And reduces the risk of a general recommendation becoming an ambiguous commission.

An audit can also recommend no intervention

This possibility deserves emphasis.

If diagnosis confirms the website works properly, retains value and can address anticipated needs, a major project may be unnecessary.

We can recommend preserving, maintaining and reviewing it when certain conditions change.

That is also a strategic decision.

A professional evaluation should help decide what the business needs, even when the answer does not involve commissioning a rebuild.

9. The best decision protects existing value and prepares the future

A website does not need to prove it is new.

It needs to serve a business purpose.

Your current website may remain perfectly suitable and deserve preservation.

It may need improvements to explain services better, facilitate enquiries or resolve difficulties.

Or its limitations may be deep enough to justify rebuilding.

There is also the possibility of retaining content, URLs and other valuable parts while replacing the foundation that prevents progress.

None of these decisions is correct by definition.

Their usefulness is determined by the relationship between business needs, existing value and the conditions needed to keep developing it.

We should therefore avoid two opposing impulses.

The first is rebuilding out of frustration, comparison with competitors or simply because several years have passed.

The second is accumulating repairs on a foundation that no longer permits safe, sustainable work.

Both can consume resources unnecessarily.

The alternative is establishing criteria.

Recognise what works.

Investigate what causes difficulties.

Define what the website must do in future.

Compare possible interventions before committing investment.

The best renewal is not necessarily the one that changes the website most. It resolves what really needs changing while protecting value worth preserving.

Sometimes this means small improvements.

At other times, rebuilding a substantial part of the system.

Sometimes the best recommendation is continuing to use the current website.

Directing a digital asset does not mean constant intervention.

It means knowing when intervention is appropriate, how far to go and why.