Website Redesign QA Checklist

A website redesign quality assurance checklist is not a bureaucratic formality. More redesigns launch with avoidable defects than any other type of web project, and the cause is almost always the same: the QA phase was rushed, shortened, or skipped entirely.

A structured QA process is what separates a clean launch from a week of emergency fixes, broken forms, and lost analytics data.

A visual scroll-through by a single person misses 40 to 60% of real defects.

A written checklist, completed by multiple reviewers across multiple devices, closes those gaps. This article covers every category of QA that a professional redesign launch requires.

Key Takeaways

• QA has two distinct phases: Pre-launch testing on staging and post-launch verification on production, both are required, and neither replaces the other.
• Multi-device and multi-browser testing is mandatory: A site that works perfectly on your Mac in Chrome may break on an Android device in Samsung Internet.
• Forms and tracking are the most-missed failures: Broken contact forms and misconfigured analytics are the two issues that cause the most post-launch damage.
• Redirect verification must be exhaustive: Every changed URL must be individually tested, one missed redirect on a high-traffic page damages SEO rankings and user experience.
• Written checklists prevent gaps: A checklist shared between multiple reviewers ensures every category is covered before launch approval is given.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

Pre-Launch QA: Staging Environment

Pre-launch QA on the staging environment is the most important phase of quality assurance. Every issue caught on staging costs a fraction of what it costs to fix after launch.

Content Review: All Pages, All Copy

Every page must be reviewed for content accuracy before the site goes live.

• Placeholder content check: Verify that every instance of "Lorem ipsum," dummy text, and placeholder images has been replaced with final content.
• Copy accuracy: Verify that all copy is the approved final version, not an earlier draft or an uncorrected version of supplied content.
• Image completeness: Check every image on every page, broken image links, missing alt text, and placeholder images are common in newly built sites.
• Date and personnel accuracy: Team pages, blog posts, and case studies should be verified for accurate dates, current team members, and live client references.

Assign content review to someone who knows the business, not just a technical reviewer. A developer cannot verify whether the company's services are described correctly.

Forms: Submission, Notification, and Data

Forms are the most commonly broken element on newly launched websites and the most commercially damaging failure to miss.

• Valid submission test: Submit every form with complete, valid data. Verify the confirmation message appears correctly on screen.
• Notification email receipt: Verify that the notification email is received by the correct recipient within two minutes of submission.
• CRM record creation: Verify that the CRM or database record is created with all form fields mapped to the correct CRM properties.
• Error handling test: Submit forms with invalid data, missing required fields, invalid email format, and verify that error messages are clear and correctly displayed.

Test every form on a mobile device in addition to desktop. Mobile form usability failures are extremely common and easily missed on desktop-only testing.

Navigation and Internal Links

Every navigation item, internal link, and CTA button must be clicked and verified.

• Primary navigation: Click every item in the primary navigation menu across desktop and mobile, including any dropdown or mega-menu items.
• Footer navigation: Verify every footer link destination is correct and returns a 200 status code.
• In-content links: Check every hyperlink in the body content of every page, not just the homepage and top-level pages.
• CTA buttons: Every button on every page must be clicked to verify its destination, whether internal link, form, or external URL.

Redirect Verification

Every URL in the redirect map must be individually tested. Bulk testing is not sufficient, test each redirect against the expected destination.

• 301 status verification: Use a bulk redirect checker or screaming frog to verify that each redirect returns a 301 status code, not a 302, 404, or chain redirect.
• Destination accuracy: Verify that each redirect lands on the correct target page, not just the homepage.
• Chain redirect check: Identify any redirect chains (URL A redirects to URL B, which redirects to URL C) and consolidate them to direct redirects.
• Document all failures: Any redirect that fails, wrong destination, wrong status code, or returning a 404, must be fixed and retested before the launch gate is signed off.

Performance QA

Checking page speed after redesign is a critical QA step that is frequently deferred to post-launch. Performance issues caught on staging are faster and cheaper to address than those discovered after go-live.

