A redesign succeeds when the new site improves the business without silently discarding what already worked. The visual layer is only one part of the release.
1. Define the business problem
“The site looks old” is an observation, not an outcome. Name the real constraint: visitors cannot understand the offer, the team cannot maintain content, mobile conversion is weak, or the platform blocks required work. Record the baseline: important landing pages, search visibility, qualified conversions, working forms, performance, and known complaints.
2. Inventory the current site
List every public URL, title, canonical, status code, internal link, asset, form, tracking tag, and integration. Mark each keep, improve, merge, redirect, or retire. Save screenshots at desktop, tablet, and mobile widths; they capture behavior a crawler misses.
3. Protect URLs and content
Keep a one-to-one URL map. When a useful URL changes, use the most relevant destination and a permanent server-side redirect—not the homepage by default. Update internal links, canonicals, navigation, sitemaps, and campaign destinations. Google’s site-move guidance recommends mapping, testing, and monitoring these changes.
For every page ask who it serves, what decision it supports, what proof exists, and what happens next. A redesign does not authorize invented statistics, testimonials, locations, or outcomes.
4. Test the experience
Test real viewport widths, keyboard navigation, visible focus, zoom, reflow, and reduced motion. Check headings, labels, alternative text, contrast, dialogs, and errors against the WCAG quick reference. Measure representative templates with current Core Web Vitals.
5. Prepare launch and rollback
Require a restorable backup, reproducible build, deploy manifest, crawl and link check, safe form tests, analytics verification, and named rollback trigger. After launch, verify live status codes, canonicals, redirects, sitemap, assets, console errors, and conversion events. Preserve the useful system before improving its appearance.
