Blog · Testing basics

What is website QA? A plain definition with examples

Short answer

Website QA is checking that a site’s important journeys, content and layouts work for visitors in real browsers, with evidence for each result: what passed, what failed, and what could not be checked. A speed score or one accessibility scan is only part of it.

On this page

Website QA (quality assurance) is the work of finding out whether a site does what its visitors need, before they find out for you. This post defines the term, shows what a QA pass covers and explains what a result must include before you can act on it. We make Sybqa, a website QA service, so the examples come from how its reports work.

By Sybqa · First published November 4, 2026 · Updated November 4, 2026

Website QA in one paragraph

For a website, QA means opening the site the way a visitor does, trying the things the site exists for and recording what happened. The output is not an opinion that the site “looks fine”. It is a list of checks, each with a result and the evidence behind it, so someone else can repeat a check and get the same answer.

Three things make it QA rather than a click-around: a defined scope (which pages, which journeys, which screen sizes), an expected result for each check written before you look, and a record of what actually happened.

What a website QA pass checks

Areas a website QA pass usually covers, with an example check for eachScroll sideways for more columns.
Area	Example check	Evidence that settles it
Journeys	From the home page, a signed-out visitor reaches the pricing page and sees the plan heading.	The steps taken, the final URL and the visible heading.
Forms	Submitting the signup form with an empty email shows a message next to the field.	The input used, the message shown and a screenshot.
Content and links	Links in the main navigation and footer open real pages, not 404s.	Each link target and the response it returned.
Layout	At 320 px wide the page does not scroll sideways and the main button stays visible.	The viewport size and a screenshot.
Accessibility basics	Form fields have labels and body text meets the contrast rule.	The rule checked and the measured value.
Errors	The page loads without JavaScript errors or failed requests.	The console and network entries.

For the full list before a launch, use the website launch checklist, which has 30 checks. When something is already wrong and you need to find it, use the website error checklist.

What website QA is not

A speed score. A performance report measures how a page loads. It does not tell you whether the signup form works. See Lighthouse and PageSpeed vs website QA.
One accessibility scan. Automated rules catch some problems, such as a field with no label. Others, such as whether a keyboard or screen reader user can finish checkout, need a person. See automated accessibility testing.
Unit tests. Unit tests check that your code does what you wrote. QA checks what a visitor gets from the deployed site. You want both; testing a Next.js app in layers shows how they fit together.
A promise that everything works. A QA pass covers the checks it ran, on the pages and screen sizes it reached. Everything else is still unknown.

Every result needs an honest state

A QA result is only useful if it says plainly what happened. Sybqa reports each check in one of five states:

Passed: the check ran and met its expected result.
Failed: the check ran and a real browser saw it break.
Blocked: the check could not run, for example because a login or protection page was in the way.
Not run: the check was skipped, for example because the run’s time budget ran out.
Needs review: something may be wrong, and a person should look.

Only Passed counts as passed. A report with no failures and three blocked checks is not a clean report; it is an unfinished one. Blocked is not passed explains why that rule matters, and the website QA report example shows how the states appear in a report.

How to run a first QA pass

Pick the one task your site exists for: sign up, buy, book or send a message.
Write the expected result before you look, for example “the confirmation heading appears”.
Open the published URL, not the builder preview, in a fresh browser window while signed out.
Try the task at desktop width and at phone width.
Record each check as passed, failed, blocked or not run, with a screenshot or a note.
After a fix, repeat the same check the same way. See how to retest a fix without writing test code.

Sybqa can do the browser part. Paste a link and a goal, review the plan it proposes, then start the run. It checks the pages in a real browser at desktop, phone and narrow widths and returns a report with the evidence for each check. It does not decide for you what matters on your site, and it does not replace unit or integration tests.

Common questions

Is website QA the same as website testing?

The terms are used loosely. Testing is running checks. QA is the wider practice: deciding what to check, running it, and keeping an honest record of the result, including what could not be checked.

Can AI do website QA?

AI can suggest what to check and spot things that look wrong on a screenshot. Treat those as leads until a browser check reproduces them. AI exploratory testing explains how Sybqa handles AI flags.

Sources

Sybqa website QA report example: the evidence states in a report

Subscribe to new posts (Atom feed)

Try Sybqa on your site

Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.

Add your site link here and it will be waiting in the console after you create an account. Then describe one journey to check and review the test plan before any run starts.