The 2026 Website Launch Checklist: Pre-Launch QA That Catches Real Bugs

A website launch checklist is the structured pre-launch QA pass a team runs in the final 48 to 72 hours before a site goes live — covering functionality, forms, cross-browser behaviour, mobile, Core Web Vitals, SEO, security headers, accessibility, redirects, analytics, and cookie consent. Done well, it surfaces the bugs that would otherwise be discovered by the first cohort of real users — usually at the worst possible moment, on a Tuesday morning, two hours after the launch tweet.

This is not a generic "remember to test things" article. It is the actual checklist Crosscheck recommends to QA leads and engineering managers running launch day QA in 2026, with the numeric thresholds, tooling references, and standards you should be measuring against.

TL;DR — the launch day QA non-negotiables

• Core Web Vitals at the 75th percentile: LCP under 2.5s, INP under 200ms, CLS under 0.1 — Google's official thresholds, last reconfirmed December 2025.
• WCAG 2.2 Level AA quick check — focus indicators, 24×24 CSS pixel touch targets, accessible authentication, no drag-only interactions.
• HTTPS everywhere with HSTS, plus a baseline of five security headers — CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-Frame-Options.
• All redirects single-hop, sitemap submitted, robots.txt verified — staging Disallow: / rules silently kill launches more than anything else.
• Analytics, consent banner, and conversion events validated against the live environment before announcement traffic arrives.
• A bug reporting workflow that captures evidence the first time, because launch week has no time for follow-up questions.

---

How to use this checklist

Three principles before you start.

Test in production, not staging. Staging is a useful approximation, but CDN configuration, SSL certificates, environment variables, third-party API credentials, and caching behaviour diverge across environments. A passing staging test is necessary but not sufficient. Many launch-day incidents — analytics under-counting, third-party widget failures, broken email delivery — are environment differences, not code bugs.

Assign by category, not by page. One person owns cross-browser and mobile. Another owns performance and SEO. A third owns accessibility, security, and analytics. Category ownership means each reviewer goes deep on their area instead of skimming wide and missing the specifics. It also makes incomplete coverage visible the moment someone tries to sign off.

Document pass/fail with timestamps. A checklist held in someone's head is not a QA artefact. Use a shared sheet — Notion, Google Sheets, a Linear cycle, whatever the team already trusts — with each item, the tester, the date, and a link to evidence (a screenshot, a Lighthouse report, a bug ticket). When the launch decision goes to a director or a CTO, the documentation is what makes "we're ready" a defensible statement.

With that frame set, here is what to check.

---

Cross-browser and mobile compatibility

The browser market in 2026 is dominated by three engines — Blink (Chrome, Edge, Opera, Brave), WebKit (Safari on macOS and all iOS browsers), and Gecko (Firefox) — but the engineering implication remains the same as a decade ago: developers default to Chrome, and bugs surface elsewhere.

Layout parity across Chrome, Firefox, Safari, and Edge. Walk the primary pages in each browser. Look for broken grids, overflowing text, misaligned components, and any element that renders differently from the design. Pay particular attention to CSS Grid subgrid, container queries, :has() selectors, and View Transitions — features that landed in different browsers at different times and still have edge cases.

Safari on iOS tested on a real device. Chrome on iOS uses WebKit under the hood because of Apple's App Store rules, so "Chrome on mobile" is not a proxy for iOS Safari behaviour. The differences that matter — viewport unit handling, scroll behaviour, video autoplay rules, PWA install prompts — only surface on actual hardware or in a high-fidelity simulator. BrowserStack, Sauce Labs, and LambdaTest all offer real-device farms; if budget is tight, borrow an iPhone for an afternoon.

Layout at all major breakpoints. Mobile portrait (375px), mobile landscape (667px), small tablet (768px), large tablet (1024px), small desktop (1280px), and large desktop (1440px and up). At each breakpoint, check navigation, content columns, images, modals, and forms for overflow, overlap, or unintended stacking. Browser DevTools device emulation is fine for the first pass — but the final sign-off needs a physical device because pointer events, viewport behaviour, and font rendering all diverge from the desktop simulation.

