A redesign is a business change with a design component. Start by identifying what the current website prevents people from doing, then decide whether the problem needs new content, a technical repair, a focused refresh or a full rebuild. A new visual treatment alone does not create better commercial results.
Key takeaways
- Use analytics, search data, support requests and staff interviews to define the problem.
- Keep useful URLs, content and journeys unless evidence supports changing them.
- Agree measurable launch checks, named owners and a post-launch review before work begins.
Diagnose before choosing a solution
Build a baseline from available evidence. Review enquiries and sales, Search Console queries and landing pages, analytics events, site search, support requests and recurring staff workarounds. Speak with people who use the site and the teams that maintain it. Separate observed problems from assumptions.
Then choose the smallest intervention that solves the problem. A confusing service page may need clearer content. A broken enquiry flow may need a repair. A site with unsupported software, unmanageable content or structural limitations may need a rebuild. Record what must remain, what can change and what is outside the project.
Plan the information and technical structure
Map audiences to their tasks, pages and next steps. Confirm the content owner, approval process, language needs and accessibility requirements. Review the current URL inventory, indexation, inbound links and organic landing-page performance before changing the structure.
If a URL must change, map the old address to its closest replacement and set a direct permanent redirect. Update internal links, canonical tags and the sitemap. Do not send unrelated retired pages to the home page. Google’s site-move guidance recommends testing the destination, preparing URL mappings and monitoring both sets of URLs during a move.
Set acceptance criteria
Write down how the team will know the work is ready. Include critical user journeys, forms and integrations, mobile layouts, accessibility checks, redirects, metadata, analytics events, backup and rollback steps, and content approvals. Set performance targets based on real requirements and measurements, not a promise that every page will reach a perfect lab score.
Define who owns the domain, hosting, code, content, licences and administrator access. State what training, warranty, support and future work are included. Keep the project scope and exclusions in writing.
Launch and review
Test the build in a suitable staging environment. Before launch, crawl key routes and check status codes, redirects, canonical URLs, forms, analytics and mobile behaviour. After launch, monitor errors, conversions, search visibility and user feedback against the baseline. Investigate material changes rather than assuming the redesign caused every movement.
Google site-move guidance notes that search visibility can fluctuate while moved URLs are crawled and processed. A redesign cannot guarantee rankings, leads or revenue.
Common questions
When is a full redesign justified?
When evidence shows the current information architecture, technology or operating model prevents important tasks and smaller repairs will not address the cause.
What should a redesign proposal include?
Deliverables, exclusions, content responsibilities, migration approach, acceptance checks, ownership, launch support and how changes outside scope are handled.
Who should own the website accounts and assets?
The organisation should retain administrative control of its domain and essential accounts, with access granted to suppliers as needed. Document ownership and recovery access before work starts.
Sources and review notes
Reviewed 20 October 2026. Guidance on URL changes follows Google Search Central’s site-move documentation. No conversion, revenue or ranking outcome is promised.