Client site QA checklist: the agency pre-delivery list

A client site QA checklist is the repeatable pre-delivery pass an agency runs on a client’s site — before handoff — to catch what actually breaks, and to produce something forwardable as proof the site was QA’d. At a glance, the pre-delivery list, ordered by what breaks most often:

1. Analytics events actually fire on a real browser load
2. Cookies carry the Secure attribute
3. The canonical link exists and points to the right host
4. No broken internal links in nav, footer, or CTAs
5. No JavaScript console errors during page load
6. The meta description and core SEO tags are present
7. The signup / checkout flow actually completes (the one every other checklist skips)
8. The deliverable is a QA report where every finding is machine-verified, not an opinion

Items 1–6 are the static-checker layer that most “ultimate QA checklist” guides cover. Item 7 is the functional-flow layer almost nobody checks. Item 8 is the artifact you hand the client. This list unifies all three, in that order.

Here is the reason the order matters. In a June 2026 audit of 49 fresh web launches, 38 (78%) shipped with at least one critical verified finding on day one (n=49; sample is public launches generally, not agency-built sites specifically). Those were launches the builders themselves believed were ready. For an agency, that number reframes cleanly: it is roughly how often a disciplined second set of eyes catches a real critical before a client ever sees it. The frequencies below — which check fires most often — come from the same dataset, which is why the list is ordered by what breaks, not alphabetically.

For the universal, persona-agnostic version of this list, see the pre-launch QA checklist before launch. This page is the agency-specific subset — the deep dive behind Prufa’s QA for agencies workflow: same checks, plus the two demands a client deliverable carries that a solo builder’s does not — repeatability across every project, and a forwardable artifact at handoff.

The client site QA checklist, ordered by what actually breaks

Each item below carries its failure mode, why it ships, how to check it, and what it costs the agency if it slips through to a client. The frequencies are counts from the 49-launch audit set (outbound/leads.csv).

1. Analytics events fire on a real browser load

38 of the 49 audited launches had no analytics events detected at all on a real browser load (critical); 3 more loaded a tag container that never fired an event — the subtle variant that passes a view-source check but fails a network-traffic one. The script is in the HTML, the tag manager is configured — and nothing fires. For an agency this is the quiet killer: the client signed off on “you’ll have analytics,” the dashboard stays empty for a month, and the conversation is about why you delivered a site that does not measure anything.

Why it ships: the analytics tag and the consent banner are built as separate features and never tested against each other; the tag fires only after consent is accepted, the event name does not match the dashboard, or the dataLayer.push is swallowed by an error handler.

How to check: automated — load the site in a real browser, accept consent, click around, filter the network tab by the analytics vendor’s hostname. Zero requests is the critical case; a container that loads but never fires an event is the subtler warning a view-source check misses.

2. Cookies set with the Secure attribute

22 of 49 set a session or auth cookie over HTTPS with no Secure flag. Some browsers send it over plain HTTP anyway, some do not — inconsistent behavior is the worst kind, because it passes your test and fails the client’s user.

Why it ships: the framework default is not Secure, and local dev runs on HTTP where the flag never matters.

How to check: automated, but trivially manual too — DevTools → Application → Cookies; the Secure column should be checked on every auth-related cookie.

3. The canonical link is present and points to the right host

28 of 49 had a canonical problem — most often a missing <link rel="canonical">, sometimes a canonical pointing at a different host (a leftover staging or template domain). The second variant is the dangerous one for an agency: you can ship a site that quietly tells Google to index your boilerplate domain instead of the client’s.

Why it ships: canonical tags are SEO housekeeping, invisible in the browser, and easy to copy wrong from a starter template.

How to check: automated — view source, search for rel="canonical", confirm the host is the client’s.

4. No broken internal links

14 of 49 shipped at least one broken internal link — a nav item, a footer link, or worse, a CTA that 404s. The CTA case is the reputation hit: the client clicks the one button the whole page is built around and lands on a 404.