Touch targets meet 24×24 CSS pixels, ideally 44×44. WCAG 2.2's success criterion 2.5.8 sets the floor at 24×24, while Apple's HIG and Google's Material guidelines both recommend 44×44 or 48×48. Targets smaller than this produce tap misses, fat-finger errors, and silent abandonment — especially on form fields where the abandonment never registers as a complaint.

No horizontal scroll on mobile. Horizontal scroll on a phone is almost always a fixed-width element or an image without a max-width: 100%. Test on a physical device and verify the page is fully contained within the viewport width at every breakpoint.

Fonts load and fall back correctly. Custom fonts loaded via Google Fonts, Adobe Fonts, or self-hosted files should render consistently across browsers. The fallback stack should be readable and close enough in size and weight that the layout does not break if the custom font fails — using font-display: swap or optional is the modern default, with the fallback metrics matched via size-adjust and ascent-override to prevent CLS.

---

Core Web Vitals and performance

Core Web Vitals have been a Google ranking signal since 2021, and the three thresholds Google evaluates at the 75th percentile of real-user data — collected via the Chrome User Experience Report (CrUX) — have not changed in 2026. Google reconfirmed them in its December 2025 documentation update.

INP replaced First Input Delay in March 2024 and remains the hardest metric for most sites to pass. Industry data from 2025 suggests roughly 43% of sites still fail the 200ms INP threshold — almost always because of long JavaScript tasks blocking the main thread during user interactions. INP is not solved by image compression or CDN caching; it requires rethinking how the front end handles event handlers, third-party scripts, and React or Vue render cycles.

Run PageSpeed Insights against three pages. Home, a key conversion page (pricing, product detail, signup), and one content page. Look at the field data (CrUX) if the site has been live in any form, and lab data (Lighthouse) otherwise. Mobile scores carry more weight than desktop because Google uses mobile as the primary ranking signal.

Set internal alert thresholds tighter than Google's. A common pattern is alerting at 80% of the official threshold — LCP > 2.0s, INP > 160ms, CLS > 0.08 — so regressions surface inside the 28-day CrUX window rather than after rankings have already shifted.

Images compressed, sized correctly, and served as WebP or AVIF. Oversized images remain the single most common performance problem on new sites. Serve images at the rendered dimensions, not at 4000px scaled down with CSS. WebP support is universal in 2026; AVIF is supported by Chrome, Firefox, Safari, and Edge. Use the <picture> element or modern frameworks' built-in image components to serve the right format and size per device.

Lazy-load below-the-fold images and iframes. Native loading="lazy" is supported in every modern browser and removes the need for JavaScript libraries. Hero images should never be lazy-loaded — they are typically the LCP element.

JavaScript and CSS minified, code-split, and tree-shaken. Open the Network tab in DevTools and check the largest JS bundle. If a single chunk exceeds 200KB gzipped on a marketing site, the build is shipping more than the user needs. Route-level code splitting and dynamic imports should be the default in any framework newer than 2020.

Third-party scripts deferred or loaded after consent. Analytics, chat, A/B testing, and advertising scripts should be async or deferred, and most consent frameworks (OneTrust, Cookiebot, Iubenda) only load tracking scripts after the user accepts. Check the Network waterfall for any synchronous third-party script in the <head> — those are the ones blocking First Contentful Paint.

CDN configured for static assets with appropriate cache headers. Cloudflare, Fastly, Bunny, AWS CloudFront, or your framework's edge network should be in front of static assets with Cache-Control: public, max-age=31536000, immutable for hashed filenames and shorter TTLs for HTML.

Throttled connection test. In DevTools, throttle to Slow 4G and reload key pages. The page should be visually complete in under five seconds and interactive within seven. If it is not, the largest assets or slowest requests are the place to start.

---

SEO basics — the launch day list

SEO errors introduced at launch can suppress rankings for weeks or months, long after the underlying problem has been fixed. A 90-minute pre-launch SEO pass is the highest-leverage hour in the entire checklist.

