How to test a website before launch: pre-launch QA checklist

Testing a website before launch means running a structured series of checks across functionality, performance, accessibility, content accuracy, SEO hygiene, and real-user behavior before any traffic hits the live URL. Done well, it catches the issues that damage first impressions and search rankings before they reach your audience.

This guide walks through every layer of pre-launch testing with a practical checklist your product or UX team can work through in the two weeks before go-live.

Why pre-launch testing is a separate discipline

Most teams do some form of QA during development. Pre-launch testing is different: it validates the site as an integrated whole, not individual features in isolation. A button that works in Figma, passes unit tests, and looks fine in staging can still fail when a real user tries to complete a goal on an actual device with a variable network connection.

Pre-launch testing also closes the gap between technical correctness and real-world usability. A form can submit successfully and still confuse half your target audience. That confusion costs conversions, support tickets, and sometimes search rankings.

Pre-launch testing checklist by category

Use this checklist as a working document. Assign an owner and a target completion date to each section.

1. Functionality and forms

All navigation links resolve to the correct destination with no 404s
Forms (contact, signup, checkout, search) submit successfully and trigger confirmation messages
Form validation catches empty required fields, invalid email formats, and special characters
Error states display helpful, not generic, messages
CTAs link to correct pages or trigger correct modals
Redirects from old URLs to new URLs return 301 (not 302)
Login, account creation, and password reset flows work end to end
Third-party integrations (CRM, chat, analytics) are receiving data

2. Cross-browser and cross-device

Tested on Chrome, Firefox, Safari, and Edge on desktop
Tested on iOS Safari and Android Chrome on real devices
Layout does not break at common responsive breakpoints (320px, 768px, 1280px, 1440px)
Images, fonts, and icons render correctly across all browsers
Videos and embedded media play without errors
Touch targets are at least 44x44px on mobile

3. Performance

Lighthouse performance score is 80 or above on mobile
Core Web Vitals: LCP under 2.5s, INP under 200ms, CLS under 0.1
Images are compressed and served in modern formats (WebP or AVIF)
JavaScript and CSS are minified and non-critical scripts are deferred
Caching headers are configured correctly
CDN is active and serving assets from edge nodes

Tools to use: Google PageSpeed Insights and WebPageTest both give free, detailed performance reports against real user devices.

4. Accessibility

Accessibility failures carry legal risk in most jurisdictions and affect a significant share of your visitors. Run a combination of automated and manual checks.

Automated scan with axe DevTools or WAVE returns zero critical violations
All images have descriptive alt text (decorative images use empty alt="")
Heading hierarchy is logical (H1 once per page, then H2, H3 in order)
Color contrast meets WCAG 2.1 AA (4.5:1 for body text, 3:1 for large text)
Keyboard navigation works for all interactive elements without requiring a mouse
Focus indicators are visible on all interactive elements
Form fields have associated labels (not just placeholder text)
Error messages are associated with their fields programmatically

5. SEO and metadata

6. Content and copy

No placeholder text (Lorem Ipsum) appears anywhere on the site
Legal pages are present: privacy policy, terms of service, cookie notice
Copyright year is correct
All images have final, licensed versions (no comps or stock watermarks)
Phone numbers, email addresses, and physical addresses are accurate
Social media links open the correct profiles
All blog posts, case studies, or landing pages have final approved copy

7. Analytics and tracking

A site can launch and immediately generate data that cannot be recovered. Set up tracking before go-live.

Google Analytics 4 property is receiving pageview data
Conversion events (form submissions, purchases, signups) are firing correctly
Google Tag Manager container is published with the correct configuration
Any advertising pixels (LinkedIn, Meta) are firing on the correct pages
Cookie consent banner is correctly gating tags based on user choice

Where real-user testing fits in

The checklist categories above can be completed largely by your internal team. Real-user testing is the layer you cannot substitute with tooling.

Schedule at least one round of moderated or unmoderated usability testing before launch to answer:

Can your target audience find the key information they came for?
Do your CTAs communicate what happens when clicked?
Where do users hesitate, backtrack, or drop off?
Does the navigation structure match how users think about your content?

