Why You Need a QA Checklist (Not Just a Quick Look)

You've spent weeks — maybe months — building the site. The design is sharp, the content is loaded, and 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. Not with more development time, but with a structured QA process that catches what quick spot-checks miss. According to BugHerd, the most common launch-day failures come from categories that teams simply forgot to test, not from complex technical edge cases.

This checklist covers every category you need 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 are looking for tools to streamline the feedback side of QA, see our roundup of the best website feedback tools in 2026.

1. Functionality and Forms

Forms are the most common source of post-launch bug reports. They involve user input, validation logic, server communication, and confirmation flows — each of which can fail independently.

• 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 that validation messages appear correctly (empty required fields, malformed emails, phone numbers with 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 media icons
• Verify downloads — if the site offers PDFs, assets, or files, 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. As the BrowserStack testing guide emphasises, cross-browser issues account for a significant percentage 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 all 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 — ensure they load correctly and that fallback fonts are acceptable if they don't

3. Mobile Responsiveness

Responsive design isn't just about whether the layout adapts. It's about whether the adapted layout is actually usable.

• 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 guidelines)
• 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. Google uses Core Web Vitals as a ranking signal. Performance isn't optional.

• 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 (LCP) under 2.5 seconds, First Input Delay (FID) under 100ms, Cumulative Layout Shift (CLS) under 0.1
• Verify image optimisation — are images served in modern formats (WebP/AVIF)? Are they appropriately compressed? Are they 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
• Check for unnecessary third-party scripts — each analytics pixel, chat widget, and tracking script adds load time

5. Security Essentials

Security basics are non-negotiable. 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 — no mixed-content warnings on any page
• 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 — 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 surprisingly persistent. 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 all public pages and exclude private/admin pages?
• Verify robots.txt — make sure it's not accidentally blocking important pages (this happens more often than you'd think 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 for broken structured data using Google's Rich Results Test
• Confirm 301 redirects are in place for any changed URLs (especially important for site redesigns)

7. Accessibility

Accessibility isn't just compliance — it's usability for everyone. The Brand Vision QA checklist highlights accessibility as one of the most frequently overlooked launch categories.

• Run an automated audit using Axe, WAVE, or Lighthouse Accessibility — but understand that automated tools catch only about 30-40% of issues
• 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 or highlight 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, or 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 be firing on every page
• Check that page views are tracked correctly — visit several pages and confirm they appear in your real-time analytics 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 or disable any debug/staging tracking that shouldn't be in production
• Confirm cookie consent — if required by GDPR/CCPA, 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 images with watermarks, no "test" filenames visible to users
• Check responsive content — does text truncate awkwardly at certain breakpoints? Do headlines wrap in an odd way on mobile?
• Verify dynamic content — if the site pulls from a CMS or API, ensure the real data is populating correctly (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 that are visible on every single page view

10. Legal and Compliance

Missing legal pages can create liability. Don't treat these 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 you've worked through the technical checklist above, there's one more critical step: getting human eyes on the site. This is the stakeholder review phase, and it catches an entirely different category of issues — subjective problems, content accuracy, brand alignment, and user experience gaps that automated tests and developer self-review will never flag.

The challenge with stakeholder reviews is collecting that feedback in a format developers can act on. As we've written about 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 up their notes in an email — which the research shows produces less nuanced, 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.

This approach turns the stakeholder review from the most chaotic part of QA into the most structured — and it does it without asking non-technical reviewers to learn a new tool or change their natural behaviour.

Making the Checklist Work for Your Team

A checklist only works if you actually use it. Here are 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 that feedback flows in throughout development, not just at the end.

For agencies managing QA across multiple client sites simultaneously, 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're ready 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.