Website age is easy to measure, so it often gets used as a shortcut. It is not a diagnosis. An older site that is maintainable, secure, usable, and capable of supporting the business may need focused work rather than replacement. A newer site with a fragile foundation may need deeper intervention.
Start with maintainability
Ask whether a qualified team can safely update the site. A maintainable site has understandable code or configuration, current dependencies, reliable deployment and backups, and access to the accounts needed to operate it. If routine changes repeatedly break unrelated features, the underlying structure deserves investigation.
Check the experience on mobile
Review real pages and tasks on narrow screens. Can visitors read the content, use navigation, complete forms, and reach key actions without zooming or fighting the layout? Mobile problems can sometimes be repaired template by template. They support a rebuild only when the layout system itself makes consistent repair impractical.
Measure performance in context
Look at field data and representative pages rather than one score from one test. Large images, third-party scripts, hosting configuration, and accumulated plugins may be repairable. A rebuild becomes more reasonable when the platform or architecture prevents meaningful improvement.
Can the business update what it owns?
A site that requires a developer for every text change may be a poor fit even if it looks current. The decision is not automatically to rebuild: a better editing workflow, component cleanup, or a targeted content-system change may solve the operational problem.
Does the architecture support what comes next?
New requirements can expose a real mismatch. Portals, complex integrations, multilingual content, membership workflows, or a substantially different information architecture may exceed what the current system was designed to handle. Compare the cost and risk of extending it with the cost and risk of replacement.
Are accessibility and security issues structural or repairable?
Individual WCAG findings, outdated packages, and configuration problems can often be remediated. A rebuild is more defensible when inaccessible interaction patterns are repeated throughout the product, unsupported software cannot be upgraded safely, or the system makes reliable testing and deployment impossible.
Compare targeted work with replacement
Estimate the work required to reach the next useful state. If targeted improvements preserve healthy parts of the site and cost materially less than replacement, updating may be the responsible choice. If repairs would reproduce most of a rebuild while retaining the same constraints, replacement may be clearer.
A takeover doesn't automatically mean a rebuild
If a client brings Bright Bridge an existing website, the first job is to understand what is healthy, what needs repair, and what can stay. A rebuild should be justified by the condition of the site—not used as the default sales answer.
The useful question is not “How old is this website?” It is “Can this website support the business safely and maintainably from here?”
