Protect Rankings in 30 Days: UK Website Redesign Checklist

A website redesign checklist works only when it forces sequence: goals and content decisions first, design and build second, testing and monitoring last. Skip that order and you end up rebuilding a site that looks sharper but ranks worse. Start today by building a content inventory and setting three or four measurable KPIs before anyone opens a design tool.

TL;DR:

• Building a comprehensive content inventory and setting measurable KPIs before starting design drastically reduces the risk of losing search visibility and usability post-launch.
• A proper project sequence must include goal setting, content planning, design development, testing, and stabilization, with each phase producing inputs for the next.
• Pre-launch checks should verify Core Web Vitals, correct redirects, accessibility compliance, and functional QA for critical user paths on multiple devices to prevent costly post-launch fixes.
• Clear stakeholder sign-offs, detailed documentation, and a staged handover process ensure the team can operate and maintain the site independently after launch.
• Partnering with specialists who review, test, and deliver a fully functional site before payment minimizes surprises, shortens revision cycles, and ensures SEO, performance, and accessibility standards are met.

Table of Contents

• What should a website redesign checklist actually cover?
• Content inventory and URL mapping: the step everyone underestimates
• What design deliverables do you need before development starts?
• How do you hit Core Web Vitals targets before launch?
• SEO checklist: redirects, metadata and structured data
• What should pre-launch QA actually test?
• Launch day sequence: what order should tasks happen in?
• 30-day stabilisation: what to check after launch
• Accessibility checklist aligned to WCAG 2.2
• Sign-off, documentation and operations handover
• Why a specialist reduces redesign risk
• What redesign trade-offs should you expect?
• Get a redesign that's tested before you pay for it
• Sources
• FAQ

What should a website redesign checklist actually cover?

A proper redesign project plan runs through five stages: planning, content and architecture, design, build and testing, then launch and stabilisation. Most failed relaunches skip straight from "we need a new look" to hiring a designer, which is why traffic drops within weeks of going live. The checklist below follows the order that protects both SEO and usability, because each phase produces the inputs the next one needs.

If you have heard of the "7 C's" of web design, they cover much the same ground under a different label: clarity, consistency, credibility, content, conversion, compatibility and communication. They are useful as a mental checklist for the finished product, but they do not tell you how to sequence a redesign project, which is the gap this guide fills.

Set goals, KPIs, stakeholders and a realistic timeline

A redesign without a stated KPI is just a design refresh with extra risk. Before anyone touches a wireframe, agree what "success" looks like in numbers, and who signs off on each stage.

Core metrics worth tracking from day one:

• Traffic retention on your top 20 pages by organic sessions, measured 30 and 90 days post-launch.
• Conversion rate for your primary goal (enquiry form, checkout, phone click), benchmarked against the last 90 days of the old site.
• Core Web Vitals at the 75th percentile, gated before launch (covered in detail further down).
• Bounce rate and time on page for your five highest-traffic landing pages.

Roles matter more than most teams admit. Nominate one decision-maker per stage: a content approver, a design approver, and a technical sign-off owner. Without named approvers, feedback rounds drag on indefinitely and the project stalls in review purgatory. Set a communication cadence, weekly is usually enough, and put milestones on a shared calendar with buffer time built in rather than assumed.

Budget guardrails should include a contingency of roughly 15 to 20% for scope creep, because redesigns almost always surface legacy problems nobody scoped (broken integrations, undocumented custom code, content nobody can find the original author for). Define rollback criteria now, while you're calm, not during a stressful launch night: what performance or error threshold triggers a revert to the old site?

A short risk register helps here. List the risk, its likelihood, its impact, and the owner responsible for watching it. A typical entry: "Third-party booking widget breaks on new theme, likelihood medium, impact high, owner: development lead."

Pro Tip: Write your rollback criteria as a single sentence you could read aloud at 2am: "If checkout conversion drops more than 30% in the first six hours, we revert." Vague criteria get argued over during the exact moment you need speed.

Content inventory and URL mapping: the step everyone underestimates

Every URL on your existing site needs a decision before launch, not during it. A complete content inventory and granular URL disposition is the single biggest safeguard against losing search visibility in a redesign, and it's the step most teams rush or skip entirely.

