How often should a website QA checklist be run?

Use three depths tied to three triggers: a full pass before launch and after major redesigns or framework upgrades, a five-check smoke pass on every deploy, and a monthly drift pass covering links, performance, integrations, and expiring keys and certificates.

Which website QA checks can be automated?

Automate anything deterministic: broken links, missing metadata, colour contrast, Core Web Vitals, and critical user journeys as end-to-end tests. Keep humans on judgement calls — whether copy makes sense, whether a layout is right — and use AI persona testing for the unscripted paths no checklist contains.

What is the most common launch-day QA miss?

A noindex tag or robots.txt block left over from staging, which keeps the live site out of search results. Canonical URLs pointing at the staging domain are a close second. Both belong in the SEO and metadata section of the pre-launch pass.

Does the checklist differ for AI-generated or vibe-coded sites?

The sections are the same but the weighting shifts. AI-generated code usually produces a working happy path with thin error handling, so spend the extra time on form validation and failure branches, authentication and access control, and anything touching payments or personal data.

Website QA Checklist: What to Test Before You Launch

Q: What are the eight sections of a website QA checklist?

Core functionality, forms and data handling, cross-browser rendering, responsive and mobile behaviour, performance, accessibility, SEO and metadata, and content and legal pages. Work them in that order — broken functionality makes performance measurements meaningless.

A website QA checklist is a fixed, repeatable list of checks you run against a site before launch and again after every meaningful change. A good one covers eight areas in order: core functionality, forms and data handling, cross-browser rendering, responsive and mobile behaviour, performance, accessibility, SEO and metadata, and content and legal pages. The point of writing it down is that it stops being a memory exercise — the same checks run the same way on every project, so the bug your client finds on launch day is one you have already looked for.

What should a website QA checklist cover?

Eight sections, worked top to bottom. The order matters: broken functionality makes performance numbers meaningless, so fix what is broken before you measure what is slow.

1. Core functionality

Every navigation link, footer link, and in-body link resolves — no 404s, no links to staging domains.
Every call-to-action button does what its label promises.
Search, filters, sorting, and pagination return correct results, including for zero results.
Authentication: sign up, log in, log out, password reset, and session expiry.
Any transaction path end to end — cart, checkout, booking, quote request — including the failure branch (declined card, unavailable slot).

2. Forms and data handling

Required-field validation fires, and the error message says which field and why.
Invalid input is rejected: malformed emails, letters in numeric fields, dates in the past where only future dates are valid.
The submission actually lands somewhere — inbox, CRM, database — and the confirmation the user sees matches what was stored.
Double submission does not create two records.
File uploads handle the wrong type and an oversized file without a raw server error.

3. Cross-browser rendering

Current Chrome, Safari, Firefox, and Edge at minimum. Safari is the one that usually breaks: it differs on date inputs, flex and grid edge cases, and video autoplay.
Check iOS Safari separately from desktop Safari — they are not the same engine build.

4. Responsive and mobile behaviour

Test the breakpoints the design defines, plus one width between each pair — that is where layouts collapse.
No horizontal scroll at any width. Tap targets are large enough to hit with a thumb.
Sticky headers, modals, and dropdowns behave with the mobile keyboard open.
Build the device list from the site's own analytics where it exists, not from a generic top-ten list. An audience skewed to older Android devices needs different coverage than one on recent iPhones.

5. Performance

Measure Core Web Vitals (LCP, CLS, INP) on a throttled mobile connection, not on your office fibre.
Images sized and compressed for their display size; modern formats where supported.
No render-blocking third-party scripts; check what analytics and chat widgets add.

6. Accessibility

Keyboard-only: tab through every interactive element, confirm visible focus, confirm no keyboard trap in modals.
Images have meaningful alt text; decorative images have empty alt.
Form inputs have associated labels, not just placeholders.
Colour contrast meets WCAG AA. Run an automated scanner, then verify the interactive paths by hand — scanners miss most real barriers.

