Website Launch QA Checklist: 40 Things to Test Before Going Live
Launching a website is one of the highest-stakes moments in a product cycle. The days before a launch are also the days when QA shortcuts are most tempting — the deadline is fixed, pressure is high, and the assumption that "it mostly works" gets accepted in place of systematic verification.
That assumption is where launch bugs come from.
This checklist covers 40 specific things to test before a website goes live. The items are organized across ten categories: functionality, forms, navigation, cross-browser, responsive design, performance, SEO, security, accessibility, and analytics and tracking. Run through all 40 before launch day. Assign sections to different team members if time is tight. Document your results so that anyone picking up from where you left off knows exactly what has been checked and what has not.
Let's get into it.
Category 1: Functionality
Functionality testing confirms that every feature on the site does what it is supposed to do. Before launch, the goal is not to run exhaustive test scenarios — it is to ensure that every user-facing feature works end to end without errors.
1. All primary user flows complete without errors
Map out the top three to five things a visitor is supposed to do on the site — sign up, make a purchase, request a demo, download a resource, contact your team. Walk each flow completely, as a new user would, and verify that every step completes without error messages, dead ends, or broken states.
2. Third-party integrations are functional in production
Payment processors, CRM connectors, chat widgets, calendar booking tools — each of these needs to be tested against the production environment, not the staging environment. Credentials, API keys, and webhook endpoints often differ between environments. A passing staging test does not guarantee production works.
3. Email notifications send correctly
Every triggered email — confirmation messages, password resets, welcome sequences — should fire on the correct event, arrive in under two minutes, render correctly in Gmail, Outlook, and Apple Mail, and contain no broken links or placeholder copy.
4. Search functions return relevant results
If the site includes search, verify that it returns results for common queries, handles misspellings gracefully, and displays a clear empty state for queries with no matches. Test edge cases: very short queries, queries with special characters, and queries that match nothing.
5. All interactive elements respond correctly
Every button, toggle, dropdown, tab, accordion, slider, and modal on the site should be clicked or triggered before launch. Interactive elements that do nothing, produce an error, or behave inconsistently are among the most visible launch bugs.
Category 2: Forms
Forms are where visitors convert into leads, customers, or registered users. A broken form at launch means lost conversions, and often means the problem goes unreported because users abandon rather than complain.
6. Required field validation works correctly
Submit every form with required fields left blank. The form should prevent submission and display clear, field-level error messages. Verify that the error indicators (red borders, warning icons, messages) appear adjacent to the relevant field — not only at the top of the page.
7. Form submissions reach the correct destination
Submit a complete test entry through every form on the site. Verify that the data arrives in the expected destination — CRM, email inbox, database — with all fields populated correctly and no data truncation.
8. Confirmation states are shown after submission
After a successful form submission, the user should see unambiguous confirmation: a success message on the page, a redirect to a thank-you page, or both. A blank reload that leaves the form empty is not a confirmation.
9. Duplicate submissions are prevented
Click the submit button twice in rapid succession. The form should submit once and disable the button after the first click. Duplicate submissions are a common source of duplicate leads and double charges.
10. Input fields handle edge-case values
Test long strings in name fields, international characters in address fields, plus signs and subdomains in email fields, and very long content in text areas. Inputs that break on unusual but valid data produce poor user experiences and can expose vulnerabilities.
Category 3: Navigation
Navigation failures are the most immediately visible bugs on any site. A broken link in the primary menu or a redirect that loops is something every visitor encounters, not just those following a specific path.
11. Every navigation link goes to the correct destination
Click every link in the primary navigation, secondary navigation, footer, and sidebar. Verify the destination is correct and the page loads without error. Do this in the production environment — staging URLs sometimes appear in production builds.
12. No broken links anywhere on the site
Run a broken link scan using a tool like Screaming Frog, Ahrefs, or the W3C Link Checker. Broken internal links (404 errors) hurt SEO and damage user trust. Broken external links are a maintenance signal.
13. The 404 page is informative and helpful
Visit a URL that does not exist on the site. The 404 page should clearly explain that the page was not found, include the site's primary navigation or a search field, and provide a path back to content — not just an error message.
14. Redirects work and are not chained
If old URLs have been redirected to new ones (common during redesigns and migrations), verify that each redirect is a single hop — a 301 or 302 that takes the user directly to the destination. Chains of three or more redirects slow page load and cause crawl budget waste.
15. Browser back button works correctly
Navigate forward through three or four pages, then use the browser back button to return. Verify that each back navigation lands on the correct page in the correct state — no stale content, no broken layouts, no redirect loops.
Category 4: Cross-Browser Compatibility
Developers typically work in Chrome. The site should work in all major browsers your visitors use. Each browser engine handles CSS, JavaScript, and web APIs differently — and the differences surface at launch.
16. Layout is consistent across Chrome, Firefox, Safari, and Edge
Open the site in each major desktop browser and walk through the primary pages. Look for layout differences: broken grids, overflowing text, misaligned elements, and components that render differently than designed. Pay particular attention to CSS Grid, flexbox, and custom properties, which have historical inconsistencies across engines.
17. JavaScript-dependent features work in all target browsers
Forms, interactive components, animations, and third-party widgets that depend on JavaScript should be tested in each browser. Console errors in one browser often point to APIs that are not universally supported.
18. Fonts load and fall back correctly in all browsers
Custom fonts loaded via Google Fonts, Adobe Fonts, or self-hosted files should render consistently across browsers. Verify that the fallback font stack is readable and close enough in size and weight that the layout does not break if the custom font fails to load.
19. Video and media playback works across browsers
If the site includes video content, verify that it plays in Chrome, Firefox, Safari, and Edge. Safari requires H.264 encoded MP4 files; it does not support VP8/VP9 WebM without a polyfill. Autoplay behavior also differs — always mute autoplayed videos.
20. Safari on iOS is specifically tested
Safari on iOS runs on a distinct engine (WebKit) and accounts for a significant share of mobile traffic. Chrome on iOS also uses WebKit — so "Chrome on mobile" is not a proxy for iOS behavior. Test on a real iOS device or a reliable iOS simulator.
Category 5: Responsive Design
Responsive testing is not a single pass on a narrow browser window. It is a systematic check of the site's behavior at every viewport breakpoint that affects layout decisions, on multiple device types.
21. Layout is correct at all major breakpoints
Test at mobile portrait (375px), mobile landscape (667px), tablet (768px and 1024px), and desktop (1280px and above). At each breakpoint, verify that navigation, content columns, images, and interactive elements render correctly without overflow, overlap, or unintended stacking.
22. The mobile navigation is fully functional
On mobile viewports, the hamburger menu or drawer navigation should open and close correctly, all links within it should be tappable, and the menu should dismiss when a link is selected. Verify that the navigation is not obscured by any fixed elements.
23. Touch targets are appropriately sized on mobile
Buttons, links, and form fields that are tapped on mobile should meet the minimum touch target recommendation of 44x44 pixels. Targets smaller than this produce tap misses and user frustration. Check interactive elements throughout the site on an actual mobile device, not only in a desktop browser's device emulation mode.
24. Images scale correctly at all sizes
Images should scale within their containers without stretching, pixelating, or overflowing. Verify that hero images, product images, and inline content images render sharply on high-density displays (retina / HiDPI screens) and do not cause horizontal scroll on narrow viewports.
25. No horizontal scroll on mobile
Horizontal scroll on mobile is almost always a bug. It typically results from a fixed-width element, an image without a max-width, or a table that does not reformat for small screens. Test on a physical device and verify that the page is fully contained within the viewport width.
Category 6: Performance
Page speed is a ranking factor, a conversion factor, and a user experience factor. Slow sites lose visitors before they see any content. Pre-launch performance checks establish a baseline and catch the most common causes of slow load times.
26. Core Web Vitals pass acceptable thresholds
Run the site through Google PageSpeed Insights or Lighthouse. Verify that Largest Contentful Paint (LCP) is under 2.5 seconds, Cumulative Layout Shift (CLS) is under 0.1, and Interaction to Next Paint (INP) is under 200 milliseconds. These are the metrics Google uses for ranking; failing them affects organic visibility from day one.
27. Images are compressed and sized correctly
Oversized images are the most common performance problem on new websites. Every image should be served at the display dimensions it will be rendered at — not uploaded at 4000px and scaled down in CSS. Use WebP or AVIF formats where supported. Verify that image compression has been applied without visible quality degradation.
28. JavaScript and CSS are minified in production
Production builds should output minified JavaScript and CSS files. Verify this by opening the page source or the Network tab in DevTools. Unminified production assets suggest that the build process is not running correctly.
29. Third-party scripts do not block page load
Scripts for analytics, chat, A/B testing, and advertising should be loaded asynchronously or deferred. Synchronous third-party scripts in the <head> block HTML parsing and delay Time to Interactive. Check the Waterfall view in the Network tab for any script that is blocking rendering.
30. The site loads acceptably on a simulated slow connection
In Chrome DevTools, throttle the network to "Fast 3G" and reload key pages. The page should be visually complete within four to five seconds and usable within six. If it is not, identify the largest assets or slowest requests responsible and address them before launch.
Category 7: SEO
SEO errors introduced at launch can suppress rankings for weeks or months — long after the technical problem has been fixed. A pre-launch SEO check costs an hour and prevents problems that are expensive to reverse.
31. Every page has a unique, descriptive title tag and meta description
Open the page source or use a browser extension to check title and meta description tags on every key page. Title tags should be under 60 characters and describe the page accurately. Meta descriptions should be under 160 characters and provide a reason to click. Duplicate or missing tags are a crawlability signal that depresses performance.
32. The canonical tag is set correctly on every page
Every page should have a <link rel="canonical"> tag pointing to its own URL (or to the preferred version if there are multiple URL variants). Without canonical tags, search engines may index duplicate versions of pages — particularly common with URL parameters, trailing slashes, and HTTP/HTTPS variants.
33. The robots.txt file is configured correctly
Verify that robots.txt exists at the root of the domain and does not accidentally block pages that should be indexed. It is common for staging environments to use Disallow: / in robots.txt, and for that configuration to carry over to production.
34. The XML sitemap is present and submitted to Google Search Console
Verify that the sitemap exists at /sitemap.xml (or the URL specified in robots.txt), contains all intended pages, and does not include noindex pages or redirects. Submit it to Google Search Console at launch to accelerate indexing.
35. Heading structure is logical and consistent
Every page should have exactly one <h1> tag containing the primary topic of the page. Subheadings should follow a logical hierarchy (h2 for main sections, h3 for subsections). Heading tags used for styling purposes rather than semantic structure confuse crawlers and screen readers alike.
Category 8: Security
Basic security validation belongs in the pre-launch checklist. Discovering that a contact form stores submissions in plaintext, or that an admin URL is publicly accessible, after launch is a significantly worse experience than finding it before.
36. HTTPS is enforced site-wide with no mixed content
Verify that the SSL certificate is installed and valid, that HTTP requests redirect to HTTPS, and that there is no mixed content (HTTP resources loaded on HTTPS pages). Mixed content warnings in Chrome break padlock indicators and can block some resources from loading. Use a tool like Why No Padlock or the browser's Security panel to check.
37. Admin and sensitive URLs are not publicly accessible
Admin panels, CMS login pages, configuration files, and environment files should not be accessible without authentication. Test URLs like /admin, /wp-admin, /.env, /config, and /phpinfo.php. Any that return content rather than a 403 or redirect represent an exposure risk.
38. Form inputs are validated server-side
Client-side validation is a UX feature, not a security control. Verify that the server rejects invalid, oversized, or malicious input regardless of what the browser sends. Test by submitting a form with a simple XSS payload (<script>alert(1)</script>) and confirming that it is not executed or stored as executable content.
Category 9: Accessibility
Accessibility is a legal requirement in many jurisdictions and a quality signal in all of them. The most impactful accessibility checks can be completed in under an hour and fix the issues that affect the largest number of users.
39. Keyboard navigation works for all interactive elements
Close your mouse and navigate the site using only the Tab key. Verify that every interactive element — links, buttons, form fields, dropdowns, modals — is reachable in a logical order and has a visible focus indicator. Tab through all navigation, complete a form, and trigger any interactive components. If any element is unreachable by keyboard, it is inaccessible to keyboard-only users and most screen reader users.
Category 10: Analytics and Tracking
Analytics that are not verified before launch produce inaccurate data from day one. Retroactive data correction is rarely possible; the baseline you set at launch is the baseline you use for all future comparison.
40. Analytics events and conversion tracking fire correctly
Open the site with your analytics debugger active (Google Tag Assistant, Meta Pixel Helper, or the GA4 DebugView). Complete the primary user flows — page view, form submission, purchase, button click — and verify that each expected event fires with the correct parameters. Confirm that the goal or conversion events that matter to the business (lead form submission, checkout completion, content download) are tracked and flowing into the reporting dashboard. A launch with unverified tracking is a launch without data.
How to Run This Checklist Efficiently
Forty items across ten categories is manageable if the work is distributed and documented.
Assign by category, not by page. Give one person functionality and forms, another navigation and cross-browser, another performance and SEO. Category-based ownership means each reviewer goes deep rather than wide, and is less likely to miss items within their area.
Test in the production environment. Staging environments differ from production in ways that matter: CDN configuration, SSL certificates, environment variables, third-party API credentials, and caching behavior are all candidates for divergence. Many launch bugs are staging-to-production differences, not code bugs.
Document pass/fail for every item. A checklist that exists only as a mental note is not a QA artifact. Maintain a shared document — a spreadsheet, a Notion table, a test management tool — where each item has a status, a tester name, and a date. If a launch is delayed or an item is deferred, the documentation makes the decision visible.
File bugs immediately, with complete context. When you find something during the checklist run, file it immediately with everything a developer needs to reproduce and fix it: the URL, the steps taken, the expected behavior, the actual behavior, the browser and OS, and any relevant console errors or network failures. Bugs that go into a queue as "navigation feels off" get deprioritized. Bugs with full technical context get fixed.
Capturing Bugs During the Checklist Run
The quality of bug reports filed during a pre-launch checklist directly affects how quickly issues are resolved. A developer receiving a report that says "the form doesn't work" has to reproduce the issue from scratch, guess at what browser was used, and ask follow-up questions before they can even begin debugging. That back-and-forth costs hours under launch deadline pressure.
This is the specific workflow problem that Crosscheck solves. Crosscheck is a browser extension built for QA testers that captures everything at the moment a bug is found: a screenshot or full session replay, every console error, every network request and response, and complete browser environment details. When you find a broken form submission during your pre-launch checklist run, Crosscheck has already captured the failed network request, the console error that preceded it, and the exact sequence of interactions that led to the failure.
You give the bug a title, set the severity, add a note if needed — and it goes to Jira, ClickUp, Linear, or wherever your team works, with full technical context attached. No manual DevTools screenshots. No copying and pasting console output. No follow-up questions from the developer.
For launch week, where time between finding a bug and having it fixed is measured in hours, the difference between a complete bug report and an incomplete one is not a minor efficiency gain — it is often the difference between a bug getting fixed before launch and getting deferred to a hotfix after.
Try Crosscheck free before your next launch and see how much faster the reporting step becomes when the evidence is captured automatically.
The Bottom Line
A website launch QA checklist is not a sign of distrust in your development team. It is a recognition that the surface area of a modern website — across browsers, devices, integrations, and user paths — is larger than any individual can hold in working memory during a high-pressure launch week.
The 40 items in this checklist cover the categories where launch bugs most commonly appear: functionality and forms, navigation, cross-browser and responsive behavior, performance, SEO, security, accessibility, and tracking. Run through them systematically, document your results, and file complete bug reports for everything you find.
The investment is a few hours. The return is a launch you can stand behind.