Robots.txt verified at the production domain. This is the single most common launch-day disaster — a staging environment's Disallow: / carrying over to production and de-indexing the entire site for days before anyone notices the traffic chart is flat. Open https://yourdomain.com/robots.txt directly in a browser and read it. Do not assume.

XML sitemap present, accurate, and submitted to Google Search Console and Bing Webmaster Tools. The sitemap should be at /sitemap.xml or referenced in robots.txt. It should contain only canonical, indexable URLs — no noindex pages, no redirects, no parameters. Submit it on launch day; this accelerates discovery, particularly for large sites.

Canonical tags set correctly on every page. Every page needs a <link rel="canonical"> pointing to its own URL or to the preferred variant if duplicates exist (trailing slash vs no slash, HTTP vs HTTPS, www vs apex, parameter variants). Without canonicals, search engines may index multiple versions of the same content and split ranking signals.

Unique, accurate title tags and meta descriptions. Title tags under 60 characters, meta descriptions between 140 and 160. Duplicate titles across pages are a crawlability signal that depresses overall performance.

Structured data deployed and validated. At minimum, Organization schema on the home page, BreadcrumbList on internal pages, and the appropriate type on content pages — Article for blog posts, Product for product pages, FAQPage for FAQs, LocalBusiness for locations. Validate every type with the Schema Markup Validator and Google's Rich Results Test. Invalid JSON-LD does not earn rich snippets and can occasionally trigger manual actions.

Open Graph and Twitter Card tags on every page. Specifically og:title, og:description, og:image (1200×630 minimum, under 5MB), og:type, og:url, and twitter:card. Test with the OpenGraph.xyz preview tool or LinkedIn's Post Inspector. The first social share of a launch is what gets seen by the largest number of people; getting the preview wrong is a soft but visible failure.

Heading structure logical and consistent. Exactly one <h1> per page containing the page's primary topic. Subheadings follow a logical hierarchy. Headings used for styling rather than structure confuse crawlers and screen readers alike.

All redirects single-hop and using the right status code. 301 for permanent moves, 302 for temporary. Chains of three or more hops slow page load, waste crawl budget, and dilute link equity. Use a tool like httpstatus.io or curl -IL to verify.