Five to eight participants from your target profile will surface the majority of critical issues. For B2B products, this means recruiting from the right buyer role and industry, not just general web users.

Platforms like CleverX give product teams direct access to 8M+ verified B2B and B2C participants across 150+ countries. You can recruit to a precise profile (job title, company size, industry, technology stack), run AI-moderated sessions, and get results in days rather than weeks, which fits the compressed timeline before a launch.

For a deeper look at tool options for this stage, see best website testing tools in 2026.

How to structure your two-week pre-launch testing timeline

Days before launch	Activity
14 to 10 days	Functional QA: links, forms, redirects, integrations
10 to 7 days	Cross-browser and device testing; fix layout issues
7 to 5 days	Performance optimization; accessibility audit
7 to 5 days	SEO metadata and technical SEO audit
5 to 3 days	User testing sessions with target audience (5 to 8 participants)
3 to 2 days	Analytics verification; fix issues surfaced by user testing
1 day	Final smoke test across all critical paths

Common issues found in pre-launch testing

Broken redirects from the old site. If you are replacing an existing site, map every URL that receives inbound links or organic traffic to a valid 301. Missing redirects hand traffic and link equity to 404 pages.

Performance failures on mobile. A site that scores 95 on desktop can score 45 on mobile if images are not served responsively and scripts are not deferred. Run Lighthouse on mobile specifically, not just desktop.

Staging noindex still live. Development environments often add <meta name="robots" content="noindex"> to prevent accidental indexing. It is easy to deploy this tag to production. A Screaming Frog crawl of your staging and production environments will catch it.

Form validation gaps. QA testers often use valid test data, which means edge cases (special characters in name fields, international phone formats, very long strings) are not exercised. Use boundary testing: submit every form with empty fields, malformed email addresses, and excessively long inputs.

Accessibility issues in interactive components. Carousels, accordions, modals, and custom dropdowns frequently fail keyboard navigation and screen reader tests even when they look correct visually. Test these components specifically with keyboard-only navigation and with VoiceOver or NVDA.

Pre-launch testing vs ongoing testing

Pre-launch testing answers “is this ready to ship?” Ongoing testing answers “is this working as well as it should?” Both matter, but they operate on different timelines.

After launch, move to continuous monitoring: set up uptime alerts, track Core Web Vitals in Google Search Console, and schedule regular rounds of user testing tied to major content or feature changes.

For structured approaches to ongoing research, see how to do usability testing effectively: a UX researcher’s playbook and what is a usability test. For testing prototypes before development is even complete, prototype testing guide: best practices for effective user validation covers the earlier stage.

Frequently asked questions

How long before launch should you start website testing? Start functional and content QA at least two weeks before your go-live date. Reserve the final week for performance testing, accessibility audits, and a round of real-user testing. Leaving testing to the last 48 hours almost always surfaces issues too late to fix safely.

What is the difference between QA testing and user testing for a website? QA testing checks whether the site works as specified: broken links, form validation, load speed, browser compatibility. User testing checks whether real visitors can complete key tasks without confusion. Both are necessary before launch, but they catch different classes of problems.

How many users do you need for pre-launch usability testing? Five to eight participants will surface the majority of critical usability issues on a new website. If you have distinct audience segments, run five participants per segment. For B2B sites, recruit from your actual buyer profile rather than general consumers.

Do you need to test a website on mobile before launch? Yes. Mobile accounts for more than half of global web traffic, and Google uses mobile-first indexing. Test on at least two real devices alongside emulators, covering iOS Safari and Android Chrome as a minimum.

What SEO checks belong in a pre-launch QA checklist? Verify that page titles and meta descriptions are unique and within character limits, canonical tags are set correctly, the XML sitemap is valid and submitted, robots.txt is not blocking crawlers, and no staging-environment noindex tags remain. Check that redirect chains are resolved and all 301s point to the correct final URLs.

What tools are commonly used for pre-launch website testing? Common tools include Lighthouse or WebPageTest for performance, axe or WAVE for accessibility, Screaming Frog for technical SEO and crawl analysis, BrowserStack for cross-browser testing, and a user research platform with a built-in participant panel for live usability sessions.