Why it ships: routes get renamed, pages are generated as a set, and the links between them are never validated as a graph.

How to check: automated link-status crawl over every <a href> on the visited pages; manually, right-click any internal link → open in new tab → check the status code.

5. No JavaScript console errors during page load

10 of 49 threw a non-trivial JS error during initial render. The page can look perfect while something underneath — a form handler, a third-party widget, an analytics init — is already broken.

Why it ships: an event fires before its handler is registered, or a bundled reference does not resolve in production the way it did in dev.

How to check: automated console capture during the page-load walk; manually, open the site in a fresh window and read every red line in the console.

6. Meta description and core SEO tags present

10 of 49 were missing a meta description, and a long tail were missing Open Graph tags (og:title, og:image) or had no robots.txt or sitemap.xml. None of these break the site, but they are exactly the things a client’s marketing person notices the week after launch and asks why they were not done.

Why it ships: they are not user-visible, so they fall off the build-it-fast path.

How to check: automated — these are the standard static SEO checks every audit tool covers.

These six are the layer the generic “ultimate website QA checklist” guides and the white-label SEO-report tools already cover well. The next item is the one almost none of them touch.

The check every other QA checklist skips: does the client’s signup/checkout flow actually complete

Every static check above can pass on a site whose signup or checkout is dead. The form renders, the success page shows, analytics fire — and the auth cookie never sets, the session row never writes, or the confirmation email never sends. The site looks like it works. For an agency, a dead checkout shipped to a client is the single most reputation-damaging miss there is — and it is the one no static checklist catches.

This is the gap. Generic checklists stop at meta tags, SSL, speed, and broken links. The white-label audit-report tools cover technical SEO, page speed, accessibility, content quality — all static. None of them walks the flow and asks whether it actually completes.

Prufa’s free audit closes part of this gap on the client’s URL. It detects the signup or checkout flow and re-verifies in code that the flow’s entry element is really in the DOM — the LLM navigates and plain code verifies, never the other way around. That detection is how the same engine that powers how Prufa verifies a signup flow works: the agent claims a flow exists, deterministic code confirms it before the finding is allowed to count. The founder-facing version of this exact check is documented in test your signup flow before launch — an agency runs the identical check, just pointed at the client’s URL instead of its own.

Honest about the seams: the free audit looks at the flow; walking it end-to-end with assertions on every step is the monitoring product, not the free run. And some of the flow stays manual no matter what — the audit can’t pass a reCAPTCHA, can’t do OAuth without a Google account, and can’t confirm an email actually arrived. Those three you test by hand: sign up with a fresh address, read the inbox, then confirm the session holds in an incognito window. The automated check narrows the surface; it does not erase the manual last mile.

How agencies QA a client website before delivery (a repeatable process)

The list becomes a process the moment you run it the same way on every project. Repeatability is the whole point for an agency — a single dead checkout shipped once does more reputational damage than ten polished launches build, so the process has to be boring and identical:

1. Run it pre-handoff, not at the end of a sprint. QA is a delivery gate, not a final-day formality.
2. Static layer first, functional-flow layer second. Items 1–6, then item 7. The static layer is seconds of automated checking; the flow layer is where you spend the manual time.
3. One person owns the run. Whoever owns delivery runs the checklist — ideally not the person who built the page, because the builder tested the happy path they built.
4. Gate delivery on no open critical findings. A critical is a blocker, full stop. Warnings and info-tier items get a documented decision: fix now, or note for the client.
5. Same order every time. A repeatable order is what makes the result comparable across projects and defensible to the client.

The ordering of the static layer is not arbitrary — it follows the 49-launch frequency data above, so the things most likely to be broken are the things you check first. If you want the universal, deeper version of the static layer, the pre-launch QA checklist before launch is the hub this process is built on.

What to hand the client at launch: a QA report, not an opinion

