Before redesigning, record the business goal, top user journeys, current traffic and conversion baseline. Audit every URL and integration; decide what stays, changes or retires; build the new content and design system; test accessibility, responsiveness, forms, analytics and performance on staging; map every changed URL to a redirect; and keep a rollback copy while monitoring the live launch.
Reviewed for material changes on August 13, 2026
Write a brief that can prove success
Replace ‘make it modern’ with a short list of observable outcomes: more qualified demo requests, fewer support questions, faster publishing, clearer positioning or better mobile completion. Pick a baseline measure for each one before the old site changes.
Name the audiences and their first important job. A buyer comparing plans, a candidate checking culture and an existing customer looking for help should not all be sent through the same generic story.
- Record current traffic, conversion and form-completion baselines.
- List the top three customer journeys and their owners.
- Agree what is explicitly out of scope.
- Set launch criteria and decide who can stop the release.
Audit content and URLs before drawing pages
Export the current sitemap and combine it with analytics, search data and stakeholder knowledge. Mark each URL keep, improve, merge or remove. Preserve addresses that already work unless a structural change earns its migration cost.
Write content in the new hierarchy before final visual polish. Navigation labels, headings and calls to action shape the design. Lorem ipsum makes weak information architecture look temporarily tidy.
Design the repeated decisions once
Set foundations for type, colour, spacing, containers, imagery, controls and states. Build representative components with awkward real content: a long title, no image, a validation error, six navigation items and a testimonial twice the expected length.
Review the system at narrow and wide widths as it develops. Accessibility belongs inside those decisions. Use semantic elements, visible keyboard focus, adequate contrast, clear labels and input errors that explain how to recover; W3C recommends targeting the latest WCAG version.
Treat performance, search and integrations as product work
Budget image weight, fonts and third-party scripts instead of trying to optimise them after sign-off. Google's current Core Web Vitals cover loading, interaction and visual stability, and real-user data is the meaningful measure once the redesigned site has traffic.
Create unique titles and descriptions, retain canonicals, regenerate structured data where it is accurate and confirm crawl rules. Test CRM delivery, email notifications, payments, booking, search, consent and analytics with production-like accounts—not mocked success screens.
Launch with redirects, monitoring and a way back
Every intentionally changed URL needs a relevant destination, not a blanket redirect to the homepage. Update internal links and the sitemap, check that staging blocks are gone from production, and crawl the final build for broken links and missing metadata.
Google's site-move guidance recommends testing redirects and monitoring the move. Keep the old deployment recoverable, assign launch-day owners for forms, revenue, errors and search, and review the agreed success measures after enough data has accumulated to mean something.
Sources and checks
Product limits and prices came from the companies themselves:
- Google Search Central: site moves with URL changes
- Google Search Central: SEO Starter Guide
- Google web.dev: Web Vitals
- W3C Web Accessibility Initiative: WCAG overview
Plans move. We date every check so you know when to verify again.