Core Web Vitals on Staging

Run Google PageSpeed Insights and Lighthouse on the staging site before launch.

• LCP target: Largest Contentful Paint under 2.5 seconds on mobile. The LCP element on each page template should be identified and optimized specifically.
• CLS target: Cumulative Layout Shift under 0.1. Layout shift issues are often caused by images without explicit dimensions or web fonts loading after initial render.
• FID or INP target: First Input Delay under 100 milliseconds, or Interaction to Next Paint under 200 milliseconds on the updated Core Web Vitals framework.
• Record baseline scores: Document all performance scores on staging for comparison against post-launch scores. Unexpected score drops on the live site indicate a configuration difference.

Image Optimization Verification

Large images are the most common performance failure in newly built sites.

• Format verification: Verify that all images are served in WebP format where supported, with JPEG or PNG fallbacks for older browsers.
• Dimension accuracy: Verify that no image is being displayed at a smaller size than its actual file dimensions. A 2400px wide image displayed at 800px is serving three times the necessary data.
• Lazy loading: Verify that images below the fold have the loading="lazy" attribute applied. Above-the-fold hero images must not be lazy-loaded.
• Total page weight: Check the total page weight of the homepage and primary landing pages using Chrome DevTools. Pages above 3MB on desktop or 1.5MB on mobile require investigation.

Third-Party Script Audit

Every third-party script affects page load time and must be audited before launch.

• Script inventory: List every third-party script installed: Google Analytics, Hotjar, HubSpot, Intercom, chatbots, advertising pixels, and any others.
• Defer non-critical scripts: All non-critical scripts, marketing pixels, chat widgets, heat mapping tools, should be configured to fire after page load, not before.
• Remove redundant scripts: Scripts from the previous site that are no longer needed must be removed from the new site. Legacy scripts from old marketing campaigns are commonly overlooked.
• Impact measurement: Use WebPageTest or Lighthouse to measure the performance impact of each script. Any script adding more than 500ms to page load requires justification.

Security and Infrastructure QA

SSL certificate checklist checks are part of a broader infrastructure review that must be completed before launch.

SSL Certificate and HTTPS

Verify the SSL certificate is valid, correctly configured, and that all page loads redirect from HTTP to HTTPS.

• Certificate validity: Confirm the SSL certificate is valid, not expired, and correctly installed for the live domain.
• HTTPS redirect: Verify that all HTTP requests redirect to HTTPS with a 301 status code, not a 302 or without a redirect.
• www and non-www resolution: Both www.domain.com and domain.com must resolve correctly to the primary domain version without certificate errors.
• Subdomain verification: If the site uses subdomains, blog.domain.com, shop.domain.com, verify SSL is correctly configured for each subdomain.

Robots.txt and Sitemap

A misconfigured robots.txt file that blocks search engines is one of the most common staging-to-production errors in redesign launches.

• Staging disallow removal: Verify that the staging environment's robots.txt disallow-all instruction has been removed or replaced with the correct production configuration.
• Robots.txt accuracy: Confirm that the production robots.txt only disallows pages that should genuinely not be indexed, admin areas, thank-you pages, duplicate parameter URLs.
• XML sitemap accessibility: Verify the sitemap.xml file is accessible at yourdomain.com/sitemap.xml and contains all pages intended for indexation.
• Sitemap submission: The XML sitemap should be submitted to Google Search Console within 24 hours of launch.

Form Spam Protection

Unprotected forms on newly launched sites are typically targeted by bots within hours of launch.

• Honeypot fields: Verify that all forms have hidden honeypot fields that catch bot submissions without affecting real users.
• CAPTCHA implementation: For high-risk forms, contact forms, registration forms, verify that reCAPTCHA v3 or hCaptcha is correctly configured and functioning.
• Submission rate limiting: Verify that forms have submission rate limiting configured to prevent bulk spam submissions from bots that defeat honeypots.
• Test spam protection: Submit a test submission using a bot-mimicking tool or a headless browser to verify that spam protection is functioning correctly.

