01
Look for business and customer signals
A redesign may be justified when customers cannot understand the offer, key services have no usable page, mobile enquiries fail, staff cannot update essential information or the brand and organisation have changed substantially. Security, accessibility and unsupported-platform risks can also make continued patching unreasonable.
Use evidence from customer questions, form failures, search data, support requests, performance tests and content ownership. A dip in one monthly metric or a competitor’s new look is not enough. First confirm whether the problem is the website, the offer, demand or the process after an enquiry.
- The business model or priority audience has changed
- Important journeys repeatedly fail
- The platform blocks safe maintenance
- Content has become duplicated and unowned
02
Choose focused fixes, redesign or rebuild deliberately
Focused improvement is suitable when the underlying platform and content model are sound: rewrite a service, simplify navigation, repair forms or optimise media. A visual redesign changes presentation and components. A rebuild replaces significant architecture or technology and carries greater migration risk.
Audit the current site before deciding. Estimate the cost of correcting shared templates and technical debt versus moving content and integrations. A common mistake is calling every project a redesign, then discovering midway that accounts, data and business workflows require a full application rebuild.
03
Preserve evidence, content and search value
Inventory every useful URL, page purpose, backlink, asset, form, integration and analytics event. Decide what to keep, improve, combine or remove. Map old URLs to the closest useful replacements and retain a baseline of traffic, rankings, conversions, performance and accessibility evidence.
Do not copy weak content automatically, but do not delete valuable pages because they do not fit the first mock-up. Plan domain, DNS, email, analytics, consent, structured data and third-party changes. Freeze unnecessary publishing before migration so the inventory stays accurate.
04
Treat launch as a controlled transition
Test redirects, canonicals, metadata, sitemaps, forms, integrations, keyboard journeys, browsers, mobile layouts and performance before release. Prepare rollback and provider contacts. Launch when the team can monitor, not immediately before a holiday or critical campaign.
Compare outcomes with the recorded baseline and allow for search recrawling and customer adaptation. Fix defects quickly, but avoid changing titles, navigation and calls to action simultaneously every few days. A redesign is successful when it solves the agreed problems and remains maintainable.
Practical next steps
Checklist
- 01Record the business problem and affected journeys
- 02Collect customer, analytics and technical evidence
- 03Decide whether focused fixes could solve it
- 04Inventory URLs, content, links and integrations
- 05Set measurable acceptance criteria
- 06Map redirects and canonical destinations
- 07Test accessibility, mobile and performance
- 08Prepare rollback, monitoring and provider contacts
- 09Compare post-launch evidence with the baseline
Common questions
Questions and answers
How often should a website be redesigned?
There is no fixed interval. Redesign when evidence shows that the current structure, technology or presentation no longer supports important needs.
Will a redesign harm SEO?
It can if useful content, URLs, internal links or technical signals are lost. A controlled inventory, redirect map and post-launch monitoring reduce that risk but cannot guarantee unchanged rankings.
Can I redesign without changing platforms?
Yes, when the platform remains supported and its content, performance and accessibility constraints are manageable.
Should all old content move to the new site?
No. Keep or improve content with a real purpose, consolidate overlap and remove material that is obsolete, unsupported or unsafe, using suitable redirects where a replacement exists.
Need a considered recommendation?
Discuss the website, not just the symptom.
AHANIX reviews each requirement manually. Technical recommendations may depend on access to the website, hosting or DNS configuration.
Continue learning