Try it nowFree
    Voice + Replay Feedback

    One embed captures voice, clicks, and scrolls. AI extracts tasks.

    Get started
    Client feedback without the detective workAI Task Extraction & Effort EstimatesCopy-Paste Prompts for Cursor & Claude CodeClient feedback without the detective workAI Task Extraction & Effort EstimatesCopy-Paste Prompts for Cursor & Claude CodeClient feedback without the detective workAI Task Extraction & Effort EstimatesCopy-Paste Prompts for Cursor & Claude CodeClient feedback without the detective workAI Task Extraction & Effort EstimatesCopy-Paste Prompts for Cursor & Claude Code
    QAWeb DevelopmentChecklist

    The Ultimate Website QA Checklist Before Launch

    Mahmoud Halat·March 28, 2026·8 min read

    This article is part of our guide on Mastering UAT for Modern Web Projects.

    Why You Need a QA Checklist

    You've spent weeks (sometimes months) building the site. The design is sharp, the content is loaded, the client is eager to go live. So you click around for ten minutes, everything looks fine, and you launch.

    Then the support emails start. The contact form doesn't work on Safari. The mobile nav covers the CTA on Android. The page takes eleven seconds to load on a 4G connection. An image on the About page still says "placeholder_final_v2.jpg."

    Every one of these issues was preventable, but not by adding more dev time. They were preventable with a structured QA process that catches what spot-checks miss. According to BugHerd, the most common launch-day failures come from categories teams forgot to test, not from complex edge cases.

    This checklist covers what to verify before pushing a site to production. Use it as a living document: copy it, adapt it to your stack, and run through it on every project. If you also need a feedback workflow for stakeholder review, see our roundup of the best website feedback tools in 2026.

    1. Functionality and Forms

    Forms are the top source of post-launch bug reports. Each form involves user input, validation, server communication, and a confirmation flow, and any one of those layers can fail on its own.

    • Test every form on the site: contact forms, newsletter signups, search bars, login/registration, checkout flows.
    • Submit with valid data and verify the submission reaches its destination (email inbox, CRM, database).
    • Submit with invalid data and confirm validation messages appear correctly: empty required fields, malformed emails, phone numbers in wrong formats.
    • Test form behaviour after submission. Does the user see a success message? Are they redirected? Can they accidentally submit twice?
    • Check all links: internal navigation, external links, buttons, CTAs, footer links, social icons.
    • Verify downloads. If the site offers PDFs or assets, confirm they download correctly and aren't corrupted.
    • Test search functionality. Does it return relevant results? What happens with zero results? How does it handle special characters?
    • Check e-commerce flows end-to-end: add to cart, update quantities, apply discount codes, complete checkout with test payment credentials.

    2. Cross-Browser Testing

    Your site needs to work on the browsers your audience actually uses. The BrowserStack testing guide notes that cross-browser issues account for a significant share of user-reported bugs, particularly around CSS rendering and JavaScript API support.

    • Test on the latest versions of Chrome, Firefox, Safari, and Edge at minimum.
    • Include at least one older browser version if your analytics show meaningful traffic from it.
    • Check CSS rendering. Flexbox/grid layouts, custom fonts, animations, transitions, gradients, and backdrop filters can behave differently across engines.
    • Verify JavaScript functionality: interactive elements, form validation, dynamic content loading, third-party widget integrations.
    • Test print stylesheets if the site has printable content (invoices, recipes, articles).
    • Check web fonts. Confirm they load correctly and that fallback fonts are acceptable when they don't.

    3. Mobile Responsiveness

    Responsive layouts can adapt cleanly and still be unusable. Test the actual experience, not just the breakpoints.

    • Test on real devices when possible, not just browser DevTools. Emulators miss touch target issues, real scroll behaviour, and device-specific rendering quirks.
    • Verify all breakpoints: desktop, tablet landscape, tablet portrait, mobile landscape, mobile portrait.
    • Check touch targets. Buttons, links, and interactive elements should be at least 44x44 pixels (Apple's Human Interface Guidelines) or 48x48dp (Google's Material Design).
    • Test navigation. Hamburger menus, dropdown menus, and slide-out panels should open and close reliably on touch.
    • Verify that no horizontal scrolling exists on any page at any breakpoint.
    • Check images. Do they scale correctly? Are appropriately sized images served to mobile devices (srcset/picture element)?
    • Test orientation changes. Rotating from portrait to landscape shouldn't break the layout or lose scroll position.

    4. Performance and Load Testing

    Users expect pages to load in under three seconds, and Google uses Core Web Vitals as a ranking signal.

    • Run Google Lighthouse audits on key pages (home, high-traffic landing pages, conversion pages) and aim for scores above 90.
    • Check Core Web Vitals using PageSpeed Insights: Largest Contentful Paint under 2.5 seconds, First Input Delay under 100ms, Cumulative Layout Shift under 0.1.
    • Verify image optimisation. Are images served in modern formats (WebP/AVIF)? Are they appropriately compressed and lazy-loaded below the fold?
    • Check for render-blocking resources: undeferred CSS and JavaScript in the that delay first paint.
    • Test on throttled connections. Simulate 3G and 4G speeds to catch assets that are too large for mobile networks.
    • Verify caching headers. Static assets should have appropriate Cache-Control headers.
    • Audit third-party scripts. Each analytics pixel, chat widget, and tracking script adds load time.

    5. Security Essentials

    A single missing configuration can expose user data or tank your search rankings.

    • Verify SSL/TLS certificate is installed, valid, and not expiring soon.
    • Confirm all pages load over HTTPS with no mixed-content warnings.
    • Test HTTP-to-HTTPS redirects. Entering http://yoursite.com should redirect to https://.
    • Check security headers: X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, Strict-Transport-Security.
    • Verify form data is transmitted securely with no sensitive data in URL parameters.
    • Check for exposed sensitive files. .env, .git, wp-config.php, backup files, and directory listings should all return 403 or 404.
    • Test authentication flows: password reset, session expiration, logout, and account lockout after failed attempts.

    6. SEO Fundamentals

    Technical SEO mistakes made at launch are hard to undo. Pages get indexed with bad metadata and it can take weeks to correct.

    • Verify unique title tags on every page (50-60 characters, including primary keyword).
    • Check meta descriptions: unique, compelling, 150-160 characters per page.
    • Confirm canonical URLs are set correctly to avoid duplicate-content issues.
    • Test the XML sitemap. Does it exist at /sitemap.xml? Does it include public pages and exclude private/admin pages?
    • Verify robots.txt. Make sure it isn't accidentally blocking important pages (a common slip after migrating from staging).
    • Check heading hierarchy. Each page should have exactly one

      , with logical

      -
      nesting.

    • Verify Open Graph and Twitter Card tags. Share a page on social media and confirm the preview looks correct.
    • Check structured data with Google's Rich Results Test.
    • Confirm 301 redirects are in place for any changed URLs (especially important for site redesigns).

    7. Accessibility

    Accessibility is usability for keyboard users, screen-reader users, low-vision users, and anyone on a hostile network. The Brand Vision QA checklist flags accessibility as one of the most frequently overlooked launch categories.

    • Run an automated audit using Axe, WAVE, or Lighthouse Accessibility. Automated tools catch only about 30-40% of issues, so manual checks still matter.
    • Test keyboard navigation. Can you reach and interact with every element using only Tab, Enter, Escape, and arrow keys?
    • Verify focus indicators. When tabbing through the page, is there a visible outline showing which element is focused?
    • Check colour contrast. Text should meet WCAG 2.1 AA minimums (4.5:1 for normal text, 3:1 for large text).
    • Verify all images have alt text that describes the content. Decorative images should have empty alt="".
    • Test with a screen reader: VoiceOver on macOS, NVDA on Windows, TalkBack on Android. Does the page make sense when read aloud?
    • Check form labels. Every input should have an associated element, not just placeholder text.
    • Verify ARIA roles and landmarks are used correctly and aren't overriding native HTML semantics.

    8. Analytics and Tracking

    Launching without analytics is like opening a store without a cash register. You won't know what's working.

    • Verify analytics is installed. Google Analytics 4, Plausible, Fathom, or your tool of choice should fire on every page.
    • Check that page views are tracked correctly. Visit several pages and confirm they appear in your real-time dashboard.
    • Test conversion tracking. Submit a form, complete a purchase, or perform whatever action represents a conversion, and verify it registers as an event.
    • Verify UTM parameters work. Click a tracked link and confirm the source/medium/campaign data appears correctly.
    • Remove any debug or staging tracking that shouldn't be in production.
    • Confirm cookie consent. If GDPR/CCPA applies, ensure the consent banner appears and that analytics scripts only fire after consent is granted.

    9. Content Review

    Content errors are embarrassing and easy to miss, especially on sites with dozens of pages.

    • Proofread every page. Check for typos, grammatical errors, and placeholder text that was never replaced.
    • Verify all images are final. No placeholder images, no watermarks, no "test" filenames visible to users.
    • Check responsive content. Does text truncate awkwardly at certain breakpoints? Do headlines wrap oddly on mobile?
    • Verify dynamic content. If the site pulls from a CMS or API, ensure the real data is populating (not staging data).
    • Test 404 pages. Type a random URL and confirm the 404 page displays correctly with navigation back to the main site.
    • Check favicon and browser tab title. Small details visible on every page view.

    10. Legal and Compliance

    Missing legal pages can create liability. Don't treat them as an afterthought.

    • Privacy Policy: required if you collect any user data (forms, analytics, cookies).
    • Terms of Service: especially important for SaaS, e-commerce, and membership sites.
    • Cookie Policy and consent banner: required under GDPR for EU visitors and increasingly expected globally.
    • Accessibility statement: recommended, and required for certain organisations.
    • Copyright notice in the footer with the current year.
    • Third-party licensing. If you use stock photos, fonts, or open-source libraries, verify your licenses cover production use.

    The Stakeholder Review Phase

    After the technical checklist, there's one more step: getting human eyes on the site. Stakeholder review catches subjective problems, content accuracy, brand alignment, and UX gaps that automated tests and developer self-review will never flag.

    The hard part is collecting that feedback in a format developers can act on. As we've covered in our guide to reducing revision cycles, the gap between what the reviewer noticed and what the developer received is where most launch delays originate.

    This is where tools like givefeedback.dev fit into the QA process. Instead of asking stakeholders to write notes in an email (which the research shows produces less nuanced and less actionable feedback), you embed a single script tag on the staging site:

    `html `

    Stakeholders can then record voice walkthroughs while navigating the site. Their clicks, scrolls, and hovers are captured as session replay, synchronised with their spoken commentary. AI extracts structured tasks from the recording, so developers receive both the human context and a clear action list.

    The result: stakeholder review goes from the most chaotic part of QA to the most structured, without asking non-technical reviewers to learn a new tool or change how they work.

    Making the Checklist Work for Your Team

    A checklist only works if you actually use it. Three principles to keep it practical:

    1. Assign ownership. Each section should have a named person responsible. "Everyone checks everything" means nobody checks anything.
    2. Time-box the process. A full QA pass on a marketing site should take 2-4 hours, not 2-4 days. If it's taking longer, your checklist is too detailed for your project scope. Scale it down.
    3. Integrate feedback tooling early. Don't wait until the final review to set up your feedback collection. Install it on staging from day one so feedback flows in throughout development, not just at the end.

    For agencies managing QA across multiple client sites at once, our guide on how agencies scale client feedback covers the operational side. For more on structuring your feedback process, see our guide on how to give good website feedback. And if you want to try a voice-first approach to stakeholder QA, check out our pricing plans. The free Hobby tier gives you one project and five feedback sessions, which is enough to test the workflow on your next launch.

    Skip the back-and-forth

    givefeedback.dev captures voice, clicks, and scrolls in one embed — so your clients give specific feedback without a guide.

    Start Free