Website QA intelligence for teams who ship
Guides Tool Comparisons QA Glossary Archive RSS Feed
HomeGuidesThe Ultimate Website Launch Checklist for QA Teams in 2026

The Ultimate Website Launch Checklist for QA Teams in 2026

A structured pre-launch testing plan that covers functionality, performance, security, SEO, and compliance

Last updated: 2026-05-15 05:02 UTC 13 min read
Key Takeaways
  • Why Every Website Launch Needs a QA Checklist
  • Functionality and Content Checklist
  • Performance and SEO Checklist
  • Security and Compliance Checklist
  • Infrastructure and DNS Checklist

Why Every Website Launch Needs a QA Checklist

A website launch is a high-stakes event. Everything your team has built over weeks or months becomes public in a single moment. Without a structured checklist, critical items get missed - not because your team is careless, but because launches involve dozens of interconnected systems and the cognitive load exceeds what any individual can track.

The best launch checklists share these characteristics:

  • They are specific and actionable. "Test the website" is not a checklist item. "Verify all contact form submissions reach the correct email inbox" is.
  • They assign ownership. Every item has a person responsible for verifying it.
  • They define pass/fail criteria. What does "working" mean for each item? A Lighthouse score above 90? Zero console errors? All links returning 200 status codes?
  • They are versioned and improved. After every launch, add items for anything that was missed.

This guide provides a comprehensive checklist organized by category. Adapt it to your specific project - not every item applies to every site, and your site likely has domain-specific items to add. The goal is to give you a strong starting template that covers the categories teams most commonly overlook.

Start your checklist review two weeks before launch. Items discovered on launch day are exponentially more stressful and expensive to fix than items found during a structured pre-launch period.

Functionality and Content Checklist

These are the foundational checks that verify your website works as intended.

Navigation and links:

  • All navigation menu items link to the correct pages
  • Run a broken link checker (Screaming Frog, W3C Link Checker, or linkinator) across the entire site. Zero broken links on launch.
  • Footer links are correct and complete
  • Logo links to the homepage
  • Breadcrumbs display correctly and link to the right pages

Forms and interactive elements:

  • Every form submits successfully and data reaches its destination (CRM, email inbox, database)
  • Form validation works on all fields - test required fields, email format, phone format
  • Form confirmation messages/pages display after submission
  • Search functionality returns relevant results and handles empty queries gracefully
  • All modals, accordions, tabs, and carousels function correctly

Content review:

  • No placeholder text (Lorem ipsum) remains anywhere on the site
  • All images have meaningful alt text
  • No broken images or missing media files
  • Copyright year is current (2026)
  • Legal pages are present: Privacy Policy, Terms of Service, Cookie Policy
  • Contact information is accurate: phone numbers, email addresses, physical addresses

Cross-browser verification: Test all critical user journeys in Chrome, Firefox, Safari, and Edge on both desktop and mobile.

Performance and SEO Checklist

Performance and SEO issues discovered after launch mean lost traffic and poor first impressions with search engines.

Performance checks:

  • Lighthouse performance score > 90 on mobile for all key pages
  • Core Web Vitals in "Good" range: LCP < 2.5s, INP < 200ms, CLS < 0.1
  • Images are optimized: served in WebP/AVIF format, properly sized, lazy-loaded (except above-the-fold images)
  • CSS and JavaScript are minified and compressed (gzip or Brotli)
  • Fonts are preloaded and use font-display: swap
  • No render-blocking resources in the critical path
  • CDN is configured and serving assets from edge locations

SEO checks:

  • Every page has a unique <title> tag (50-60 characters)
  • Every page has a unique <meta name="description"> (120-155 characters)
  • Heading hierarchy is correct: one <h1> per page, logical <h2>-<h6> nesting
  • robots.txt allows search engine crawling (verify it does not block critical pages)
  • XML sitemap is generated, accurate, and submitted to Google Search Console
  • Canonical URLs are set correctly on all pages
  • Structured data (JSON-LD) is valid - test with Google's Rich Results Test tool
  • Open Graph and Twitter Card meta tags are present for social sharing
  • 301 redirects are in place for any URLs changing from the previous site version

Indexing readiness: If launching a new site, verify the noindex tag used during development is removed from production. This is one of the most common launch-day oversights.

Security and Compliance Checklist

Security and compliance issues found post-launch can have legal and financial consequences beyond just fixing the bug.

Security essentials:

  • SSL/TLS certificate is installed and valid. All pages served over HTTPS. HTTP requests redirect to HTTPS.
  • Security headers are configured: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security
  • No sensitive information exposed in HTML source, JavaScript files, or API responses (API keys, database credentials, internal URLs)
  • Admin and staging URLs are not accessible from production
  • File upload functionality (if any) validates file types and sizes server-side
  • SQL injection and XSS protections are in place - test form inputs with common attack strings

Privacy and compliance:

  • Cookie consent banner displays on first visit and functions correctly (accept, reject, customize)
  • No non-essential cookies are set before user consent (verify with browser DevTools)
  • Privacy policy is current and accurately describes data collection practices
  • Data subject request process is functional (GDPR right to access, right to deletion)
  • Analytics tracking respects user consent preferences

Accessibility compliance:

  • Run automated accessibility audit (axe-core) with zero critical or serious violations
  • Keyboard navigation works for all interactive elements
  • Screen reader testing on key pages (using NVDA, VoiceOver, or JAWS)
  • Color contrast ratios meet WCAG AA standards (4.5:1 for normal text, 3:1 for large text)
  • Focus indicators are visible on all interactive elements