1. Export every URL from your CMS, sitemap and Google Search Console (crawled and indexed pages often differ, so check both).
2. Classify each URL using one of five labels: keep as-is, update content, merge with another page, redirect, or retire entirely.
3. Prioritise by traffic and backlinks, using Search Console and your analytics tool to flag which pages earn organic sessions or external links, since these are the ones that will hurt most if mishandled.
4. Build a redirect map in a shared spreadsheet with source URL, destination URL, redirect type (301 in almost all cases), and a note on why the decision was made.
5. Test the redirect map on staging before launch, checking for redirect chains (A to B to C) and loops, both of which waste crawl budget and confuse users.

Keep the redirect notes machine-readable where you can, recording the reason, the previous traffic level and a priority flag for each rule, because that level of detail makes post-launch reversals auditable rather than a guessing game six weeks later.

Information architecture work runs in parallel with content classification, not after it. Useful exercises include:

• Card sorting with five to eight real users or staff members to see how they naturally group your content.
• Top-task analysis, asking your ten most common site visitors what they came to do, then checking whether your proposed navigation gets them there in two clicks or fewer.
• Menu pruning, cutting any navigation item that gets under 2% of total clicks in your current analytics.

Once the structure is settled, build content templates for each page type (service page, blog post, case study) with metadata standards baked in: title tag length, meta description format, heading hierarchy rules, and required alt text fields. This turns content migration into a repeatable task instead of a fresh decision on every page.

What design deliverables do you need before development starts?

Design work should move from rough to refined in stages, and skipping stages is the most common cause of expensive rebuilds mid-project. The deliverable sequence: low-fidelity wireframes, then interactive prototypes, then a component library the developers can build from directly.

Required deliverables, in order:

• Low-fidelity wireframes for every unique page template, agreed with stakeholders before any colour or imagery is added.
• Interactive prototypes covering your top three to five user journeys (find a product, submit an enquiry, complete checkout).
• A component library documenting buttons, forms, cards and navigation states, so developers aren't guessing at edge cases.
• Mobile-first layouts, designed for the smallest screen first and expanded upward, not the reverse.

Mobile-first is not a slogan, it's a design constraint. Build every layout at 375px width before you touch a desktop breakpoint, and test tap target sizing, form field spacing and menu behaviour at that width before anything else. Responsive testing should cover at minimum: 375px (small phone), 768px (tablet), 1280px (laptop) and 1920px (desktop), checked on real devices where possible rather than only a browser resizer.

Usability testing belongs in the design phase, not after launch when fixes are expensive. A workable test plan needs:

• Five to eight participants, ideally a mix of existing customers and people unfamiliar with your brand.
• Three to five defined tasks (e.g. "find our opening hours", "start a booking").
• Success criteria stated in advance: task completion rate, time on task, and a satisfaction rating.

Fold accessibility checks into design review meetings rather than treating them as a separate audit later. Check colour contrast ratios, confirm every interactive element has a visible focus state, and verify heading structures follow a logical hierarchy before a single line of code gets written.

Pro Tip: Run your five-participant usability test on the prototype, not the finished build. Fixing a confusing navigation label in Figma costs an hour. Fixing it after launch costs a developer's afternoon and a re-test.

How do you hit Core Web Vitals targets before launch?

Set the performance bar before development starts, not after the client complains the new site feels slower than the old one. The current thresholds are unambiguous: Largest Contentful Paint (LCP) should be 2.5 seconds or under, Interaction to Next Paint (INP) should be 200 milliseconds or under, and Cumulative Layout Shift (CLS) should be 0.1 or under, all measured at the 75th percentile of real user visits rather than a single best-case test run.

Core Web Vitals gate: don't launch until your 75th percentile scores on primary landing pages meet these "good" thresholds, or have a documented mitigation plan such as a phased rollout or feature flags on the heaviest pages. Treating this as optional is how redesigns quietly get slower than the site they replaced.

Practical optimisations that move the needle:

• Serve modern image formats (WebP or AVIF) with responsive sizing, rather than one oversized JPEG scaled down by CSS.
• Load fonts efficiently, using font-display: swap and preloading critical font files rather than letting render block on a font request.
• Defer or async non-critical scripts, especially third-party trackers and chat widgets, so they don't delay interactivity.
• Set a caching strategy at the CDN and browser level, with sensible cache lifetimes for static assets.
• Inline critical CSS for above-the-fold content so the browser doesn't wait on a full stylesheet download to paint anything.

