A slow page, editing difficulty or search issue does not automatically require a rebuild. Use the review below to decide what can be repaired and what needs a wider redesign.
Check the customer journey
Ask someone unfamiliar with the website to find a service and make an enquiry. Give a realistic task without coaching the route. Record where the person hesitates, which information is missing and whether they understand what happens after submitting a form.
Repeat important tasks on a phone and with the keyboard. Check readable text, visible focus, navigation, labels and error recovery. The goal is evidence of specific friction, not a general judgement that the site feels old.
Audit the existing content and URLs
Create a list of pages, articles and important downloads. Identify material that still attracts useful visits or answers current customer questions. Mark each item to keep, improve, combine or retire. Do not remove useful content simply because it belongs to an older visual design.
If URLs must change, map them to equivalent new destinations. A redirect to an unrelated homepage is rarely a useful replacement for a detailed resource. Google’s site-move guidance explains the search considerations.
Diagnose technical issues separately
Check status codes, robots directives, canonicals, internal links and the sitemap. Measure representative pages and inspect what causes delay. Oversized images or an unnecessary script may be repairable within the current platform.
Review editing access and supported software. Staff may need training or a clearer content model rather than a new system. Conversely, an unsupported implementation with missing source access can make ongoing repairs impractical. Document the condition before making that decision.
Compare three options against the same task
A repair addresses a defined fault: for example, restoring a broken enquiry route and verifying receipt. A redesign changes structure, presentation or content while potentially retaining the platform. A rebuild replaces a substantial part of the implementation and introduces a wider migration and testing task.
For an illustrative case, a readable site with a failed form may need a repair. A site with clear technology but confusing service information may need a content and layout redesign. A private workflow forced into an unsuitable content tool may need a separate application. These are decision examples rather than automatic prescriptions.
Prepare a launch and rollback checklist
Agree content approval, access, backups, redirect testing, form testing, production indexing and analytics verification. Record who can approve the final switch and who handles an urgent issue. Keep a recoverable previous version until the important tasks have been checked.
Use website redesign planning to discuss the options. A brief should include the current URL, the observed problem and what a useful improvement would look like. That gives the recommendation a purpose beyond replacing the site’s appearance.