Analytics and Tracking QA

Google Analytics redesign setup verification is one of the most commercially important QA steps. Analytics tracking failures are silent, they do not cause visible errors, and can result in weeks of missing conversion data before anyone notices.

Google Analytics 4 Configuration

Verify GA4 is installed on every page and configured correctly before launch.

• Universal installation: Use GA4's DebugView or the Google Tag Assistant browser extension to confirm the GA4 tag is firing on every page, not just the homepage.
• Page view events: Verify that page views are recording correctly for all page templates, including thank-you pages and confirmation screens.
• Conversion events: Verify that GA4 conversion events are configured for all primary conversion actions, form submission, phone click-to-call, email click, e-commerce purchase.
• User properties: Verify that any user properties configured in the previous site, user role, account type, are correctly carried over or replaced in the new GA4 configuration.

Google Tag Manager Audit

If GTM is used, audit all tags before launch.

• Tag inventory: Export a list of all tags in the GTM container and verify that only tags required for the new site are active.
• Firing conditions: Verify that each tag has the correct trigger configuration. Tags firing on every page unnecessarily add page load time and tracking noise.
• Preview and debug: Use GTM's Preview mode to verify that every tag fires on the correct page and event, and does not fire where it should not.
• Legacy tag cleanup: Remove any tags from the previous site that are no longer needed. Legacy GTM containers often contain years of redundant tracking code.

Conversion Tracking Verification

Every conversion event must be verified end-to-end before launch.

• Contact form conversion: Submit the contact form and verify the conversion event fires in GA4's DebugView and in any ad platform conversion tracking.
• Thank-you page tracking: Verify that thank-you page and confirmation screen page views are correctly tracked as conversion events or goals.
• E-commerce revenue tracking: For e-commerce sites, complete a test purchase and verify that the transaction event fires with the correct revenue value.
• Phone and email click tracking: Verify that click-to-call links and email address clicks fire the correct tracking events in GA4.

SEO and Search Engine QA

Search Console redesign setup is a post-launch step, but the SEO quality checks that precede it must happen on staging before launch.

Meta Titles and Descriptions

Verify every page has a unique, optimized meta title and meta description.

• Title length: All meta titles should be under 60 characters. Titles that are too long are truncated in search results.
• Title uniqueness: Run Screaming Frog on the staging site and export the meta title report. Flag any duplicate titles for immediate correction.
• Meta description coverage: Verify that every indexable page has a meta description under 155 characters. Missing meta descriptions are replaced by Google with arbitrary page snippets.
• Keyword relevance: Verify that each page's meta title includes the primary keyword for that page, consistent with the keyword map developed in discovery.

Heading Hierarchy

Verify every page has a logical heading hierarchy before launch.

• Single H1 per page: Every page should have exactly one H1 tag containing the primary keyword. Multiple H1s on a single page are an SEO and accessibility failure.
• Hierarchy order: H2s should follow H1s, and H3s should follow H2s, heading tags should not be used for styling purposes that skip levels in the hierarchy.
• H1 content check: The H1 on each page should match the meta title in topic, if not in wording. A mismatch between H1 and meta title creates keyword signal confusion.
• Crawl tool verification: Export the heading data from Screaming Frog to check H1 coverage across the full site in one pass.

Canonical Tags

Canonical tags prevent duplicate content issues and must be verified before launch.

• Self-referencing canonicals: Every indexable page should have a self-referencing canonical tag pointing to its own URL.
• No conflicting canonicals: Verify that canonical tags do not conflict with noindex directives. A canonicalised page that is also noindexed has conflicting signals.
• Paginated content: Verify that paginated pages, blog page 2, 3, 4, are correctly canonicalised if they are not intended to be indexed independently.
• Parameter URLs: Verify that any URLs with tracking parameters are correctly canonicalised to the clean URL version.

Post-Launch QA and Monitoring

Post-launch redesign checklist activities begin the moment the site goes live and continue for at least 90 days.

Immediate Post-Launch Crawl (Within 24 Hours)