Testing strategy should combine two approaches. Lab tools such as PageSpeed Insights or Lighthouse are useful for debugging a specific, reproducible problem, but field data from a real-user-monitoring tool is preferable for diagnosing INP issues because it reflects genuine interaction context rather than a single simulated session. Chrome's own Web Vitals data draws on CrUX (Chrome User Experience Report) for origin-level field insight, which is worth pulling before and after launch to compare like-for-like.

INP specifically is judged "good" at 200 milliseconds or below, and it replaced First Input Delay as a Core Web Vital because it captures the full responsiveness of a page, not just the first click. A redesign with heavy JavaScript animations or bloated third-party scripts is the most common way INP quietly slips past that threshold.

Make performance an acceptance criterion, not a nice-to-have caveat. Write it into your sign-off document: "Staging environment must show LCP under 2.5s and INP under 200ms on the homepage, product listing and checkout templates before deployment approval."

SEO checklist: redirects, metadata and structured data

Redirect mapping done in the content phase gets tested and validated here, right before launch, because this is your last checkpoint before search engines start crawling the new URLs.

1. Verify every redirect returns a 301 status, not a 302, since temporary redirects don't pass the same signal to search engines and can leave old URLs indexed alongside new ones.
2. Check for redirect chains and loops using a crawler tool, fixing any URL that bounces through more than one hop.
3. Preserve title tags, meta descriptions and heading structures on pages that keep their content, since a full rewrite during a redesign often loses ranking signal for no real gain.
4. Audit for orphaned pages, confirming every important URL is reachable through internal navigation or a sitemap link, not just a direct URL.
5. Test and resubmit your XML sitemap in Search Console once the new structure is live, alongside an updated robots.txt that isn't accidentally blocking crawlers.
6. Validate structured data (schema markup) using Google's Rich Results Test, particularly for product, review, article or local business markup carried over from the old site.

Beyond the numbered sequence, a few checks are easy to forget under launch pressure:

• Confirm canonical tags point to the correct new URL, not a leftover staging domain.
• Check that internal links across the site point to final URLs, not to redirect targets (redirect chains inside your own navigation are avoidable).
• Set up Search Console for the new property (or confirm the existing one still verifies) before launch day, not after.

Google's own guidance treats a structured site-move plan combined with a defined monitoring period as essential to avoiding long-term traffic loss after a relaunch, which is exactly why the next phase matters as much as launch day itself.

What should pre-launch QA actually test?

Functional testing on staging needs to cover every critical business flow, not just the pages that look finished. Forms, payment processing and sign-up flows deserve dedicated test scripts, because these are the paths where a broken redesign costs actual revenue, not just a bad user experience.

• Test every form submission end-to-end, including validation messages, confirmation emails and any CRM or booking integration behind it.
• Run a link check across the full site to catch broken internal and external links before real visitors do.
• Load-test key pages if you expect a launch-day traffic spike from an announcement or marketing push.
• Check third-party integrations (payment gateways, booking widgets, chat tools, analytics tags) fire correctly on the new codebase.

Cross-browser and device testing needs a defined matrix rather than "check it on whatever's on your desk." Cover at minimum the two most recent versions of Chrome, Safari and Firefox, plus one older Android device and one iOS device. Keyboard-only navigation and screen reader testing (NVDA or VoiceOver are common free options) belong in this same pass, not as an afterthought.

Automated accessibility scans (tools like axe or WAVE) catch perhaps a third of real issues. Manual keyboard testing and form-field checks against WCAG success criteria catch the rest, particularly focus order and error messaging that automated tools can't judge properly.

A simple triage matrix keeps bug lists from becoming a shouting match. Rank each issue as blocker (breaks a core journey), high (affects usability but has a workaround), or low (cosmetic), and agree that only blockers and high-priority items can delay launch.

Pro Tip: Assign one person to own the bug triage list during the final QA week. Without a single owner, the same ten bugs get discussed in three different meetings and nothing gets fixed faster for it.

Launch day sequence: what order should tasks happen in?

Launch day works best as a strict, timed sequence rather than a list everyone tackles in whatever order feels urgent.