The handoff package everyone agrees on is credentials, CMS training, and documentation. The handoff literature adds a “close-out summary.” The white-label audit tools add a branded PDF. The thing none of those gives the client is a report where every finding is machine-verified against captured evidence — not an opinion.

That distinction is architectural, not marketing. Prufa’s reports separate verified findings from advisory ones by design: deterministic checks (analytics, cookies, canonical, links, SEO) are verified — plain code checked them against captured network traffic and DOM state — while anything the LLM judged about UX is fenced into an advisory tier (docs/PLAN.md: the LLM navigates, plain code verifies; LLM-judged UX findings are advisory-tier only). The live outbound report renders this split literally: a “Verified findings” section opening with “Every finding below was machine-verified against captured network…”, with each item marked verified, and a separate advisory section for the LLM-judged calls. That is the artifact an agency forwards as proof of QA.

Where the alternatives genuinely win, plainly: the white-label SEO-report tools beat Prufa on branded-PDF polish and breadth of static SEO checks — they will put your agency’s logo on a 90-check PDF, and Prufa does not white-label or rebrand a report. If a logo-on-the-cover deliverable is the client’s expectation, those tools serve it better. Where Prufa wins is the two things they don’t do: the functional-flow finding (item 7) and verified-not-opinion evidence on every static finding. Pick the artifact that matches what the client actually needs to trust.

Pre-launch vs post-launch QA for agencies

Pre-launch QA gates delivery — you catch critical findings before the client or their users see them, which is the entire value of being a second set of eyes. Post-launch QA is ongoing monitoring of the live site for regressions after release: a deploy breaks the checkout, a third-party script changes, analytics stop firing. The 49-launch data sits on the pre-launch side of that line — 78% of those launches shipped a critical the builders thought was ready, and the pre-delivery gate is exactly where a disciplined agency catches them. Post-launch monitoring is a different (recurring) engagement, and worth pricing as one.

Run the checklist (and get the forwardable report)

You can generate a forwardable audit free on the client’s URL: it runs the static layer (items 1–6) and detects the flow layer (item 7), then produces the shareable HTML report described above — verified findings with captured evidence, advisory findings fenced off, in seconds. No signup, no card. It is the fastest way to run this checklist on a client site and walk away with the forwardable artifact.

For the universal pre-launch checklist this process is built on, see the pre-launch QA checklist before launch. For the data behind the ordering and the 78% figure, see the audit of 49 Show HN launches; the companion audit of 14 side-project launches shows the same point on a smaller set — even clean-looking sites carry a uniform quiet-flaw layer that a repeatable checklist surfaces.

FAQ

What is website QA (quality assurance)?

Website QA is the pre-launch pass that verifies a site actually works — signup and checkout flows, forms, internal links, analytics firing — and meets quality bars for accessibility, SEO, security and performance before it goes live. For an agency it is a repeatable pre-delivery step run identically on every project, not a one-off, because reputation compounds across clients.

How do agencies QA a client website before delivery?

They run the same checklist on every project before handoff: the static-checker layer first (analytics, cookies, canonical, broken links, console errors), then the functional-flow layer (does signup or checkout actually complete). Delivery is gated on no open critical findings. In a June 2026 audit of 49 launches, 78% shipped at least one critical — the pre-delivery gate is where those get caught.

What should an agency hand the client at launch?

The usual handoff package — credentials, CMS training, documentation — plus a QA report where every finding is machine-verified against captured evidence, not an opinion. That last artifact is what turns “we tested it” into proof. Prufa’s free audit produces a shareable HTML report of this shape; it is not a white-labeled or rebranded PDF, so say so plainly to the client.

Pre-launch vs post-launch QA — what is the difference?

Pre-launch QA gates delivery: you catch critical findings before the client or their users ever see them. Post-launch QA is ongoing monitoring of the live site for regressions after release. In a June 2026 audit of 49 launches, 38 (78%) shipped a critical the builders thought was ready — pre-launch QA is the gate where those are caught (n=49, launches generally, not agency-built sites).