Start by exporting your baseline metrics and drafting a full redirect map. That single step prevents most of the post-launch traffic loss we see when businesses rebuild their site. From there, work through six phases: plan, audit, build, test, launch and monitor, using Core Web Vitals and WCAG 2.2 as your build standards throughout.
- Export twelve months of landing page sessions, conversions, and bounce rates, plus keyword rankings, before changing the old site; those historical baselines cannot be recreated.
- Keep pages that rank, convert, or serve a clear business purpose; merge overlapping topics, and redirect retired pages to the closest relevant destination.
- Map every legacy URL to a relevant new page with a direct 301 redirect, then test for chains and loops before launch.
- Target LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less at the 75th percentile.
- Monitor traffic, conversions, server errors, and 404s for 72 hours; crawl within a day, check 404s daily for a week, and keep rollback criteria visible.
Table of Contents
- Plan: define goals, scope, timelines, roles and approvals
- Audit current site: export baselines and map risks
- Content inventory and URL mapping: keep, merge or retire
- SEO-safe migration: create and validate a redirect map, preserve tracking
- Design and accessibility: mobile-first, component systems and WCAG 2.2
- Performance: set Core Web Vitals targets and test in lab and field
- Build and QA: continuous testing for functionality, integrations and security
- Pre-launch: staging verification, backups, and launch rehearsals
- Launch day: controlled cutover sequence and immediate smoke tests
- Post-launch monitoring, validation and rollback plan
- Why choose a specialist agency and what to expect from an engagement
- Author perspective: practical rules we never waive
- How TTOY Digital helps: services that map to this checklist
- FAQ
- Sources
Plan: define goals, scope, timelines, roles and approvals
Before anyone touches a wireframe, we sit down and write out what success actually looks like. Not “a nicer website”, but numbers: a target bounce rate, a conversion goal, a Largest Contentful Paint under 2.5 seconds. Without that, every decision later in the project becomes a matter of opinion, and opinions are exactly what derail timelines.
The Gov makes a point that applies well beyond redirects: redesigns that stay tightly aligned to business goals, decided before any design work starts, are far more likely to actually move the needle on conversions. That means your goals come first, your audit comes second, and your visual direction comes last. It feels backwards to a lot of owners who want to jump straight to colours and layouts, but it’s the order that works.
Stage gates matter just as much as goals. A stage gate is simply a point where a named person has to sign off before the project moves forward, and it stops the classic mid-project disaster where someone decides, three weeks before launch, that the whole navigation needs rethinking. Once the sitemap gate closes, the sitemap is done. Once the content inventory gate closes, that’s the content you’re building pages for.
Set these up early:
- A single decision owner for design, one for content and one for technical sign-off.
- Written KPIs tied to traffic, conversions, and performance targets like LCP and CLS.
- A rough timeline with milestones for audit completion, design approval, build, QA and launch.
- A communication routine, even if it’s just a short weekly check-in, so nobody is guessing at progress.
Pro Tip: Put your stage gates in writing before the project starts, not after the first disagreement.
Audit current site: export baselines and map risks
You cannot prove a redesign worked if you never recorded what “before” looked like. This is the step most teams skip, and it’s the one that turns a messy launch into an unrecoverable mystery three months later when someone asks why organic traffic dropped and nobody has the old numbers to compare against.
Work through this before the old site changes in any way:
- Export twelve months of analytics data for your top landing pages: sessions, conversions and bounce rate.
- Pull a ranking snapshot for your priority keywords from whatever rank tracker or Search Console view you use.
- Crawl the live site to generate a complete URL list, including pages that no longer appear in navigation.
- Record every form, CRM integration and third-party script currently running, along with what each one does.
- Note your current hosting provider, backup schedule and who holds developer or admin access.
Historical data, once the old site is gone, is gone for good, which is exactly why gov.uk’s guidance treats exporting baselines as a non-negotiable step before migration, not a nice-to-have.
A few extra things worth capturing while you’re in there:
- Any legacy redirects already in place, so you don’t accidentally break a chain that’s been working for years.
- Pages ranking well that nobody remembers writing, often the ones with the most backlinks.
- Broken internal links or orphaned pages that the redesign gives you a natural chance to fix.
This audit becomes the single reference document everyone works from for the rest of the project, from content decisions through to the final redirect map.
Content inventory and URL mapping: keep, merge or retire
Once you have your full URL list, every page needs a decision: keep it, merge it into something stronger, or retire it. This is where a lot of redesigns quietly lose their best-performing content because nobody checked what was actually driving traffic before deleting it.
Work through the inventory with a simple decision rule. A useful guide on what is a client gallery, and why does every studio need one can help inform content choices in this process. A page keeps its slot if it ranks, converts, or serves a clear business purpose. Pages covering the same topic get merged into one stronger page rather than left to compete with each other. Anything outdated, duplicated, or no longer relevant to the business gets retired, with its traffic redirected to the closest living equivalent.
From the pages you keep, build your new information architecture and canonical sitemap. This is also the moment to flatten any content that’s grown unnecessarily deep over the years, since fewer clicks to a page generally helps both users and crawlers find it.
Your mapping spreadsheet needs, at minimum:
- Old URL and new URL, side by side.
- Page title, meta description and primary target keyword to carry across.
- Decision status: keep, merge or retire, with a one-line reason.
- Redirect type and destination, confirmed before build starts.
Pro Tip: Treat near-duplicate pages honestly. If two pages are answering the same question, merge them into one and redirect the weaker page, rather than letting them split your rankings.
SEO-safe migration: create and validate a redirect map, preserve tracking
This is the step that decides whether your redesign grows organic traffic or quietly bleeds it. The gov.uk guidance on redirect maps is direct about this: failing to map every legacy URL to a relevant new page is the most common cause of post-launch traffic drops, and it’s entirely avoidable with a bit of discipline.
The rule is simple but easy to get wrong under deadline pressure: every 301 redirect should point directly to its final destination. No redirect chains, where URL A points to B which points to C. Chains slow down crawlers, dilute link value and are far more likely to break silently when someone edits one link in the chain later.
A redirect map with gaps is worse than no redesign at all, because it looks finished right up until rankings start sliding a few weeks after launch.
Before you go live:
- Confirm every URL from your audit has a corresponding 301 entry, no exceptions.
- Test each redirect for chains and loops using a crawler, not by clicking through manually.
- Carry over canonical tags and structured data to the new page templates.
- Update your XML sitemap and robots directives to reflect the new structure.
- Verify your Google Search Console property and analytics tracking are connected and firing correctly before and after launch.
We’ve written more on this in our piece on implementing SEO best practices during a website migration, and if you want the shorter version of what can go wrong, our article on whether redesigns affect SEO walks through the usual failure points.
Design and accessibility: mobile-first, component systems and WCAG 2.2
Design decisions made in isolation from accessibility and responsiveness tend to get expensive to fix later, so we build both in from the first wireframe rather than bolting them on before launch.
Start every layout at the smallest screen size and work up, verifying each breakpoint actually works rather than just scales. A Statista figure on mobile’s share of web traffic is a useful reminder that “mobile-first” isn’t a design trend, it’s where most of your visitors already are.
WCAG 2.2 gives you a layered set of success criteria across conformance levels A, AA and AAA, and the practical move is to build these into your component templates once rather than auditing every page individually afterwards.
Work through this list at the component level:
- Colour contrast ratios checked against WCAG 2.2 thresholds for text and interactive elements.
- Full keyboard navigation for menus, forms and modals, with visible focus states.
- ARIA labels applied correctly, not sprinkled in as an afterthought.
- Every form control carrying a proper, programmatically linked label.
Pro Tip: Build accessibility into your component library once, and every page that uses those components inherits it automatically.
A shared component system also protects your Cumulative Layout Shift score, since consistent, pre-sized components stop content jumping around as the page loads.
Performance: set Core Web Vitals targets and test in lab and field
Pull your current Core Web Vitals data before you build anything new, so you have something concrete to improve on rather than a vague sense that “the new site feels faster”. The accepted “good” thresholds, as defined by web.dev, are an LCP of 2.5 seconds or under, an INP of 200 milliseconds or under, and a CLS score of 0.1 or under, all measured at the 75th percentile of real visits. Set those as your launch targets, not stretch goals.
Interaction to Next Paint became a Core Web Vital alongside LCP and CLS, replacing the old First Input Delay metric, and it’s worth checking specifically because slow interactions often hide behind an otherwise fast-looking page.
The optimisations that move these numbers most reliably:
- Serve images in modern formats at the correct size for the device, not a desktop image shrunk by CSS.
- Set proper caching headers so repeat visits load from cache rather than refetching everything.
- Inline critical CSS for above-the-fold content and defer the rest.
- Break up long JavaScript tasks that block the main thread during interaction.
Check both lab and field data: tools like PageSpeed Insights and Lighthouse show you where to focus fixes, while real-user monitoring shows what actual visitors on actual devices experience at the percentiles that matter. We’ve unpacked how this connects to revenue in our piece on page speed and conversions for small businesses.
Build and QA: continuous testing for functionality, integrations and security
Quality assurance works best as a running thread through the build, not a single sprint bolted on at the end. Gov.uk’s guidance is specific on this point: QA should be continuous, with technical checks completed and documented before anyone shows the site to stakeholders, not treated as a discovery phase where problems surface for the first time in front of the client.
Run through this test matrix as pages go live on staging:
- Automated and manual link checks across every page, catching anything the redirect map missed.
- Full redirect validation, confirming each legacy URL lands on its correct new destination.
- Form submission tests for every form, checking confirmation emails and CRM entries actually arrive.
- Integration checks for your CRM, email platform, payment gateway, tag manager and analytics.
- Cross-browser and cross-device checks, not just a quick glance on one laptop.
Alongside functional testing, work through a security and hosting checklist before anything goes near production:
- Full backup taken and verified as restorable, not just “backup completed” in a log.
- SSL certificate installed and forced across the whole domain.
- File and folder permissions reviewed, with admin access limited to people who still need it.
- Staging environment access locked down separately from production credentials.
Document every test result and get a named sign-off at each gate before the site goes in front of stakeholders for final approval.
Pre-launch: staging verification, backups, and launch rehearsals
The final week before launch is for confirming, not discovering. If something is broken here, it should be a known issue you’re fixing, not a surprise.
- Run a final staging pass covering performance, accessibility and the full redirect map together, not as separate checks.
- Take a complete backup of the live site and database, and write down the exact rollback steps in order.
- Schedule your DNS and hosting changes for the quietest traffic window your analytics show, and tell every stakeholder the exact time.
- Run a dry-run launch on staging to confirm monitoring and alerting actually fire when something goes wrong.
- Confirm every team member involved on launch day knows their task and who to contact if something stalls.
A rollback plan you’ve never tested isn’t a rollback plan, it’s a hope. Run the rehearsal properly, including the part where you pretend something has broken and practise fixing it.
Launch day: controlled cutover sequence and immediate smoke tests
Launch day runs on sequence, not speed. Rushing the order is how redirects go live before DNS has propagated, or caches get cleared before the new content is actually in place.
- Publish the new site to production and confirm it’s reachable at its final hosting location.
- Update DNS records and wait for propagation to confirm across multiple checking tools.
- Deploy the full redirect ruleset and confirm it’s active before announcing the launch publicly.
- Clear all caches, server-side and CDN, so visitors aren’t served stale versions of the old site.
- Run smoke tests on your highest-traffic pages, main forms and key analytics events immediately after each step.
- Scan for broken links and spot-check a sample of redirects from your map to confirm they resolve correctly.
Pro Tip: Keep your rollback trigger simple and pre-agreed, such as “more than a handful of critical redirects failing” or “the main contact form not submitting”, so nobody has to debate the decision live.
Know in advance who gets escalated to if something fails, and at what point the answer is rollback rather than patch and hope.
Post-launch monitoring, validation and rollback plan
The first 72 hours decide how much of your audit work actually paid off. Watch traffic and conversion funnels against the baselines you exported, alongside server error rates and any spike in 404s, which usually means a gap in the redirect map.
A single missed redirect can cost far more traffic than the page itself ever earned, because gov.uk’s guidance notes that incomplete redirect maps are the most common cause of post-launch traffic loss, and search engines re-crawl and reassess rankings quickly once they hit broken paths.
Run an automated crawl within the first day to catch redirect issues and broken links at scale rather than relying on manual spot checks. Compare rankings and organic traffic for your top landing pages against the snapshot you took during the audit.
- Check 404 reports daily for the first week, then weekly after that.
- Watch conversion funnels for drop-offs that didn’t exist on the old site.
- Keep your rollback criteria visible to the whole team, not just the person who wrote them.
- Agree who communicates status updates to stakeholders if something needs fixing.
Why choose a specialist agency and what to expect from an engagement
We built this checklist the way we build redesigns for the small business clients we work with day to day. As a specialised digital agency focused on small businesses, we spend most of our time on mobile-first websites paired with local SEO that’s actually meant to get found, not just look good in a portfolio.
Where we go further than a template rebuild is SmartFlowCRM, our own platform that pulls WhatsApp, email and other communication channels into one place, so leads generated by a freshly redesigned site don’t get lost across five different inboxes. For businesses needing something beyond a standard site, we also build bespoke web applications with ongoing support shaped around the specific challenges a client comes to us with.
If you’re evaluating proposals from any agency for your own redesign, ask for these in writing:
- A complete redirect map covering every legacy URL, not a sample.
- Confirmed backup and rollback procedures before any changes go live.
- A performance SLA covering Core Web Vitals, backed by real-user monitoring data.
- A clear sign-off process at each build stage, not just at the final handover.
Author perspective: practical rules we never waive
A few rules don’t get negotiated on any redesign we touch, regardless of budget or timeline pressure.
We always export baselines before anything on the old site changes, because that data cannot be recreated once it’s gone. We always draft the redirect map before design starts, not after, because retrofitting redirects onto a finished build is how gaps slip through. QA runs continuously through the build rather than as a single pass at the end, with a documented sign-off at every gate, because a verbal “looks fine to me” isn’t a record anyone can act on later.
And we always rehearse the launch and hold a rollback window open, even when everything on staging looks perfect. Staging never quite matches production, and the businesses that skip the rehearsal are the ones calling us in a panic at 6pm on launch day.
— Chris
How TTOY Digital helps: services that map to this checklist
If working through all of this alongside running your actual business sounds like a lot, that’s exactly the gap we exist to fill. Our web design plans, Starter, Growth and Smart, cover the managed redesign process end to end: audit, redirect-first migration, build and launch, with transparent pricing and unlimited content changes rather than a fixed scope you’ll outgrow in six months.
Once your new site is live, SmartFlowCRM on our Silver or Gold plans keeps the leads it generates organised across WhatsApp and email instead of scattered across inboxes, and our WordPress Maintenance and UK Web Hosting plans handle the backups, uptime and security checks a redesign needs after launch, not just during it. If organic traffic preservation is your main worry, our SEO service picks up where the redirect map leaves off, keeping rankings moving in the right direction.
When you’re comparing quotes from any agency, ask for the redirect map, backup plan and performance targets in writing before you sign anything. If you’d rather talk it through first, get in touch with our Derbyshire-based team and we’ll tell you honestly what your project needs.
FAQ
What are the 7 C’s of website design?
The “C’s” are a loose framework some designers use to cover key website aspects such as context, content, community, customisation, communication, connection and commerce, though the exact list varies between sources. Rather than chasing a fixed acronym, the checklist in this article, goals, audit, content, SEO, design, performance and launch, covers the same ground in a more actionable order.
How do I plan a website redesign?
Start with written, measurable goals tied to traffic and conversion targets, then audit your current site to export baseline analytics, rankings and a full URL list before anything changes. From there, build a content inventory, a redirect map and a build and QA schedule with clear stage gates before design work begins.
How can I redesign my existing website without losing rankings?
The main safeguard is a complete 301 redirect map covering every legacy URL, with each redirect pointing directly to its final destination rather than through a chain. Export your current rankings and traffic as a baseline before launch, then compare them against the same pages after launch to catch and fix any gaps quickly.
How long does a website redesign usually take?
Timelines vary widely depending on scope, but most small business redesigns move through planning, audit, build, QA and launch over several weeks to a few months. Setting clear stage gates for each phase, rather than an open-ended single deadline, tends to keep the project on track.