7. SEO and metadata

Unique title and meta description per page; one H1 per page.
Canonical URLs correct; no noindex left over from staging. This is the single most common launch-day mistake.
robots.txt and sitemap.xml present and accurate; Open Graph tags render correctly when a URL is pasted into Slack or LinkedIn.

8. Content and legal

No lorem ipsum, no placeholder images, no "Client Name Here".
Contact details, pricing, and business hours match what the client signed off.
Privacy policy, terms, and cookie consent present where required.
404 page exists and offers a route back.

How often should you run the website QA checklist?

Running all eight sections on every deploy is not sustainable, and teams that try it soon stop running anything. Split the checklist into three depths tied to three triggers:

Depth	Trigger	What runs
Full pass	Pre-launch, major redesign, CMS or framework upgrade	All eight sections
Smoke pass	Every deploy	Homepage renders, primary nav, one form submits, the money path completes, no new console errors
Drift pass	Monthly, or after any third-party or dependency update	Links, performance, integrations, expired API keys and certificates

The drift pass is the one most agencies skip, and it is where client-facing breakage quietly accumulates: an expired certificate, a payment gateway API version sunset, a form handler that stopped delivering weeks ago.

Which checks should be automated and which stay manual?

Automate anything deterministic and repeated. Keep human judgement for anything about meaning or intent.

Check	Best handled by	Why
Broken links, missing metadata, contrast ratios	Automated scanner	Pass/fail with no interpretation needed
Core Web Vitals	Automated, in CI	Needs consistent conditions to be comparable
Critical user journeys (checkout, signup)	Automated E2E test	High cost of failure, runs on every deploy
Does the copy make sense? Is the layout right?	Human	Requires judgement a script cannot encode
Unscripted paths real users take	AI persona testing	By definition not in a script you wrote

Automated end-to-end tests are worth writing for the money path, but they break whenever the DOM changes, which is why agencies abandon them by the third redesign. Self-healing runners like AutoSim exist to absorb that churn so the suite survives the site it tests.

What do you do with the bugs the checklist finds?

A checklist that produces vague tickets creates a second problem. Every bug the pass turns up needs four things attached or it comes back as "cannot reproduce":

Exact steps from a known starting URL.
Environment — browser, version, OS, viewport width.
Visual evidence — annotated screenshot or a short capture.
Technical state — console errors and failed network requests at the moment it broke.

Collecting those by hand is the reason QA passes drag. Snap captures all four from a right-click on the page, which is also what makes it usable by the non-technical people who often run the content and copy sections of the checklist. For more on the format itself, see how to write a bug report developers will actually act on.

What does a website QA checklist not catch?

Two blind spots, both structural:

Paths you did not think of. A checklist tests what you expected. Real users arrive with a stale cookie, a back-button mid-checkout, a form half-filled from autofill, three tabs open. Those combinations are not on any list — which is the argument for exploratory testing alongside the checklist, and for AI QA approaches that generate paths rather than replay them.

What changed since you last looked. A pass is a snapshot. Dependencies update, third-party scripts change, content editors publish. The drift pass above is the mitigation, and continuous checks are the better version of it.

Does the checklist change for AI-generated sites?

The sections stay the same, but the weighting shifts. Code generated by Cursor, Lovable, v0, or Bolt tends to produce a plausible happy path with thin error handling, so the checks that earn the most time are forms and data handling (validation and the failure branch), authentication and access control, and anything touching money or personal data. Generated code also tends to be confidently wrong in ways that look finished, which makes the "does this actually store what it says it stored" check more valuable than any amount of visual review. The vibe coding QA checklist covers that variant in detail.

Where to start if you have no checklist today

Do not try to write all eight sections before the next launch. Start with the smoke pass — five checks, ten minutes, every deploy — and add a section to the full pass each time a client finds something you missed. A checklist grown from your own escaped bugs fits your work better than any template, including this one.

Try Klavity free and run your next client site through Snap, Sims, and AutoSim before the client does.