Infrastructure and DNS Checklist

Infrastructure issues are the most panic-inducing launch problems because they affect every user simultaneously and are often outside the development team's direct control.

DNS and domain:

  • DNS records are configured correctly (A records, CNAME records, MX records for email)
  • Domain ownership is verified and auto-renewal is enabled
  • www and non-www variants both resolve correctly (one redirects to the other)
  • DNS TTL has been lowered in advance of launch (set to 300 seconds 24-48 hours before launch, so changes propagate quickly)
  • If migrating domains: old domain redirects are in place and tested

Hosting and deployment:

  • Production environment matches staging configuration (server version, environment variables, feature flags)
  • Environment variables are set correctly in production (database URLs, API keys, third-party service credentials)
  • Error pages (404, 500) are custom-designed and functional
  • CDN cache is cleared or invalidated for launch
  • Database migrations have been run on production
  • Backup and restore procedures are tested and documented

Monitoring and alerting:

  • Uptime monitoring is active and alerting the right people (Pingdom, UptimeRobot, or equivalent)
  • Error tracking is configured (Sentry, Bugsnag, or equivalent)
  • Log aggregation is set up and accessible to the team
  • Performance monitoring is active (New Relic, Datadog, or equivalent)

Rollback plan: Document and test the rollback procedure before launch. If the launch goes badly, how quickly can you revert to the previous version? Everyone on the launch team should know the rollback trigger criteria and process.

Analytics, Tracking, and Third-Party Integrations

Third-party integrations are frequently the last items configured and the first to be misconfigured. Verify each one explicitly.

Analytics:

  • Google Analytics (or your analytics platform) tracking code is installed on all pages
  • Page views are recording correctly - check real-time reports while browsing the staging site
  • Event tracking fires for key interactions: form submissions, button clicks, downloads, video plays
  • Conversion goals/events are configured for business-critical actions
  • E-commerce tracking is recording transactions correctly (if applicable)
  • Cross-domain tracking is configured if the user journey spans multiple domains

Marketing and CRM integrations:

  • Email marketing platform integration works (newsletter signup, transactional emails)
  • CRM receives form submissions with correct field mapping
  • Marketing automation triggers fire correctly
  • Facebook Pixel, Google Ads conversion tracking, and other ad platform pixels are installed and verified with their respective debug tools

Third-party services:

  • Live chat widget loads and connects to the support team
  • Maps and location services display correctly
  • Social media sharing buttons work and share correct metadata
  • Video embeds play correctly with appropriate player controls
  • RSS feeds validate and contain the expected content

Critical pre-launch verification: Open the browser console on every key page. There should be zero JavaScript errors and zero failed network requests. Console warnings are acceptable but should be reviewed - they sometimes indicate misconfigured third-party scripts.

Launch Day: Process and Post-Launch Verification

Launch day should be methodical, not chaotic. With thorough pre-launch testing, launch day itself is primarily about executing the deployment and verifying everything works in the production environment.

Pre-deployment (morning of launch):

  • Final staging review - one pass through critical user journeys
  • Confirm all team members are available and communication channels are open (Slack channel, video call)
  • Verify rollback procedure one more time
  • Notify customer support team of the launch timeline

Deployment:

  • Execute deployment following your documented procedure
  • Monitor deployment logs for errors
  • Verify the correct code version is deployed (git log or build version check)

Post-deployment smoke test (first 30 minutes):

  • Homepage loads correctly
  • All critical user journeys work (navigation, forms, search, checkout if applicable)
  • SSL certificate is active and valid on production domain
  • No console errors on key pages
  • Analytics are tracking (check real-time reports)
  • Contact forms deliver to the correct inbox
  • Monitor error tracking dashboard for any spike in errors

Post-launch monitoring (first 48 hours):

  • Monitor uptime and response times continuously
  • Watch error tracking for new error patterns
  • Review analytics for unexpected traffic patterns or drop-offs
  • Check Core Web Vitals field data as it starts accumulating
  • Respond to any user-reported issues immediately

Hold a brief retrospective within one week of launch. What was missed? What worked well? Update the checklist for next time.

Frequently Asked Questions

How far in advance should pre-launch testing begin?

Start structured pre-launch testing two weeks before the target launch date. This gives you time to find issues, fix them, and retest. Infrastructure and DNS changes should be prepared at least one week in advance. Content review should be completed three or more days before launch to allow time for corrections.

What are the most commonly missed items in website launches?

The top five are: leftover noindex tags from development blocking search indexing, missing or broken 301 redirects from old URLs, analytics tracking not firing on all pages, contact form submissions going to the wrong email address, and DNS propagation delays because TTL was not lowered in advance.

Should we launch on a Friday?

No. Launch mid-week (Tuesday through Thursday) when your full team is available to monitor and respond to issues. Friday launches mean problems are discovered over the weekend when key team members may be unavailable. If a Friday launch is unavoidable, ensure on-call coverage for the weekend.

How do we handle a failed launch?

Have a documented rollback procedure and clear trigger criteria before launch day. If critical functionality is broken and cannot be fixed within your defined window (typically 1-2 hours), roll back to the previous version. Communicate transparently with stakeholders. A delayed launch is better than a broken production site.

Resources and Further Reading