Website Redesign QA Checklist: Don't Break What's Working

A website redesign is one of the highest-risk releases a team will execute. Unlike shipping a new feature — where the worst-case scenario is that the feature does not work — a redesign has a much larger blast radius. Everything that was working before is now a regression candidate. Every page, every form, every redirect, every pixel of SEO equity, every conversion path.

Most redesign QA failures are not failures of effort. They are failures of coverage. Teams test the new experience thoroughly and forget to verify that the old experience still functions correctly underneath it. The checkout flow that worked for three years breaks because a class name changed. Organic traffic drops because canonical tags were not carried over. A critical form stops submitting because a JavaScript library was quietly swapped out.

This checklist exists to close that gap. It is organized around the five areas where redesigns most commonly introduce silent regressions: baseline documentation, content migration, SEO preservation, functionality parity, and performance. It ends with a rollback plan, because even the best-tested redesign launch deserves one.

Phase 1: Pre-Redesign Baseline Documentation

You cannot verify that nothing broke if you do not know what working looked like before the launch. Baseline documentation is not optional — it is the entire foundation of redesign QA. Do this before a single staging environment is stood up.

Traffic and analytics baseline

Export current organic traffic by page (Google Search Console, 90-day window)
Document top-performing pages by sessions, pageviews, and conversions
Record current Core Web Vitals (LCP, CLS, FID/INP) for the top 20 pages
Export current bounce rate and average session duration by page
Document current conversion rates for every goal tracked in analytics
Screenshot or export current goal/event configuration so it can be replicated exactly

URL inventory

Crawl the current site with a tool like Screaming Frog and export the full URL list
Note every URL that receives organic traffic in Search Console — these are mandatory redirect targets
Document all existing 301 redirects already in place (export from .htaccess, Nginx config, or redirect manager)
List all pages that are linked to from external domains with meaningful authority
Capture all URLs referenced in email campaigns, paid ads, or social media bio links

Functionality inventory

Document every form on the site: location, fields, submission endpoint, confirmation behavior
List every third-party integration: payment processors, CRM connectors, chat widgets, analytics tags, marketing pixels
Record every authenticated flow: login, registration, password reset, account management
Note any custom JavaScript that handles business logic — sliders, calculators, quote generators
Capture which pages use which templates, so template-level changes can be scoped correctly

Visual baseline

Take full-page screenshots of the top 30 pages at desktop (1440px) and mobile (375px) viewports
Record short screen captures of key interactive components: navigation menus, modals, accordions, carousels
Document the current font stack, color palette, and spacing system for reference during design QA

Phase 2: Content Migration Checks

Content that existed before the redesign must exist after it — in the right place, with the right structure, and without losing any metadata that contributes to search performance.

Page presence

Every URL from the pre-redesign crawl either exists at the same URL on the new site or has a 301 redirect pointing to its new location
No pages that previously returned 200 now return 404 without a redirect
No pages that were previously indexed now return 403 or are blocked by robots.txt
Landing pages referenced in active paid campaigns exist and load correctly
Legal pages (privacy policy, terms of service, cookie policy) are present and current

Content accuracy

Body copy matches the approved source — no truncation, no placeholder text left in production
All headings (H1, H2, H3) are present and match the content hierarchy from the original or redesigned spec
Images are present, load correctly, and have not been replaced with wrong assets
All in-page links point to correct destinations — internal links updated if URLs changed
Author, date, and category metadata on blog posts and articles are accurate
Structured data (schema markup) is present on pages that had it — product, article, FAQ, breadcrumb schemas

Navigation and site structure

Primary navigation links point to the correct pages on the new site
Footer links are updated — phone numbers, addresses, social media links
Breadcrumb navigation reflects the correct page hierarchy
Sitemap.xml has been regenerated and submitted — it does not reference pre-redesign URLs that no longer exist

Phase 3: SEO Preservation

Organic search rankings are slow to recover once lost. A redesign that goes live without proper SEO QA can cause traffic drops that take months to reverse. This section is non-negotiable if organic traffic is a meaningful channel.

