Website redesign or rebuild? Diagnose the problem first

A website that looks dated does not automatically need a new technical platform. Equally, fresh typography will not repair a broken checkout or an inaccessible content workflow. The useful first decision is what is failing, not which replacement stack to buy. ## Describe a failed task, not a mood Choose an important visitor task: finding a service, comparing products, booking an appointment or sending a request. Walk through it with realistic content on a phone and a larger screen. Note the precise point where the path becomes unclear or stops working. “The site feels old” is a starting opinion; “the enquiry form loses the entered phone number after an error” is a problem someone can investigate. Look at support messages and available analytics alongside this walkthrough. A low conversion rate does not prove that the layout caused it. Traffic quality, offer, price, technical errors and measurement can all affect the number. Record an initial hypothesis and decide how it will be checked.

## When a redesign may be enough If the platform can support the required content and interactions, the work may centre on information architecture, page hierarchy, responsive components and clearer copy. This can still be substantial design work. It simply means the evidence has not yet established a need to replace the underlying system. Test the critical flow before drawing every page. A small prototype can expose missing steps and unclear requirements. Agree the required states, including empty results, validation, loading and success, so the implementation is priced against actual behaviour. ## When to investigate a rebuild A rebuild deserves technical assessment when the current system cannot support essential requirements, is unmaintainable by the responsible team, or prevents necessary security and operational updates. Those are questions for the implementation team as well as the designer. Do not infer them from a screenshot. Ask for a written assessment of the current system, the missing capability and the alternatives. Sometimes a focused repair or integration is sufficient. Sometimes replacing the platform is justified. Migration effort, content ownership and ongoing maintenance belong in that comparison.

## Put accessibility into the scope [WebAIM’s February 2026 evaluation](https://webaim.org/projects/million/) examined one million popular home pages with WAVE. The chart shows three common detectable failures. Treat this as a reason to specify and test accessibility, rather than proof that replacing a platform fixes it.

## Treat content and URLs as part of the project Inventory important pages, documents, forms and integrations before deciding what to remove. Keep useful URLs where possible. When URLs must change, plan and verify their mapping. Google's [site move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) explains the search considerations; it does not promise an instant recovery or traffic gain. A new layout also needs realistic content, suitable image dimensions and a clear CMS workflow. A design approved with tiny placeholder paragraphs may fail as soon as the actual service description arrives. ## Set a handoff that can be verified Agree the key templates, breakpoints, interaction states and content responsibilities. Check the live result with a keyboard and on mobile, including the form's error and success paths. The [W3C forms tutorial](https://www.w3.org/WAI/tutorials/forms/) is a practical reference for labels, instructions and feedback. Keep a launch checklist for redirects, forms, analytics, indexability and essential integrations. Check the previous important URLs after launch rather than assuming the migration tool handled them all. ## Make the smaller decision first Start with a focused review of the main visitor task and the system's ability to support it. Then choose redesign, repair or rebuild from the evidence. [Website design](/services/website-design) and [UX design](/services/ux-design) can help define that scope. Development and migration should be explicitly included or separately owned, rather than implied by the word “redesign”.

• website redesign
• website rebuild
• UX audit