Free checklist · No signup
Website QA Checklist
The client found it in five minutes: the broken form your team never submits, because everyone knows it is broken. This five-step checklist runs QA like a process instead of a vibe: a real browser matrix, failure paths included, and a UAT round with people who did not build the site.
Use it on this page, copy it as Markdown, or import the .docx into Google Docs or Notion.
Free checklist · 5 steps · QA and UAT
Website QA checklist
Fill in once, used throughout the template
- 1
Scope the pass and build the matrix
QA lead or developerDecide what tested means before anyone starts clicking.
GoalA written list of what gets tested, on which browsers and devices, by whom.
- Name the build under test and freeze it for the pass.
- List the pages and the critical flows: signup, checkout, contact, search.
- Write the browser and device matrix from your analytics top three, plus one older device.
- Prepare test data: accounts, coupon codes, payment sandboxes, sample files.
Critical: Build the browser matrix from your analytics, not from the team's laptops. The audience on a three-year-old Android phone outnumbers the design team's MacBooks every time.
Done when: A scoped pass anyone could run without asking what to test.
- 2
Functional pass
QA lead or developerEvery link, every form, every flow, including the ugly paths.
GoalEverything interactive works, and everything broken fails loudly and clearly.
- Click every link, including footer, legal pages, and the 404 page.
- Submit every form twice: once with valid data, once with garbage.
- Run each critical flow end to end with real-looking data.
- Check what happens logged out, on expired sessions, and with an empty cart or list.
Critical: Test the failure paths, not just the happy ones. The form that swallows garbage silently costs more than the one that rejects a valid email loudly, because nobody reports silence.
Done when: Every interactive element verified working, with failures logged, not remembered.
- 3
Content and visual pass
Editor or designerThe typo on the pricing page outranks the elegant codebase.
GoalCopy, imagery, and layout hold up on every breakpoint in the matrix.
- Read every page for typos, placeholder text, and outdated claims. Search for 'lorem' to be sure.
- Check images: right asset, right size, alt text present, nothing stretched.
- Walk each breakpoint in the matrix and screenshot anything that wraps or overlaps.
- Verify titles, meta descriptions, favicons, and social share previews.
Done when: Clean copy and layout on every device in the matrix, with evidence captured.
- 4
UAT with real users
Project leadThe team knows where not to click. Outsiders do not.
GoalThree to five people who did not build the site complete real tasks on it.
- Recruit three to five testers who match the audience, not the org chart.
- Give each a task script with goals, not click instructions: 'buy the cheapest plan', not 'click the green button'.
- Set a deadline for the round, usually 48 to 72 hours.
- Have testers report each issue as an anchored comment on the page itself, one comment per issue, each with a status.
Critical: UAT means users, not the team that built the site. Five outsiders with task scripts will find in an hour what internal QA missed in a week, because the team has learned where not to click.
Recommended toolSimple Commenter
Testers click the exact element and leave a pinned comment, with no accounts and no browser extension, and every comment carries a status you can track to done. Any tool works here as long as comments are anchored and trackable.
QA passing and ready to ship? Use the website launch checklist.
Done when: Every tester finished the tasks, and every finding is an anchored, statused comment.
- 5
Regression log and exit
QA lead or developerTested means the list is empty, not that time ran out.
GoalEvery finding is fixed and retested, or documented as a known issue with an owner.
- Work the findings by status: to do, in progress, done. Nothing moves to done without a retest.
- Retest fixed issues on the browser where they were found, not just your own.
- Write the exit line: zero open blockers, and a dated known-issues list for the rest.
- Keep the log. Next release, the regression pass starts from last release's findings.
Critical: A bug reported in a chat thread is a bug that ships. Every finding gets a tracked status the moment it is found, or it does not exist by Friday.
Done when: Zero open blockers, a dated known-issues list, and a log the next pass starts from.
The checklist is tool-agnostic on purpose. Step four recommends Simple Commenter because that is the step we build for, and it starts free.
The checklist is process guidance, not legal advice.
QA and UAT catch different bugs
Teams that skip one of the two always find out which one they needed. The checklist runs QA in steps one to three and UAT in step four, because each covers the other's blind spot.
QA: the team verifies the spec
- Every link, form, and flow, on the browsers your analytics show
- Failure paths included: garbage input, expired sessions, empty states
- Finds what is broken against what was specified
- Blind spot: the team has learned where not to click
UAT: outsiders verify the experience
- Three to five testers who match the audience, not the org chart
- Task scripts with goals, not click instructions
- Finds what is confusing, not just what is broken
- Blind spot: users never reach the edge cases QA covers
Findings that point at the pixel, not the paragraph
Most QA time is not spent finding bugs, it is spent translating them: which page, which state, which browser, what did you click. A finding reported as an anchored comment skips the translation. The tester clicks the broken element, the comment records the page, browser, and viewport with it, and the fix gets verified on the same spot.
For each defect you find, use the bug report template to record the reproduction steps, expected result, actual result, and evidence. The checklist guides the testing pass; the report gives a developer enough detail to investigate one issue.
The same flow runs client-facing reviews on the staging site review checklist, and feeds the go/no-go call in the website launch checklist.
Trusted by 600+ agencies, freelancers, and enterprises
Trusted by Agencies,
Loved by Clients
See why web professionals call Simple Commenter the best website feedback tool, and never look back.
/ Rated 5.0 on Product Hunt & 4.8 on G2
Simple. Effective. Game Changer
@Dsouldiva
Finally, a feedback tool my clients actually enjoy
@craigfenton
A Game-Changer for Web Feedback – Worth Every Penny!
@ryanbarilla
The tool I've been searching for
@alexs89
Simple, yet ingenious
@koen.kerkvliet
Great feedback app and so easy to use!
@iamvictor
Hidden Gem
@greg319
Fantastic tool for working with clients
@devdbydesign
An Essential Tool for Enhancing Communication with Clients
@Fiorenzomi
Great product!
@gramir
Very useful product and excellent support
@Ulrich86098
Simple Commenter has changed the way I work
@Jim Langman
Deserves +1000 tacos
@IgnacioJadue
Clients LOVED using Simple Commenter
@Katelyn
Phantastic
@user6961b
They fixed my issue in literal seconds from emailing them
@100587018771155070259
Super handy tool. The developer is very responsive.
@neposeda
I didn't realize how much I needed this tool!
@koen.kerkvliet
Life changed in under 5 minutes
@Dsouldiva
My clients have been engaged like never before
@Jim Langman
Simple. Effective. Game Changer
@Dsouldiva
Finally, a feedback tool my clients actually enjoy
@craigfenton
A Game-Changer for Web Feedback – Worth Every Penny!
@ryanbarilla
The tool I've been searching for
@alexs89
Simple, yet ingenious
@koen.kerkvliet
Great feedback app and so easy to use!
@iamvictor
Hidden Gem
@greg319
Fantastic tool for working with clients
@devdbydesign
An Essential Tool for Enhancing Communication with Clients
@Fiorenzomi
Great product!
@gramir
Very useful product and excellent support
@Ulrich86098
Simple Commenter has changed the way I work
@Jim Langman
Deserves +1000 tacos
@IgnacioJadue
Clients LOVED using Simple Commenter
@Katelyn
Phantastic
@user6961b
They fixed my issue in literal seconds from emailing them
@100587018771155070259
Super handy tool. The developer is very responsive.
@neposeda
I didn't realize how much I needed this tool!
@koen.kerkvliet
Life changed in under 5 minutes
@Dsouldiva
My clients have been engaged like never before
@Jim Langman
FAQ
Questions people ask before they try it
Something missing? Email info@simplecommenter.com and you’ll get an answer from the person who built it.
- What is a website QA checklist?
- A website QA checklist is a repeatable list of checks a team runs before publishing a site or a release. This one has five steps: scope the pass and build a browser matrix from analytics, run the functional pass including failure paths, run the content and visual pass, run UAT with real users and task scripts, then work the regression log to zero open blockers. Running the same list every release is what stops the obvious bug from reaching clients.
- What should website QA include?
- Four layers: functional checks covering every link, form, and critical flow including the error states, content checks for typos, placeholder text, and image quality, visual checks across the browsers and devices your analytics actually show, and a UAT round where people who did not build the site complete real tasks. Each finding needs a tracked status, because untracked bugs ship.
- What is a UAT checklist?
- A UAT checklist structures user acceptance testing: recruit three to five testers who match the audience, give each a task script with goals rather than click instructions, set a 48 to 72 hour deadline, and have testers report each issue as an anchored comment on the page itself with a status. UAT is step four of the checklist on this page, so you can run it standalone or as part of the full QA pass.
- What is the difference between QA and UAT?
- QA is the team verifying the site works as specified: links, forms, flows, browsers. UAT is outsiders verifying the site works for its audience: real users completing real tasks without guidance. Both matter, and they fail differently. QA misses what the team has learned to avoid; UAT misses edge cases users never reach. This checklist runs QA in steps one to three and UAT in step four.
- How do you review a website before publishing changes?
- Freeze the build, run the functional and visual passes against a browser matrix built from your analytics, then have people who did not make the changes complete real tasks on the staging version. Collect every finding as an anchored comment with a status, and publish only when open blockers hit zero. For the launch itself, pair this with a website launch checklist covering SEO, redirects, and rollback.
- Is this website QA checklist free?
- Yes. Use it on this page, copy it as Markdown, or download the .docx version and import it into Google Docs, Notion, or your project wiki. No email or signup required. The checklist works with any stack and any feedback tool, though step four recommends Simple Commenter, which starts free.
Run the next QA pass with the checklist
Grab the checklist above, and when the UAT round comes, Simple Commenter starts free. Testers comment on the page from a link, you track every finding to done.
No credit card required.
Related reading: the website launch checklist, the staging site review checklist, or the website feedback tool.