Estimated reading time: 7 minutes By: Editorial Team Published: January 10, 2024

Overview

Release checklists exist because quality degrades in the gaps between disciplines. A developer may ship clean code while a broken meta description goes unnoticed; an SEO pass may catch missing titles while a color contrast regression slips through. A shared checklist makes these gaps visible before they reach production.

Key takeaways

  • A checklist reviewed by two people catches more issues than one reviewed by one.
  • Automated checks should run in CI; the checklist covers what automation cannot.
  • Post-launch monitoring is part of delivery — ship-and-forget is not a strategy.
  • Checklists should evolve with the product; outdated items create noise that hides real issues.

Pre-development checklist

Before writing code for a new feature or page, confirm:

  • [ ] Designs are available and include states for empty, loading, error, and success
  • [ ] Accessibility requirements are defined (contrast ratios, keyboard interactions, screen reader announcements)
  • [ ] Performance budget for new assets is confirmed
  • [ ] Analytics events for the new feature are documented

Development checklist

During development, before opening a pull request:

HTML and semantics

  • [ ] All headings follow a logical hierarchy (one <h1>, sequential subheadings)
  • [ ] All images have descriptive alt text; decorative images use alt=""
  • [ ] Interactive elements use native HTML where possible (<button>, <a>, <input>)
  • [ ] All form inputs have associated <label> elements via for/id
  • [ ] Page uses semantic landmarks (<main>, <nav>, <footer>)

Styles

  • [ ] Text contrast meets WCAG AA (4.5:1 for body text, 3:1 for large text)
  • [ ] Focus styles are visible and not suppressed with outline: none without a replacement
  • [ ] No layout breakage at 200% zoom
  • [ ] Responsive breakpoints tested at 320px, 768px, 1024px, 1280px+

JavaScript

  • [ ] No console errors on page load or during primary user flows
  • [ ] Progressive enhancement: core content and functionality are available without JavaScript
  • [ ] Event listeners are removed when components are destroyed to prevent memory leaks
  • [ ] No blocking scripts in <head> without async or defer

Performance

  • [ ] Images are served in modern formats (WebP, AVIF) with appropriate sizes
  • [ ] Fonts are loaded with font-display: swap or optional to prevent invisible text
  • [ ] Critical CSS is inlined or loaded without render-blocking
  • [ ] Third-party scripts are deferred or loaded asynchronously

Pre-launch checklist

Before deploying to production:

SEO

  • [ ] Every page has a unique <title> tag (under 60 characters)
  • [ ] Every page has a unique <meta name="description"> (under 160 characters)
  • [ ] Canonical URLs are set correctly — no duplicate content issues
  • [ ] robots.txt is present and does not block crawling of public pages
  • [ ] sitemap.xml is present and submitted to Google Search Console
  • [ ] Open Graph tags (og:title, og:description, og:image) are present for shareable pages

Functional testing

  • [ ] All forms submit correctly and display appropriate success and error states
  • [ ] All internal links resolve to valid pages
  • [ ] 404 page is tested and returns the correct HTTP status code
  • [ ] Authentication flows (if any) are tested end-to-end

Cross-browser and device testing

  • [ ] Chrome (latest), Firefox (latest), Safari (latest)
  • [ ] iOS Safari on a real device or Simulator
  • [ ] Android Chrome on a real device or emulator
  • [ ] Windows high-contrast mode (for accessibility compliance)

Security

  • [ ] No sensitive data exposed in HTML source (API keys, tokens, credentials)
  • [ ] Content Security Policy header is configured
  • [ ] HTTPS is enforced with a valid certificate
  • [ ] External links use rel="noopener noreferrer"

Post-launch checklist

Within 48 hours of launch:

  • [ ] Core Web Vitals measured in Google Search Console or PageSpeed Insights
  • [ ] Analytics data is flowing — events are firing as expected
  • [ ] Error monitoring (Sentry or equivalent) shows no unexpected spikes
  • [ ] Lighthouse audit score is at or above pre-launch baseline
  • [ ] Crawl errors in Google Search Console are reviewed and resolved

Maintaining the checklist

A checklist that is never updated becomes a liability. Review it:

  • After any post-mortems that reveal a missed issue
  • When new tooling is added to the CI pipeline (items covered by automation can be removed)
  • At the start of each major project to verify it matches current product requirements

Conclusion

A release checklist is the connective tissue between disciplines. It does not replace code review, accessibility audits, or QA testing — it ensures that no category of quality is skipped in the handoffs between them. Keep it short enough to be used consistently and specific enough to be actionable.

More resources