1. Lower your DNS TTL (time to live) to 300 seconds or less at least 24 to 48 hours before the switch, so the eventual DNS change propagates quickly rather than taking the default 24 hours some records carry.
2. Take a full backup of the current live site (files, database, DNS records) immediately before any change, stored somewhere outside the hosting environment itself.
3. Switch DNS or CDN configuration to point at the new environment, then monitor propagation using a DNS checker tool across multiple regions.
4. Run immediate validation checks: confirm redirects fire correctly, analytics tags are recording sessions, and Search Console shows the new property crawling without blocked-resource errors.
5. Test critical paths live: submit a real test form, run a test transaction if you have a payment flow, and click through your top three navigation journeys.
6. Confirm monitoring is active, covering real-user monitoring, uptime alerts, and server error logs, with a named on-call contact for the first 24 hours.
7. Set clear rollback triggers before you need them: agree the specific error rate, downtime duration or performance drop that triggers a revert, and confirm who has authority to pull that trigger without a committee vote.

Keep the whole sequence on a shared document during launch, ticking items off in real time, so nobody duplicates a check or, worse, assumes someone else did it.

30-day stabilisation: what to check after launch

Launch is the start of the monitoring period, not the end of the project. Practitioners treat the weeks after a relaunch as a structured stabilisation window, where daily checks catch problems before they cause lasting ranking damage.

For the first two weeks, check daily:

• Crawl errors and 404s in Search Console, fixing any missed redirect within 24 to 48 hours of discovery.
• Organic traffic trends for your top 20 pages, comparing week-on-week rather than reacting to single-day noise.
• Core Web Vitals field data via CrUX or your RUM tool, watching for regressions that lab testing missed.
• Server error logs, particularly 500-level errors that indicate a broken integration rather than a content issue.

From week three to day 30, drop the cadence to weekly, but keep watching the same four signals plus conversion rate against your pre-launch benchmark.

Post-launch regressions tend to follow a predictable pattern: missing meta descriptions on migrated templates, broken internal links from an incomplete redirect map, and performance regressions on pages nobody load-tested because they weren't flagged as "important." Fix each stepwise: patch the meta issue in the CMS template, re-run your link checker weekly until it comes back clean, and re-test Core Web Vitals on any page showing a traffic drop.

If organic traffic on a key page drops more than roughly 20% against the pre-launch baseline and stays down for over a week, that's a signal to pause paid marketing spend pointing at that page and investigate before spending more to drive traffic at a broken experience. Tell stakeholders early rather than waiting for the monthly report, since a ranking dip caught on day five is far cheaper to fix than one caught on day 35.

Accessibility checklist aligned to WCAG 2.2

WCAG 2.2 adds several new success criteria beyond the 2.1 standard, and the working group recommends adopting 2.2 as your conformance target for any redesign happening now rather than building to an older version.

The new criteria that most commonly bite redesigns:

• Focus not obscured: a sticky header or cookie banner must never hide the element currently in keyboard focus.
• Target size: interactive elements need roughly 24 by 24 pixels of tappable area at minimum, a common failure point in dense mobile navigation.
• Accessible authentication: login flows shouldn't rely solely on a cognitive test (like solving a puzzle) without an alternative method.

Beyond the new criteria, the fundamentals still deserve a dedicated pass: colour contrast ratios of at least 4.5:1 for body text, visible focus indicators on every interactive element, navigation that stays predictable across pages, and forms that don't force users to re-enter information they've already provided elsewhere in the same journey.

WCAG is structured around testable success criteria at levels A, AA and AAA, and most UK business sites should target AA as a realistic, defensible conformance level. Document which criteria you've tested and how, so a conformance claim is something you can actually back up if a client or regulator asks. Aiming slightly beyond the minimum, rather than scraping past AA on a technicality, tends to catch more real usability problems for older users and anyone on an assistive device.

Pro Tip: Test your busiest form with keyboard-only navigation before launch, no mouse at all. If you can't complete it without touching the trackpad, neither can a significant number of your visitors.

Sign-off, documentation and operations handover

A redesign isn't finished when it launches, it's finished when the team running the site day-to-day can operate it without calling the developer every time something small needs changing.

Define acceptance criteria before the final review meeting, not during it, covering functional tests passed, performance targets met, and accessibility checks completed. A stakeholder sign-off checklist should list each approver by name against each deliverable, so there's no ambiguity about who actually agreed the site was ready.

Documentation to hand over includes:

• A runbook covering hosting details, DNS records, backup schedule and who to contact for each system.
• A component library so future edits stay visually consistent rather than drifting page by page.
• An editorial style guide covering tone, image sizing rules and metadata standards for anyone adding content later.

