In short
Plan a website redesign by recording the current baseline, inventorying URLs and content, observing priority user journeys, mapping business and technical constraints, and deciding what to keep, improve, merge, redirect, or replace. Turn the evidence into outcomes, scope priorities, responsibilities, acceptance criteria, and a controlled launch plan.
1. Write the reason for change
State what the current site prevents and why the project matters now. “Modernise the website” is not enough. Name the affected audience, task, business consequence, and evidence.
2. Capture the baseline
Before changing anything, record:
- organic clicks, impressions, queries, and landing pages;
- conversions and lead quality;
- priority journey completion;
- content publishing time and pain points;
- Core Web Vitals and accessibility defects;
- support and sales questions;
- current technology, integrations, and ownership;
- maintenance incidents and costs.
The baseline protects useful parts and makes the result assessable.
3. Inventory URLs and content
Combine sitemap, crawl, CMS, analytics, Search Console, backlink, and campaign data. Give every URL an outcome:
- keep;
- improve;
- merge;
- redirect;
- remove intentionally.
Record audience, intent, evidence, performance, owner, and proposed destination. This becomes the content plan and migration map.
4. Observe priority journeys
Use analytics, interviews, support themes, and usability sessions to understand where people hesitate or fail. Test representative tasks, not general reactions to the homepage.
Separate symptoms from causes. A low form completion rate may reflect an irrelevant landing page, weak offer, technical error, excessive fields, or poor mobile behaviour.
5. Audit the system in layers
| Layer | Questions |
|---|---|
| Positioning | Does the site explain the current offer and difference? |
| Content | Is information accurate, useful, evidenced, and owned? |
| Architecture | Can users and crawlers understand relationships? |
| Interface | Are hierarchy, interaction, and states clear and accessible? |
| CMS | Can editors publish safely and efficiently? |
| Technology | Is the system fast, secure, maintainable, and observable? |
| Operations | Are ownership, monitoring, support, and recovery clear? |
Replace only the layers whose problems justify it.
6. Define outcomes and non-objectives
Choose three to five outcomes tied to the evidence. Then list adjacent work the redesign will not solve, such as a full rebrand, CRM replacement, customer portal, or ongoing content programme.
Non-objectives prevent every organisational frustration from entering one project.
7. Prioritise the first release
Use:
- must launch: priority journey or obligation fails without it;
- valuable next: understood and useful, but safe to follow;
- validate first: the need may be real; the solution is unproven.
Create the smallest complete release, not a visibly incomplete one.
8. Assign ownership and decisions
Name the decision-maker, project lead, content owner, technical owner, specialist reviewers, and approval turnaround. Decide how feedback is consolidated and how disagreements are resolved.
9. Plan migration before design finishes
Preserve valuable URLs where possible. Build one-to-one permanent redirects for changed URLs, update internal links, validate canonicals and metadata, and prepare the final sitemap.
See how to redesign without losing SEO for the complete migration sequence once published.
10. Define acceptance and monitoring
Specify testable expectations for journeys, responsive behaviour, accessibility, performance, CMS, integrations, analytics, redirects, and recovery.
Launch monitoring should include errors, forms, search indexing, Core Web Vitals, and business actions. Redesign ends when the production system stabilises, not when the domain points to it.
Common questions
What should be audited before a redesign?
Audit business fit, user journeys, content, URLs, search performance, accessibility, performance, CMS workflow, integrations, technology, ownership, and maintenance.
Who should be involved in redesign planning?
Include the accountable decision-maker plus people responsible for customers, content, design, engineering, search, operations, legal, or security where those concerns apply.
Should we keep the existing sitemap?
Treat it as evidence, not a constraint. Preserve valuable URLs where possible while changing navigation and relationships when user and business needs justify it.
How do we prevent personal taste from controlling design?
Agree on audiences, tasks, content, principles, constraints, and acceptance evidence before reviewing polished screens. Ask which objective a preference supports.
When should we choose the technology?
After content, functional, integration, security, editorial, and operating requirements are understood. Technology is a response to constraints, not the starting brief.
