Guide

Website QA checklist: what to test before launch

A practical website QA and launch checklist: content, design, functionality, responsive layout, performance, accessibility, SEO and the launch itself, plus how to run the review with your team.

Updated October 7, 2026

Website QA is the review between “it's built” and “it's live.” Skipping it doesn't save time. It moves the bugs to the week after launch, when every one is public.

Use this checklist on any marketing site, web app or landing page. Copy it into your own process, drop what doesn't apply, and add what your project needs.

1. Content

Read every page as a visitor would, top to bottom.

  • No placeholder text, lorem ipsum or “TBD” left anywhere
  • Spelling, grammar and product names are right, including in buttons and error messages
  • Prices, dates, phone numbers and addresses are current
  • Every image has the right crop and meaningful alt text
  • Legal pages are linked: privacy policy, terms and cookie policy

2. Design

Compare the build with the design, page by page.

  • Spacing, type sizes and font weights match the design
  • Hover, focus, active and disabled states exist for every button and link
  • Empty, loading and error states are designed, not left to defaults
  • Light and dark mode both look right, if the site supports them
  • Icons and logos are sharp on high-resolution screens

3. Functionality

Click everything. Then try to break it.

  • Every link goes somewhere, with no 404s, and external links open where you expect
  • Forms validate input, show clear errors and send a confirmation
  • Form submissions arrive where they should, such as your inbox, CRM or database
  • Sign-up, sign-in and password reset work end to end
  • Checkout and payments work in test mode and once in live mode
  • The 404 page is helpful and links back home

Log every issue on the element

Skyelight pins each QA finding to the element on the live page, with page context and, with Skyelight Build, the source file and line. Nothing gets lost between the tester and the fix.

4. Responsive layout

Test on real devices, not only a resized desktop window.

  • Pages work at phone, tablet and desktop widths, with no sideways scrolling
  • Tap targets are large enough to hit with a thumb, about 44px
  • Menus open, close and scroll on mobile
  • Text stays readable without zooming
  • The site works in Chrome, Safari, Firefox and Edge, including Safari on iPhone

5. Performance

Slow pages lose visitors before they read a word.

  • Images are compressed and served at the size they're shown
  • The largest content on each page loads in under about 2.5 seconds on a phone
  • No layout shift as fonts, images or ads load
  • Unused scripts and third-party tags are removed

6. Accessibility

Check the basics every site should meet.

  • Every page can be used with a keyboard alone, with a visible focus outline
  • Text has enough contrast against its background
  • Headings run in order and every form field has a label
  • Images have alt text and decorative images have empty alt text
  • Motion respects the reduced-motion setting

7. SEO

Make sure search engines can find and understand each page.

  • Every page has a unique title and meta description
  • Each page has one H1
  • A sitemap exists and robots.txt doesn't block pages you want found
  • Staging and preview sites are set to noindex, and production isn't
  • Redirects are in place for any URLs that changed
  • Social share images and titles look right when a link is pasted

8. Launch

The last hour before, and the first hour after.

  • Analytics and conversion tracking fire on the live domain
  • Cookie consent works and blocks tracking until it's accepted, where the law requires it
  • The SSL certificate is valid and http redirects to https
  • Backups and uptime monitoring are on
  • Every open review thread is resolved or knowingly moved to after launch

How to run the QA review

A checklist only works if the findings reach the person who fixes them. A simple flow:

  1. Freeze the build. Review a staging or preview link that won't change under you.
  2. Split the checklist. Give design to a designer, content to whoever owns the copy, and functionality to a developer or tester. Clients can review content too.
  3. Log each issue where you found it. Pin it to the element with a website annotation tool, one issue per comment, sorted as a bug, an idea or a copy change.
  4. Assign and fix. Every issue gets an owner. A coding agent such as Claude Code or Cursor can take the straightforward fixes and reply on each thread when it's done.
  5. Recheck on the page. Resolve each issue only after you've seen the fix live. When nothing is open, you're ready to launch.

Frequently asked questions

What is website QA testing?

Checking a site before launch for broken functionality, content mistakes, design gaps, layout problems on different devices, slow pages, accessibility issues and missing SEO basics.

How long does website QA take?

For a small marketing site, plan a day for the review and a day or two for fixes. A web app with sign-in and payments needs more, because every flow has to be tested end to end.

Who should do website QA?

More than one person. Developers miss copy mistakes, writers miss broken states, and everyone misses the bugs on the device they don't use. Split the checklist and give each part to the person best placed to check it.

Run your next QA review in Skyelight

No card required.