Training matters as much as documentation. Run a session with whoever will edit the site day-to-day, covering how to add a page, update navigation, and check that a new image doesn't break page layout. Agree a maintenance schedule (monthly plugin and security updates are a sensible minimum) and a clear SLA for who responds to an outage and within what timeframe.

Why a specialist reduces redesign risk

Most of the failure points in this checklist, lost SEO signal, missed performance targets, accessibility gaps, come from rushing a stage or skipping it because nobody owned it. Webnora builds every site mobile-first with SEO fundamentals in place from the start (sitemap structure, Search Console setup, image alt text and page-level optimisation), rather than retrofitting them after a client complains rankings dropped.

Specific practices that lower risk in a redesign specifically:

• Custom-built sites, not recycled templates, so the codebase doesn't carry someone else's unused bloat that slows Core Web Vitals scores.
• Clients review and approve the completed site before any payment changes hands, which removes the financial risk of paying up front for work that doesn't meet the brief.
• Direct, transparent communication throughout the build, rather than updates filtered through account managers who don't touch the code.

For a business owner without an in-house technical team, the value of specialist practice isn't jargon, it's fewer surprises: a site that loads fast on a phone, doesn't lose its Google rankings in the handover, and looks the way you were shown before you paid for it.

What redesign trade-offs should you expect?

Launch day feels like the finish line, but it's really the start of the 30-day stabilisation window covered above, and treating it as the end is the single most common mistake I see in redesign projects. Traffic dips in week one are normal. Traffic still dipping in week five means something in the redirect map or content migration was missed.

Every redesign is a negotiation between scope, time and budget, and something always gives. If your timeline is fixed (a launch tied to a rebrand event, say), scope has to flex, cut the nice-to-have features and protect the pages that actually earn revenue. If budget is fixed, expect the timeline to stretch, because rushing QA to hit a date is how launch-day fires start.

The pragmatic approach beats the ambitious one almost every time. A checklist followed in order, with realistic acceptance criteria and a named owner for each stage, will outperform a beautifully designed site built without one. Treat this as the operating manual, not a wishlist.

— Ar

Get a redesign that's tested before you pay for it

Some agencies ask for payment before you've seen the finished site, which means there's a risk if the result doesn't match expectations. Some agencies offer a service where your redesign is built, tested against a checklist, and shown to you complete before any money changes hands.

Webnora's redesign and website services cover business websites, personal sites, landing pages, full redesigns and SEO setup, each one built from scratch rather than assembled from a recycled template, with mobile-first design and the SEO fundamentals (sitemap, Search Console setup, alt text, page-level optimisation) handled as standard rather than sold as an add-on. Each project can be custom built, and some services let clients see the working site before committing to payment, which helps reduce the risk of paying upfront for a result not yet tested.

If your current site is due a rebuild and you want the process handled without the guesswork this checklist is meant to prevent, get in touch through Webnora's services page for a quote, or browse how the process works before you reach out.

FAQ

What are the 7 C's of website design?

The 7 C's, clarity, consistency, credibility, content, conversion, compatibility and communication, describe qualities a finished site should have rather than steps for getting there. They're a useful lens for judging your finished redesign, but they don't replace a phased project plan with content mapping, design validation and post-launch monitoring built in.

How do I plan a website redesign without losing SEO?

Build a full content inventory and URL map before development starts, classifying every page as keep, update, merge, redirect or retire. Test your 301 redirect map on staging, preserve metadata and headings on pages that aren't being rewritten, and follow Google's site-move guidance on monitoring the first 30 days closely for crawl errors and traffic drops.

What should I check before launching a redesigned site?

Confirm Core Web Vitals meet the 75th-percentile thresholds (LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1), test every redirect for a correct 301 status, and run functional QA on forms, payments and critical navigation paths across your device matrix. Accessibility scans against WCAG 2.2 and a rollback plan should both be signed off before DNS is switched.

How can I redesign my existing website without a full rebuild?

A partial redesign is realistic if your information architecture and content are largely sound, in that case, focus the checklist on design deliverables, performance optimisation and accessibility rather than a full content inventory. Most small business sites still benefit from a professional review beforehand; Webnora's website redesign service assesses what genuinely needs rebuilding versus what can be kept and improved.

How much does a website redesign cost?

Costs vary by scope, number of page templates, and whether content needs rewriting alongside the design. Webnora's redesign pricing is available on request through the services page, where you can request a quote based on your specific site.

Recommended

• How It Works
• Portfolio

Written using BabyLoveGrowth