Website Quality Assurance Checklist for Launch

SECTION 01

Define coverage and severity before testing

List priority journeys such as finding a service, submitting an inquiry, purchasing, creating an account, locating support, and editing content. For each, name devices, browsers, roles, data states, third-party dependencies, analytics events, and consequence of failure. Focus first on the journeys that affect revenue, access, privacy, or business continuity.

Agree severity rules. A blocked checkout, inaccessible primary navigation, exposed secret, wrong canonical across the site, or lost lead should normally block launch. A minor spacing inconsistency may not. Record accepted issues with an owner and date instead of allowing informal exceptions to disappear.

SECTION 02

Content, responsive, and functional checklist

Test with final or production-like content. Long names, empty fields, large images, special characters, missing optional data, validation errors, and slow responses expose problems that placeholder content hides. Verify every component state, not only the default desktop view.

For forms and integrations, prove success and failure. Confirm required fields, validation, duplicate submission protection, spam controls, privacy disclosure, confirmation, delivery to the right system, monitoring, and a recovery queue when the destination rejects or times out.

SECTION 03

Accessibility checklist based on WCAG 2.2

WCAG 2.2 provides testable success criteria across perceivable, operable, understandable, and robust content. Select the target level appropriate to the organization and applicable obligations with qualified advice. Automated tools find only certain rule patterns; they cannot judge whether alternative text conveys purpose or a journey makes sense.

Test the site's main journeys with keyboard alone and with representative screen-reader combinations. Verify visible focus, logical order, skip mechanisms, semantic headings and landmarks, accessible names, status announcements, error identification, reflow, contrast, target size, motion controls, captions, and authentication behavior as applicable.

SECTION 04

Performance and security checklist

Google's Core Web Vitals measure real-world loading, interactivity, and visual stability through LCP, INP, and CLS. Test representative pages with realistic content, cache states, networks, devices, consent choices, and third-party scripts. Establish budgets for images, fonts, JavaScript, and external tags, then monitor field data after launch.

Use a threat-informed security checklist aligned with the site's functions. OWASP ASVS can support verifiable web security requirements. Review authentication, authorization, session behavior, input handling, file upload, secrets, dependencies, headers, error exposure, logging, backups, administrative access, and business-logic abuse. Scope authorized security testing carefully.

SECTION 05

SEO, redirects, consent, and analytics checklist

Crawl the site and verify status codes, indexability, titles, descriptions, headings, canonical URLs, robots directives, XML sitemaps, structured data, internal links, image references, pagination where relevant, and language annotations where used. For a redesign, compare every valuable old URL with an intentional keep, redirect, or retire decision.

Validate analytics in the browser and destination reports. Events should fire once, use consistent parameters, respect consent behavior, and map to actual business definitions. Filter or identify internal and test activity according to the analytics plan. Document who owns future tag changes because third-party scripts affect privacy, security, and performance.

SECTION 06

CMS, launch, and post-launch checklist

Have actual editors create, preview, schedule, publish, update, unpublish, and recover content. Test role boundaries and media handling. Confirm the organization owns domain, DNS, repository, hosting, CMS, analytics, integrations, backups, and licensed assets, with multi-factor authentication and recovery contacts.

Rehearse deployment and rollback, define a content freeze, back up and test restoration, lower DNS time-to-live if appropriate, schedule support, and prepare communication. Immediately after launch, verify DNS, TLS, key journeys, forms or orders, redirects, sitemap, robots, canonical, analytics, monitoring, logs, and performance. Continue monitoring because field and indexing effects emerge over time.

1. 01

   Approve the release candidate and known-issue register.

2. 02

   Complete backup, migration, deployment, and rollback rehearsal.

3. 03

   Launch with named technical, content, marketing, and business owners.

4. 04

   Run production smoke tests and reconcile real submissions.

5. 05

   Monitor errors, uptime, field performance, search, and conversions.

6. 06

   Hold a post-launch review and close or schedule remaining issues.

SECTION 07

Frequently asked questions