Look beyond visual age
A site can look dated and still serve users well; another can look current while hiding serious content and technical friction. The reason to redesign should be connected to real limitations.
The offer is difficult to understand
If teams repeatedly explain what the website should make clear, information hierarchy or content may no longer match the business.
Key tasks have become awkward
Navigation, forms or product discovery may have accumulated patches that make common journeys unnecessarily long.
Operational strain is a valid signal
A site that is difficult to update, test or extend creates recurring cost even when visitors cannot see the underlying problem.
Content ownership is unclear
Duplicated pages and inconsistent claims often indicate that the model needs restructuring, not another layer of styling.
Small changes feel risky
Fragile dependencies and undocumented templates can turn routine updates into release concerns.
Choose the right degree of change
A redesign does not have to mean replacing everything. An audit can distinguish content edits, interface improvements, structural migration and complete rebuild work.
Preserve what has evidence
Retain useful content, recognised routes and proven workflows when they continue to serve people.
Sequence the work
When risk or budget requires it, use a phased plan with clear boundaries and a coherent target system.
Audit evidence before choosing a solution
Start with what can be observed: content gaps, search queries, support questions, form behaviour, accessibility barriers, performance traces and editorial pain. Evidence does not need to be perfect to be useful, but its limits should be stated. The aim is to distinguish a measurable problem from a preference for a newer visual style.
Review pages by purpose
For each important template, ask who it serves, which question it answers, what action it supports and who owns it. Mark duplicated, outdated, unsupported and missing content rather than moving every old page into a new shell.
Observe critical tasks directly
Walk through navigation, search, enquiry, account or purchase journeys at several widths and with a keyboard. Record where the interface becomes unclear, loses state or requires an explanation outside the site.
Plan migration as product work
Redesigns often fail at the boundary between the old and new systems. URLs, content fields, media, forms, analytics and integrations need an explicit migration plan. Treat the move as a sequence of testable transformations, with owners and rollback decisions, rather than a last-minute copy task before launch.
Create a content disposition
Decide whether each important item will be kept, revised, combined, archived or removed. Map retained public URLs to their new destinations and review internal links so useful paths do not end at an avoidable error page.
Protect operational continuity
Confirm how enquiries, consent records, tracking, feeds and third-party connections behave during the transition. Rehearse the launch steps, define who can pause the release and keep a recoverable snapshot of the outgoing state.
Define success without inventing certainty
A redesign should have testable launch goals and a plan for learning afterward. Separate checks the team can complete before release from business outcomes that require time and external conditions. This prevents a visual change from being reported as growth and helps later decisions use evidence rather than memory.
Set release quality criteria
Agree on content approval, supported journeys, responsive behaviour, accessibility checks, metadata, redirects and performance guardrails. Record the devices, browsers and templates actually inspected so validation boundaries remain honest.
Plan a post-launch review
After the site has operated under normal conditions, review technical issues, search visibility, content questions and journey signals that are genuinely available. Compare them with a documented baseline and decide which follow-up work is justified.
Questions readers ask
Sometimes. Keep it when it can support the required content model, publishing workflow, integrations and delivery quality without fragile workarounds. Test those conditions before choosing either continuity or migration for purely stylistic reasons.
No. Review each page’s purpose, accuracy, use and ownership. Keep or improve material that still helps people, combine unnecessary duplication, and remove or archive content that no longer has a valid role while providing appropriate redirects.
Yes, when each phase has a coherent boundary and the target system is understood. Prioritise high-risk or high-value journeys, avoid running contradictory patterns indefinitely, and make temporary states explicit to editors and visitors.
Audit the problem first. If accurate content, sound structure and maintainable technology already exist, focused visual or usability changes may be sufficient. If the content model, journeys or platform block known needs, a surface refresh will leave the underlying constraint in place.