Run Screaming Frog on the live site within 24 hours of launch.

• 404 error check: Identify any URLs returning 404 errors that are not accounted for in the redirect map and fix them immediately.
• Redirect chain identification: Identify any redirect chains that appeared between staging and live, these should be consolidated to direct 301 redirects.
• Meta data completeness: Verify that all meta titles and descriptions are present on the live site, staging-to-production deployment can occasionally drop CMS configuration.
• Internal link verification: Check the internal link report for any links pointing to 404 pages or redirected URLs that should be updated to point directly to the final destination.

GSC Coverage Report Check (Days 1 Through 7)

Monitor the GSC Coverage report daily for the first week post-launch.

• New 404 errors: Any 404 errors appearing in GSC that were not present in the pre-launch crawl require immediate investigation and redirect resolution.
• Indexing status: Check that all pages intended for indexation are being crawled and indexed correctly. New sites typically take two to three days for GSC to begin showing new coverage data.
• Sitemap submission status: Verify that the submitted sitemap is being processed correctly and that the reported URL count matches the expected count.
• Excluded pages review: Review the Excluded section of the Coverage report to verify that only the correct pages are being excluded, no accidentally blocked pages.

Analytics Baseline Comparison

Compare Day 1 traffic in GA4 against the equivalent day in the pre-launch period.

• Session volume check: A significant drop in direct or branded traffic on day one may indicate a tracking installation failure, not a real traffic drop.
• Conversion event verification: Verify that conversion events are firing at a comparable rate to the pre-launch period. A sudden drop in conversion events on day one is a tracking failure, not a performance failure.
• Referral traffic check: Verify that known referral sources, email campaigns, social media links, partner sites, are registering correctly in GA4's source attribution.
• Real-time monitoring: Keep GA4 Real-Time open for the first two hours after launch. A flat line of zero sessions indicates a tracking failure that needs immediate investigation.

Conclusion

A QA checklist is not a sign of a slow process, it is the evidence of a professional one.

The time invested in systematic QA before and after launch is always less than the time and cost of fixing avoidable problems after they have affected real users, real analytics data, and real SEO performance. Every category in this checklist represents a class of failures that has cost real businesses real money.

Copy this checklist into a shared document with your agency or development team.

Assign each section to a specific reviewer, set a QA completion deadline 72 hours before your planned launch date, and do not sign off the launch gate until every section is complete.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

LOW/CODE Agency Runs a Structured QA Process on Every Launch

LOW/CODE Agency treats QA as a core deliverable, not a post-build extra. Every redesign goes through a staged QA process: staging environment testing, redirect verification, analytics validation, and post-launch monitoring as standard.

We operate as a strategic product team, not a dev shop.

Your launch gets a dedicated QA review, a written checklist completed before the staging sign-off meeting, and a monitoring plan that begins on launch day.

• Pre-launch staging QA: Full content, form, navigation, and redirect review on the staging environment before the client staging review is scheduled.
• Performance testing: Core Web Vitals testing on staging with Lighthouse and PageSpeed Insights, with scores documented for post-launch comparison.
• Security and infrastructure checks: SSL verification, robots.txt audit, spam protection testing, and HTTPS redirect verification as part of every launch checklist.
• Analytics verification: GA4 installation, GTM audit, conversion event testing, and baseline comparison completed before and immediately after launch.
• SEO launch checks: Meta title and description coverage, heading hierarchy audit, canonical tag verification, and Screaming Frog crawl on the live site within 24 hours.
• Post-launch monitoring: Daily GSC Coverage report checks in week one and weekly monitoring through 90 days post-launch.
• 90-day performance review: Formal comparison of rankings, traffic, and conversion rate against pre-launch baselines at the 90-day mark.

LOW/CODE Agency has delivered 450+ digital products for clients including Coca-Cola, American Express, Sotheby's, Medtronic, Zapier, and Dataiku. Our website redesign QA services ensure every launch is clean, verified, and monitored from day one.

Start with a scoping call