Redirects

Every URL that previously ranked in search has either been preserved or has a direct 301 redirect to its new location
Redirects are 301 (permanent), not 302 (temporary) — unless a 302 is intentionally appropriate
Redirect chains are resolved — no URL that redirects through more than one hop
Redirect loops have been tested and do not exist
Old sitemap URLs redirect correctly to their new equivalents
www and non-www versions of the domain both resolve to the canonical version
HTTP redirects to HTTPS without exception

On-page SEO elements

Every page has a unique, descriptive title tag (under 60 characters)
Every page has a unique meta description (under 160 characters)
Canonical tags are present and point to the correct URL — no page canonicalizing to itself with a different URL format, and no accidental self-referencing canonicals on paginated pages
H1 tags are present on every page — exactly one H1 per page
Open Graph and Twitter Card meta tags are present for pages that are shared on social media
No pages that should be indexed are marked noindex — audit robots meta tags across the site
No pages that should not be indexed are missing the noindex tag

Technical SEO

robots.txt does not block crawling of important content — compare to the pre-redesign version
Sitemap.xml is valid, accessible at /sitemap.xml, and submitted to Google Search Console
Hreflang tags are correctly implemented if the site serves multiple languages or regions
Structured data validates in Google's Rich Results Test for all pages that had schema markup
Internal linking structure has been preserved — pages that were well-linked remain well-linked
Page speed does not regress significantly — Core Web Vitals on key pages are within 10% of baseline

Phase 4: Functionality Parity

Every feature that worked before the redesign must work after it. This is the section that teams most often abbreviate under deadline pressure — and the section that produces the most painful post-launch incidents.

Forms

Every form submits successfully and produces the correct confirmation state (message, redirect, or both)
Form validation rules are identical to pre-redesign behavior — no new required fields added unintentionally, no validation removed
Form submissions reach their intended destination: CRM, email inbox, database, or API endpoint
Hidden fields and UTM parameter capture are working — marketing attribution must survive the redesign
Multi-step forms advance and retreat correctly between steps
File upload inputs enforce the same size and type restrictions as before
Anti-spam measures (CAPTCHA, honeypot fields) are in place and functional

E-commerce functionality (if applicable)

Product pages display correct price, SKU, availability, and variant options
Add to cart, update quantity, and remove item all function correctly
The full checkout flow — from cart through payment confirmation — completes without error
Guest checkout and authenticated checkout both work
Payment processor integration functions correctly in staging with test card numbers
Order confirmation emails send and contain correct order details
Discount codes and promotional pricing apply correctly

Authentication flows

New user registration completes and produces the correct welcome state
Login with correct credentials succeeds; login with incorrect credentials is rejected with an appropriate message
Password reset flow sends the reset email, the link works, and the new password is accepted
Session persistence works as expected — users remain logged in for the correct duration
OAuth login providers (Google, GitHub, etc.) complete the full authorization flow
Account management pages (profile, billing, preferences) load and accept changes

Third-party integrations

Analytics: all pre-existing pageview tracking, event tracking, and goal conversions fire correctly
Marketing pixels: Facebook, Google Ads, and other retargeting pixels are present on the correct pages
Live chat or support widget loads and connects correctly
Newsletter signup integrations push subscribers to the correct list
CRM integrations receive form submissions with the correct field mapping
Any API-driven content (pricing widgets, inventory feeds, review imports) loads and renders correctly

Cross-browser and device parity

Primary user flows tested in Chrome, Firefox, Safari, and Edge
Mobile experience tested on iOS Safari and Android Chrome on real devices
Touch interactions on mobile (taps, swipes, pinch-to-zoom) work correctly on redesigned components
No JavaScript errors in the browser console on any tested browser

Phase 5: Performance Comparison

A redesign often introduces new libraries, heavier assets, or additional third-party scripts. Performance should be measured against the documented baseline — not just against an abstract "good" threshold.

Run performance tests on the staging environment before launch

