Should you repair, refresh or rebuild your website?

When a targeted repair is a good starting point

A repair is worth considering when a site still serves its main purpose but a particular behavior has failed. Examples include an inquiry form that shows an error, a menu that cannot be opened on a phone or a page where content overlaps.

Record the exact URL, the steps that trigger the issue, the expected result and what actually happened. Add the browser or device and when the issue began. A repeatable description is more useful than “the website is broken.” The investigation still needs to determine whether the cause is local to the site or depends on another service.

• The problem can be demonstrated with specific steps
• Most other pages and customer workflows still work
• The current platform and source are available to assess

When modernization may be enough

A refresh can suit a site with useful content and working features but inconsistent layouts, difficult navigation or an awkward mobile experience. The aim is to improve how the site works for people while retaining the parts that already do their job.

List the areas that feel difficult and connect each to a visitor task. “The service links are hard to find on a phone” is a stronger brief than “make it modern.” Typography, spacing and visual polish can support that goal, but the navigation and content decisions matter too.

• The business and page structure are broadly unchanged
• Useful content can be preserved or edited
• The main issues involve usability, presentation or maintainability

When to assess a broader rebuild

A rebuild may be worth assessing when the platform cannot support essential work, the site structure no longer fits the business or a series of connected problems makes isolated changes impractical. Those are reasons to investigate, not automatic proof that replacement is necessary.

Compare the proposed work with a smaller alternative. What would a repair leave unresolved? Which requirements cannot be met through a phased refresh? A useful proposal explains those trade-offs and names the content, integrations and operational dependencies involved.

Protect the parts customers already use

Before a significant change, inventory important URLs, downloads, forms and external connections. Include pages that are not linked from the main menu but may still be in bookmarks, emails or printed materials. Keep the source and a usable backup available for rollback planning.

If URLs change, map old pages to the relevant new pages and plan the redirects and link updates. Avoid treating every old address as interchangeable with the homepage. Google’s site-move guidance describes the technical checks needed when URL changes are involved.

Further reading: Google Search Central: moving a site with URL changes

Ask for a comparison you can act on

Ask what each option fixes, what it deliberately leaves out and how the finished work will be checked. Include content preparation, migration and handover in the comparison rather than comparing a visual refresh with a fully scoped rebuild as if they were the same job.

There is no universal price or schedule for these choices. Access, code condition, required features and testing all affect the work. Start with the public URL and the most important problem so the next step can be an assessment of the actual site.

• Which visitor task is failing or difficult?
• What will each option preserve, change and leave unresolved?
• What access or third-party dependencies could block the work?
• What checks and rollback steps belong in the project plan?