The short version
Key takeaways
- Test complete user journeys with real content and realistic devices.
- Assign evidence and an owner to every launch gate.
- Prepare rollback and monitoring before changing production.
Content and decision quality
- Verify names, contact details, hours, locations, prices, availability, claims, disclosures, and dates.
- Confirm each page has one descriptive title, a useful introduction, logical headings, and an intentional next step.
- Check authorship, review date, references, image rights, alt text, and internal links.
- Remove placeholders, duplicate pages, empty archives, test accounts, and draft navigation items.
Journeys, forms, and error states
Test primary journeys from landing page to completion: research, search, contact, phone, signup, booking, purchase, document download, and account access where applicable. Test validation, required fields, confirmation, email delivery, duplicate submission, keyboard use, slow connection, and failure.
Use real recipient addresses and verify ownership. A form that displays “success” while no message is delivered is a launch blocker.
Responsive and accessibility review
- Test keyboard navigation, visible focus, skip link, menu, dialogs, forms, filters, tables, and expandable content.
- Check heading order, landmarks, labels, instructions, errors, contrast, zoom, reflow, motion preferences, and touch targets.
- Review common desktop, tablet, and mobile widths in portrait and landscape.
- Look for clipping, horizontal overflow, unexpected layout shifts, and content hidden by sticky elements.
Use automated checks to find patterns, then complete manual task testing. WCAG 2.2 success criteria are the standard reference; an automated score alone cannot establish conformance.
Crawl and technical discovery
Verify one canonical HTTPS URL per page, indexable status, useful titles and descriptions, crawlable links, appropriate structured data, Open Graph metadata, robots.txt, and XML sitemap. Confirm 404 responses, redirects, trailing-slash policy, and host normalization.
Crawl the release and check broken internal links, redirect chains, duplicate titles, missing descriptions, orphaned pages, and accidental noindex. Structured data must match visible content.
Performance, security, and recovery
Compress assets, remove unused dependencies, set caching, prevent layout shifts, defer noncritical scripts, and test from an uncached session. Review security headers, TLS, secrets, file permissions, admin exposure, dependency status, backups, restore instructions, and log access.
Record the active release identifier and create a verified recovery point. Define who can roll back, what data must not be overwritten, and how contact or transaction data created after launch will be preserved.
Launch and observe
Re-read production state immediately before deployment, deploy through the established workflow, and verify the active release, public routes, forms, redirects, sitemap, robots, health, and authenticated journeys when applicable. Watch server errors, delivery failures, analytics anomalies, and real-user reports.
Assign post-launch owners and a review window. A launch checklist is complete only when the production experience—not merely the build artifact—has been verified.
Common questions
Frequently asked questions
Should a launch be delayed for minor visual defects?
Prioritize by user impact. Broken journeys, misleading content, accessibility blockers, security issues, and data loss risks should block launch; cosmetic issues can be documented when they do not undermine trust or use.
What is the minimum rollback evidence?
A known previous release or verified backup, clear activation steps, ownership, and proof that required data will be preserved.
References and examples
Primary sources and product examples used to ground this guide. Product links are editorial references, not endorsements.