The Website QA Checklist for Launch Day

The week before launch is when the small things become expensive. A broken form, a missing page title, a button that doesn't work on Safari — each one is cheap to fix in staging and costly in production. A website QA checklist turns the final pass from a vague "look it over" into a systematic review that actually catches things.

This checklist covers the eight areas that matter most for launch day. Use it before you flip the switch — not after.

Why launch QA matters

Bugs caught pre-launch cost time. Bugs caught post-launch cost time plus reputation. Clients and end users will find the things you miss, and they'll find them at the worst moments: during a live demo, right after a campaign goes live, when traffic is highest.

A good QA pass doesn't have to take days. A structured checklist run by one or two people who know what to look for can cover most of a site in a few hours. The goal is systematic coverage — not assuming that something works because you built it, but actually verifying it.

The website QA checklist

1. Content and copy

Pages

Every page that should exist is live and accessible
No placeholder text (Lorem ipsum, "TBD", "Coming soon" that's not intentional)
Page titles are set correctly — no generic "Home | Untitled" defaults
Meta descriptions are written and within character limits
Open Graph tags (og:title, og:description, og:image) are set for all shareable pages
Canonical URLs are set correctly, especially on pages with query parameters

Copy

Brand name is spelled consistently across all pages
No broken sentences or truncated text from content management edits
Dates, prices, and legal text are current and accurate
Footer copyright year is correct

Images and media

All images have descriptive alt text (not empty strings on content images)
No broken image paths (images return 200, not 404)
Videos load and play; fallback content is in place where autoplay is blocked
Favicons are set for standard sizes (16px, 32px, 180px for Apple touch)

2. Links and navigation

Main navigation links go to the right pages
No internal links return 404 — crawl with a tool or click through manually
External links open in new tabs where appropriate
The logo links to the home page
Breadcrumbs (if present) are accurate and functional
No href="#" dead-end links in production
Footer navigation is complete
404 page exists and has a useful message plus navigation back to the site

3. Forms and interactive elements

Forms are the highest-stakes items on this list — if a contact form or checkout is broken, the site isn't working regardless of how it looks.

4. Responsive and mobile

Check at minimum: a narrow phone (375px), a tablet (768px), a desktop (1280px), and a wide desktop (1440px+).

Navigation collapses and functions correctly on mobile — hamburger menu opens and closes
Text is readable without horizontal scrolling at all breakpoints
Buttons and tap targets are large enough to tap on touch screens (44px minimum)
Images are not overflowing their containers or stretching disproportionately
Tables and data displays scroll horizontally or reflow on small screens
Modals and overlays are scrollable and closeable on mobile
No elements overlapping or clipping at any tested viewport
Sticky headers don't cover content when jumping to anchor links

5. Performance

Run a Lighthouse or PageSpeed Insights audit — note Core Web Vitals scores
Images are served in modern formats (WebP or AVIF) where supported
Images have explicit width and height attributes to prevent layout shift
Largest Contentful Paint (LCP) element loads without delay
No render-blocking scripts in the <head> that aren't critical
Fonts load without causing visible text flicker (FOUT/FOIT)
Third-party scripts (analytics, chat, ads) are loading asynchronously
Caching headers are set correctly for static assets

6. Accessibility

All interactive elements are keyboard-accessible (Tab through the page, then try every action)
Focus ring is visible — not suppressed with outline: none without an alternative
Screen reader test: run VoiceOver (macOS/iOS) or NVDA (Windows) through the key user flows
Color contrast meets WCAG AA at minimum (4.5:1 for normal text, 3:1 for large text)
Headings form a logical hierarchy (one H1, H2s for major sections, H3s for subsections)
Form inputs have associated labels — not just placeholder text
Error messages are programmatically associated with their form fields
ARIA roles and attributes are used correctly where native semantics don't apply
Animations respect prefers-reduced-motion where they're potentially distracting

7. Cross-browser testing

Test in at least: Chrome (latest), Firefox (latest), Safari (latest), Edge (latest), and Safari on iOS.

Layout renders correctly in all tested browsers
CSS features that require prefixes or fallbacks are handled (check Can I Use for anything modern)
JavaScript features work across all targets — pay attention to anything using optional chaining, nullish coalescing, or newer APIs
Fonts render correctly in all browsers — no fallback to system fonts where they shouldn't appear
Animations and transitions behave consistently

8. Analytics, tracking, and legal

Analytics (GA4, Plausible, Fathom, or similar) is installed and firing — verify with real time report
Conversion events are tracking correctly: form submissions, button clicks, purchases
Cookie consent banner is present and functional where required
Privacy policy and terms pages exist and are linked from the footer
GDPR / CCPA consent flows block third-party scripts until consent is given
Sitemap.xml is generated and up to date
robots.txt is configured correctly — staging disallowed, production allowlisted

How to log issues as you find them

Running through a checklist is the easy part. The harder part is making sure every issue you find actually gets fixed. This is where most manual QA falls apart: issues go into a shared doc, a Slack thread, or a mental note, and some percentage of them never get addressed.

The more effective approach is to log issues visually, directly on the page, as you find them. When you spot a layout bug on mobile, you click on the element and leave a comment there — not in a separate document. The tool captures the screenshot, the CSS selector, the URL, and your browser context automatically. The issue lands as a task immediately.

pinreview's embeddable widget makes this easy for QA done by your team. If you're reviewing staging on behalf of a client, the Chrome browser extension works on any page without needing to embed anything. Every issue you find becomes a task on the Kanban board, with full context, ready for a developer to act on.

The board gives everyone a shared view of what's open, what's in progress, and what's resolved — which means launch readiness is visible at a glance. When the board is clear, you're ready.

For more on what makes individual issue reports useful for developers, see our guide to visual bug reporting — the same principles that make bug reports actionable apply to issues you find in QA.

Before you launch

QA done right takes time, but it doesn't have to take days. Run through this checklist with a partner — one person testing, one person logging — and you can cover a typical marketing site in an afternoon. The goal isn't perfection; it's confidence that the site does what it's supposed to do for the people who will actually use it.

Catch it now, not after the campaign goes live.

Start free →