Website redesign vs repair
An existing website does not need to be rebuilt simply because it is old, ugly, or imperfect. The useful question is whether the current system can support the business and its customers after a focused repair—or whether the structure itself is now the problem.
Preserve · repair · replace · rebuild · investigate · or do nothing yet
Use the smallest intervention that solves the evidenced problem. A good review can conclude that the site should stay exactly where it is for now.
Do not redesign just because the site is old or because someone prefers a different aesthetic. Preserve a working asset and revisit when the business or customer journey actually changes.
Repair the broken mobile path, form, content, navigation, metadata, ownership problem, or other evidenced failure without rebuilding everything around it.
Replace the fragile or poorly fitted foundation with a cleaner site while preserving useful content, URLs, accounts, and business assets where practical.
Rebuild when the structure itself prevents a coherent fix—not merely because the colors, typography, or homepage feel dated.
Gather evidence before choosing a project. A failed form, traffic drop, ownership gap, or slow page can have a narrow cause that does not justify a redesign.
The goal is not to accumulate enough complaints to justify a project. It is to identify whether the failure is narrow, structural, operational, visual, or still uncertain.
Start with the actual jobs the website must support: call, request a quote, understand services, confirm the service area, find hours, book, or contact the business. A dated-looking page that still supports those tasks is a different problem from a polished page with a broken enquiry path.
Repair is favored when one or two specific paths are broken and the rest of the site remains usable.
Replacement is favored when the same confusion repeats across navigation, pages, mobile layouts, and calls to action.
Weak photography, stale copy, poor typography, or an awkward hero can often be changed without rebuilding the underlying site. A site whose page structure no longer matches the business is a deeper problem.
Repair is favored when the existing pages and hierarchy still make sense once the content and presentation are corrected.
Replacement is favored when services, locations, customer groups, or core tasks no longer fit the current information architecture.
A theoretically repairable site may still be a poor repair candidate if routine changes are risky, the platform is unsupported, nobody has the required access, or the implementation depends on brittle workarounds.
Repair is favored when the business controls the accounts and the existing platform can support reliable changes.
Replacement is favored when maintenance itself is the recurring failure and each small change introduces new risk.
A rebuild should not casually throw away useful URLs, content, search visibility, analytics history, forms, domain control, imagery, integrations, or customer habits. Replacement is a migration problem as well as a design problem.
Repair is favored when there is substantial working value already embedded in the current site.
Replacement can still be right when useful assets can be deliberately migrated into a cleaner foundation.
Some businesses have changed enough that the old site no longer represents the work, market, or customer expectation. That can justify deeper design work—but age alone is not evidence.
Repair is favored when the current visual system is credible and only needs focused improvement.
A custom rebuild is favored when the business needs a materially different identity, composition, content system, or interaction model.
A repair stops being economical when every fix depends on another structural fix. At that point the business may be paying replacement-level effort while preserving the liabilities of the old system.
Repair is favored when the problem has a clear boundary and the repaired site will remain maintainable afterward.
Replacement is favored when the repair scope keeps expanding because the underlying system cannot support clean changes.
Webmanship's Website Checkup looks at a deliberately limited set of public evidence: redirects, HTTPS, basic homepage metadata and structure, obvious customer actions, robots, sitemap, and a few response signals.
It cannot decide whether the design is good, the messaging is accurate, or the site deserves a rebuild. That uncertainty is intentional.
Website Rescue when the current site has useful bones and a bounded repair path.
Website Rescue →Website Foundation when a cleaner replacement is more sensible than preserving the current build.
Explore Website Foundation →Custom Website when the business genuinely needs a more bespoke direction or structure.
Explore redesign options →Request a human review when the evidence does not support a clean answer yet.
Request a review →