What problem are you actually trying to fix?
The first problem is usually not that a website looks old. It is that a visitor cannot find an answer, a team cannot update a page, or an important handoff breaks between the site and the business process.
Write down the moment that is failing. A useful description names the person, the task and the point where progress stops. “People do not understand what we do” leads to a different project than “the editor cannot publish a new service page.”
This distinction also keeps a visual refresh from hiding an information problem. A cleaner surface can still send people through the same confusing path.
When is a rebuild justified?
A rebuild is justified when the current foundation blocks the outcome. Common signals include an unmaintainable content model, a rendering setup that cannot meet performance needs, broken ownership of key pages, or a navigation structure that no longer matches the business.
The case should be visible in more than one layer. A slow template alone may need a technical fix. A slow template plus unclear content ownership and brittle integrations may point to a new foundation.
- The content model prevents the team from keeping important information current.
- The site cannot support a necessary journey without workarounds or duplicate pages.
- Core templates create a repeated accessibility, search or performance problem.
What should stay if it works?
Keep anything that already helps people complete the task: useful content, stable URLs, clear terminology, working integrations and page patterns that the team can maintain. A rebuild should preserve earned clarity while replacing the parts that create friction.
Before moving a page, make a simple inventory of its URL, purpose, owner and incoming links. This turns a redesign into a controlled transition instead of a clean slate that quietly loses useful context.
How should the decision be tested?
Test the proposed change against a small set of real tasks before committing to a full rebuild. Watch whether people find the right page, whether the team can edit it and whether the system stays understandable when the next request arrives.
A short content and technical audit is often enough to choose a direction. The output should be a ranked list of problems, the evidence behind each one and a clear reason for rebuilding or improving.