A redesign is a chance to remove friction, not just replace the visual layer. Protect what already works, understand the content and decide how success will be evaluated.
Define the reason for change
Write down the business, user and operating problems the redesign should solve. Separate visual preference from content, navigation, platform, performance and maintenance problems.
Record the current evidence
Collect analytics, search performance, enquiry quality, customer questions and internal feedback. Record current URLs so valuable content is not lost during migration.
- Business goals
- Primary audiences
- Content inventory
- Search Console exports
- Analytics baseline
- Technical constraints
- Integration inventory
Decide what to keep
Mark content and functionality to keep, improve, merge, replace or remove. High-performing pages should not disappear because they do not fit the first visual concept.
Design with real content
Use realistic headlines, images, tables, forms and long content early. Test the main journeys on small screens, with a keyboard and at different content lengths before the visual system is considered final.
Protect the migration
Create a one-to-one redirect map for changed URLs. Validate canonicals, indexation, internal links, structured data, forms and analytics in the deployed environment before switching the domain.
- URL map
- Redirect tests
- Metadata and canonicals
- Sitemap and robots
- Forms and integrations
- Analytics and consent
- Rollback owner
Review after launch
Check crawling, indexing, errors, enquiries and real-user performance after release. A launch is the start of observation, not proof that every outcome is complete.