Measure LCP, CLS, and INP for the homepage, top landing pages, and the most important conversion pages
Compare against the baseline numbers captured in Phase 1 — flag any page where LCP increased by more than 500ms
Verify total page weight has not ballooned — compare before and after using the Network tab or WebPageTest
Confirm images are being served in modern formats (WebP or AVIF) with correct responsive sizing
Confirm JavaScript bundle size has not increased significantly without a corresponding feature justification
Verify third-party scripts load asynchronously and do not block the main thread
Check that cache headers are set correctly on static assets
Run a Lighthouse audit on the top 10 pages and compare scores against the baseline

Post-launch monitoring

Set up a Core Web Vitals alert in Google Search Console to catch regressions after real-user traffic begins
Monitor 404 error rate in the first 48 hours post-launch — a spike indicates missing redirects
Watch bounce rate on key landing pages for the first week — an increase can signal content or UX issues
Check organic click-through rate in Search Console 2–4 weeks after launch for early ranking signals

Phase 6: Rollback Plan

No redesign QA process, no matter how thorough, eliminates all risk. A rollback plan is not a pessimistic gesture — it is a professional one. The teams that struggle most with launch incidents are the ones who assumed they would not need one.

Before launch day

The previous version of the site is still accessible in a staging or archived environment
All deployment steps are documented and reversible — the team knows exactly how to revert DNS, CDN, or hosting configuration
Database migrations, if any, can be rolled back without data loss
Rollback triggers are defined: specific metrics thresholds, error rates, or incident severity levels that would initiate a rollback
The team member with authority to call a rollback is identified and available on launch day

On launch day

Run a smoke test immediately after going live: homepage, navigation, top landing pages, primary conversion flow
Monitor error rates in real time for the first two hours
Verify redirects are working in production — test a sample of high-traffic redirects directly
Check that analytics events are firing in the production environment, not just staging
Confirm no unexpected 500 errors in server logs
Keep the team on standby for four hours post-launch before declaring the release stable

Capturing Bugs During Redesign QA

Working through a checklist of this scope across a full website produces a volume of bugs that is hard to manage with ad hoc screenshots and Slack messages. Reproduction steps get lost. Console errors go undocumented. Network failures that would explain a bug are visible for thirty seconds in DevTools before someone closes the tab.

This is where Crosscheck fits naturally into redesign QA. Crosscheck is a browser extension that captures everything at the moment you find a bug: a full screenshot or session replay, the complete console log, every network request in the tab, and your browser and environment details. When you hit a redirect loop in Phase 3, or a form submission that silently fails in Phase 4, or a Core Web Vitals regression you want to flag in Phase 5 — one click generates a complete bug report.

For redesign QA specifically, Crosscheck's instant replay feature is particularly useful. When a developer picks up a regression ticket, they can watch a replay of exactly what the tester did, on the exact page state that triggered the bug. There is no ambiguity about reproduction steps, and no back-and-forth about "I cannot reproduce this" when the session recording shows precisely what happened.

Crosscheck sends reports directly to Jira, Linear, ClickUp, or wherever your team tracks work — with all the technical context already attached. For a QA cycle that spans dozens of pages and hundreds of checklist items, that matters.

The Discipline of Not Breaking What Works

Redesigns are exciting. New visual systems, improved information architecture, better mobile experiences — all of it is worth the effort. But the users who trusted your old site do not care about your new design system. They care that the thing they came to do still works.

The checklist above is designed to protect that trust. Baseline documentation ensures you know what "working" looks like before you change anything. Content and SEO checks ensure the new site carries forward the equity the old one earned. Functionality parity testing ensures that every form, integration, and authenticated flow that worked before launch still works after it. Performance comparison ensures the redesign does not quietly slow down the experience that users have come to expect.

And the rollback plan ensures that if something does break despite all of this, you can fix it before it costs you.

A redesign should make your site better. This checklist makes sure it does not make it worse.

Crosscheck helps QA teams capture bugs faster during high-stakes launches — with automatic screenshots, console logs, network captures, and session replay in every report. Try it free before your next redesign goes live.