Internal links use absolute or root-relative URLs in production. Mixed-environment links (http://staging.domain.com/page) sometimes survive into production builds and break navigation, leak environment names, or trigger mixed-content warnings.

---

Accessibility — a WCAG 2.2 quick check

WCAG 2.2 was published in October 2023 and adds nine new success criteria to WCAG 2.1, with a stronger focus on cognitive accessibility, mobile interaction, and authentication. In 2026, the regulatory environment around accessibility has tightened materially:

• The European Accessibility Act became enforceable on June 28, 2025, applying to any business serving EU consumers — including non-EU companies — with penalties up to €100,000 or 4% of annual revenue. The harmonised standard (EN 301 549) currently references WCAG 2.1 Level AA, with WCAG 2.2 expected to be incorporated in the next update.
• The ADA Title II rule requires US state and local government entities with populations over 50,000 to meet WCAG 2.1 Level AA by April 24, 2026, with smaller entities following a year later.
• Private ADA Title III lawsuits against US websites have continued climbing year over year. The 2025 WebAIM Million report found that 94.8% of the top one million homepages have detectable WCAG failures — averaging more than 50 errors per page.

A full WCAG 2.2 Level AA audit is a multi-day exercise. A pre-launch quick check is not — it covers the small set of issues that affect the largest number of users and produce the loudest legal exposure.

Run axe DevTools or WAVE on every key page. Both are free browser extensions, both flag a substantial share of the issues an automated scan can detect, and both produce remediation guidance. Automated tools typically catch around 30–50% of WCAG issues; the rest require manual checks.

Keyboard navigation works for every interactive element. Close the mouse. Tab through the page. Every link, button, form field, dropdown, modal, and tab should be reachable in a logical order with a visible focus indicator. Trapped focus inside a modal (no way to escape with Esc or by tabbing out) is a frequent regression. Skip-to-content links should appear when Tab is first pressed.

Focus indicators visible and meet WCAG 2.2's Focus Appearance criterion (2.4.11 / 2.4.12). The default browser focus ring is acceptable; what is not acceptable is the outline: none CSS reset without a replacement style. Focus indicators must have a minimum contrast against the background.

Touch targets at least 24×24 CSS pixels (criterion 2.5.8). Verified earlier in the mobile section — this is the WCAG 2.2 reformulation of the same rule, and it now has legal weight in the EU.

Form fields have associated <label> elements. Placeholder text is not a label. Every input needs a real label tied via for/id, or an aria-label if the visible label is implicit (a magnifying glass icon for search, for example).

Images have meaningful alt text — or empty alt="" for decorative images. A missing alt attribute is worse than an empty one because screen readers will read the filename. Decorative images should explicitly declare themselves decorative with alt="".

Color contrast meets 4.5:1 for normal text and 3:1 for large text. Check with a contrast tool — the Chrome DevTools colour picker, WhoCanUse, or the WAVE contrast checker. Brand colours that fail contrast against the body text background are the single most common pre-launch accessibility issue.

No drag-only interactions (criterion 2.5.7). Sliders, sortable lists, and any other drag-driven UI must offer a non-drag alternative (clickable arrows, keyboard input). This is a new WCAG 2.2 criterion and a frequent gap on bespoke UIs.

Accessible authentication (criteria 3.3.8 / 3.3.9). Login flows must not require a cognitive test the user has to solve from memory. CAPTCHAs have alternatives. Two-factor flows should support copy-paste from password managers.

For a deeper walk through the tooling, see Crosscheck's guide to the best accessibility testing tools for WCAG 2.2.

---

Security headers, SSL, and the basics

Security validation at launch is not a penetration test. It is a check that the small set of headers and policies most attackers probe for is in place — and that nothing is publicly exposed that should not be.

HTTPS enforced site-wide with valid certificate. Verify the SSL certificate is valid, not expiring within 30 days, covers all subdomains in use, and that HTTP traffic redirects to HTTPS via a 301. Tools: SSL Labs, the browser's Security panel.

HSTS header set with a reasonable max-age. Strict-Transport-Security: max-age=31536000; includeSubDomains is the standard. Add preload only after the site has been stable on HTTPS for a few weeks and the domain is intentionally on the HSTS preload list.

No mixed content. Mixed content (HTTP resources loaded on HTTPS pages) breaks the padlock indicator and can block resources from loading. Check the browser console for warnings, and use the Security panel for a full list.

A baseline of five security headers. Run the production URL through securityheaders.com and aim for at least an A grade. The headers that matter:

• Content-Security-Policy (CSP) — restricts which sources can serve scripts, styles, and other resources. Start with Content-Security-Policy-Report-Only if the site is complex; move to enforcement once the report endpoint is clean.
• X-Content-Type-Options: nosniff — prevents MIME-type sniffing.
• Referrer-Policy: strict-origin-when-cross-origin — limits referrer leakage to third parties.
• Permissions-Policy — disables browser features the site does not use (camera, microphone, geolocation, payment).
• X-Frame-Options: SAMEORIGIN — prevents clickjacking via iframes. Modern alternative: frame-ancestors in CSP.

Admin and sensitive URLs not publicly accessible. Probe the obvious ones — /admin, /wp-admin, /.env, /.git, /config, /phpinfo.php, /server-status. Any that return content rather than 403 or 404 are an exposure risk. Tools like Nikto or ffuf automate this.

Forms validated server-side and protected against CSRF. Client-side validation is a UX feature, not a security control. Submit a form with a basic XSS payload (<script>alert(1)</script>) and confirm it is not executed or stored as executable content. CSRF tokens should be present on every state-changing form.

Rate limiting on login, signup, password reset, and contact endpoints. Without rate limiting, credential stuffing and contact-form spam become inevitable in the first 48 hours after launch.

---

Forms, redirects, 404s, and the long tail

The bugs that survive a launch and produce the worst user reactions are rarely the dramatic ones. They are the small frictions — a confirmation message that never appears, a 404 page that looks like a broken deployment, a contact form that silently drops submissions.

Submit every form end to end in production. Required field validation should display field-level errors, not a single message at the top. Submit a complete entry and verify the data reaches the destination — CRM, email inbox, database — with all fields populated and no truncation.

Confirmation states are clear. A blank reload that empties the form is not confirmation. A success message, a redirect to a thank-you page, or both — and the thank-you page is where the conversion event fires for analytics.

Duplicate submissions prevented. Click submit twice in rapid succession. The form should submit once and disable the button after the first click, or use an idempotency key on the server. Duplicate leads and double charges are common consequences of a missing guard here.

Edge-case inputs handled. Long strings, international characters (test something like François@müller.de), plus signs in email addresses, very long text areas, and emoji in name fields. Inputs that break on unusual but valid data produce bad experiences and sometimes vulnerabilities.

404 page is informative and useful. Hit a URL that does not exist. The 404 page should clearly state the page was not found, include primary navigation or a search field, and offer a path back to content. A bare "404 Not Found" with no styling looks like a broken deployment and produces support tickets.

Custom 500 error page exists. Less common to hit during QA, but worth verifying — typically via a deliberate error in a staging environment or a /error-test route.

Redirect map verified. If the launch involves moving from an old site, the redirect map should cover every URL that previously ranked in search, every URL with backlinks, and every URL appearing in old documentation. Use Screaming Frog or Sitebulb to crawl the old site, export the URL list, and check each one redirects to the correct new URL — single-hop, 301, no chains.

Browser back button works correctly. Navigate forward through three pages, then back. Each back navigation should land on the correct page in the correct state — no stale content, no broken layouts, no redirect loops. SPA frameworks are the usual culprits here.

Search returns relevant results. If the site has on-site search, test common queries, misspellings, special characters, and queries with no matches. The empty state matters — "No results for X" with suggestions is much better than a blank page.

---

Cookie consent, analytics, and tracking

Analytics that are not validated before launch produce inaccurate data from day one — and retroactive correction is rarely possible. The baseline you set at launch is what every future comparison will be measured against.

Cookie consent banner present, compliant, and tested. In the EU, the UK, Brazil, California, and an expanding list of jurisdictions, tracking scripts must not load until the user provides explicit, granular consent. The banner must offer "Accept all", "Reject all", and granular category controls as equally prominent options — "Reject all" cannot be hidden two clicks deep. Major frameworks: OneTrust, Cookiebot, Iubenda, Osano, Klaro. Validate with the framework's preview tool plus a manual check that no analytics or marketing cookies fire before consent is granted.

Google Tag Manager configured with consent mode v2. Google's Consent Mode v2 is required for EEA traffic — without it, ad personalisation and conversion modelling stop working. Verify the consent state is being passed correctly using Google Tag Assistant.

Analytics events firing correctly post-consent. Open the site with Google Tag Assistant, Meta Pixel Helper, or GA4 DebugView. Walk the primary user flows — page view, scroll, form submission, purchase, button click — and verify each event fires with the right parameters. The conversion events that matter to the business (lead form, checkout, content download) should map cleanly into the reporting dashboard.

Server-side tracking considered for critical events. Browser-based tracking is increasingly under-counted because of ad blockers, ITP, and privacy-mode browsing. For revenue-critical conversion events, server-side tracking via the GA4 Measurement Protocol or Meta's Conversions API is the modern default — particularly post-iOS 17, where Safari's link-tracking restrictions removed a meaningful slice of attribution data.

UTM parameters preserved through redirects. If the launch involves redirecting old URLs to new ones, verify that UTM parameters survive the redirect. Campaign attribution silently breaks otherwise.

Search Console and Bing Webmaster Tools verified. Both should be set up before launch so that the sitemap can be submitted on day one and indexing problems surface in the first week, not the third.

---

Capturing bugs during the checklist run

The quality of bug reports filed during a pre-launch checklist directly affects how quickly issues get fixed. A developer receiving a report that says "the form doesn't work" has to reproduce the issue from scratch, guess at the browser, and ask follow-up questions before debugging can begin. That back-and-forth costs hours of launch-week time the team does not have.

This is the specific bottleneck Crosscheck addresses. Crosscheck is a free Chrome extension built for QA testers and developers that captures everything at the moment a bug is found: a screenshot or screen recording, every console error, every network request and response, and the browser and OS environment details. When the pre-launch checklist surfaces a broken form submission, Crosscheck has already captured the failed network call, the console error that preceded it, and the exact sequence of interactions that led to the failure.

The reporter gives the bug a title, sets the severity, adds a note if anything needs clarifying — and the report goes straight to Jira, Linear, ClickUp, GitHub, or Slack with full technical context attached. No manual DevTools screenshots. No copy-pasting console output. No follow-up questions from the developer two hours later asking which browser was in use.

For launch week, where time between finding a bug and shipping the fix is measured in hours, complete bug reports are not a marginal efficiency gain. They are often the difference between a bug fixed before launch and a bug deferred to a hotfix after.

---

FAQ

What is a website launch checklist?

A website launch checklist is the structured pre-launch QA pass a team runs in the final days before a site goes live. It covers functionality, forms, cross-browser and mobile compatibility, Core Web Vitals, SEO basics, accessibility, security headers, redirects, analytics, and cookie consent. The goal is to find the bugs before the first real users do.

How long does pre-launch QA take for a typical website?

For a marketing site with 20 to 50 pages and a handful of forms, a thorough pre-launch QA pass is one to two days of work split across two or three people. For a SaaS product launch with authentication, billing, and complex user flows, plan for a week with a dedicated QA owner. Compressing the timeline below those numbers is where launches go wrong.

What is the difference between a launch day QA checklist and a pre-launch QA checklist?

Pre-launch QA happens in the days before go-live and covers the full surface area — functionality, performance, SEO, security, accessibility. Launch day QA is the narrower, real-time pass on the production environment immediately before and after the DNS cutover: DNS propagation, SSL on the live domain, redirects from the old site, analytics firing, and a smoke test of the top user flows. Both are needed.

Which Core Web Vitals thresholds matter for SEO in 2026?

Google's official thresholds, measured at the 75th percentile of real-user data via the Chrome User Experience Report, are: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. These have not changed in 2026. INP replaced First Input Delay in March 2024 and remains the metric most sites fail.

Is WCAG 2.2 legally required in 2026?

WCAG 2.2 is the current recommended standard, but most legal requirements still reference WCAG 2.1 Level AA. The European Accessibility Act (enforceable June 28, 2025) references EN 301 549, which currently incorporates WCAG 2.1 — with WCAG 2.2 expected in the next update. The ADA Title II rule effective April 24, 2026 references WCAG 2.1 Level AA. In practice, building to WCAG 2.2 now is the safe forward-looking choice.

What security headers should be in place at launch?

At minimum: Content-Security-Policy, Strict-Transport-Security (HSTS), X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and X-Frame-Options (or frame-ancestors in CSP). Validate with securityheaders.com and aim for at least an A grade.

---

Start your launch day QA with the evidence already captured

The 2026 version of a website launch is no kinder than the 2021 version. The surface area is larger — more browsers to support, more performance metrics to clear, more accessibility criteria to meet, more privacy regulations to respect, more analytics that need consent before they can fire. The pressure has not eased; it has compounded.

Running this checklist systematically is the best mitigation. Capturing the bugs you find with full technical context the first time is the second-best — and it is where Crosscheck saves teams the most time during launch week. Install the extension before the QA pass, file bugs with screenshots, console logs, and network traces attached, and watch the time between "found a bug" and "shipped the fix" collapse from days to hours.

Try Crosscheck free before your next launch.

For deeper reading on adjacent topics, see Crosscheck's guides to the perfect bug report template, Chrome DevTools performance auditing, and the best bug reporting tools of 2026.