The pre-launch website QA checklist agencies can actually use

Every agency has a launch checklist somewhere. Most of them fail in one of two ways: they grow until nobody runs them, or they stay so vague — "check SEO" — that ticking the box verifies nothing. The version that survives contact with a real deadline has three properties: it is short enough to execute, each item is specific enough that a second person could verify it, and it keeps three kinds of work separate — collecting evidence, making judgments, and writing the decision the client actually receives.

This is the method behind the full AgencyProof pre-launch checklist, which is free, ungated HTML you can print. What follows is how to run it.

Freeze the release candidate first

The most common way a launch review produces garbage is reviewing a moving target. Fixes land while you check, and by the end nobody knows which version any finding applies to.

So the first item is not a check at all — it is an agreement:

That third row matters more than it looks. When a checker later meets a 401 or 403, the difference between "defect" and "working as designed" is whether the route was supposed to be private — and that is only answerable if someone wrote the intention down before the scan.

Verify the public paths

Follow every navigation link on a real device. Not a crawler first — you, clicking. A crawler tells you what returns 200; only a person notices that the page which loaded is the wrong page.

Then the plumbing:

• The custom 404 exists and carries navigation back into the site.
• Redirects from old URLs land in one hop, not chains.
• Every # or empty-href control does something observable when clicked. A probe cannot tell a modal trigger from a dead button — a click can.
• Anything that returned 401/403: sign in and retry it. Protected is not broken, but "protected" is a claim someone has to confirm.

Metadata: the checks that are actually mechanical

Titles, descriptions, canonicals and the sitemap are the rare launch checks that are fully mechanical — no judgment involved, so they should be at zero defects before anyone spends review time on harder questions.

The staging-canonical mistake deserves its own sentence: a site that launches with <link rel="canonical" href="https://staging.example.com/…"> is telling search engines the real site is a duplicate of a domain that is about to be shut off. It survives every visual review, because it is invisible.

Read the words the client will be challenged on

Somewhere on the site is a sentence a competitor, a customer or a lawyer will challenge. Find it before they do. The test for every strong claim — the best, the fastest, guaranteed, any number — is one question: can the client back this if asked in writing?

This is judgment work, not tool work. A scanner can flag superlatives; only a person who knows the client's business can decide which ones are defensible.

Forms are tested by submitting them

Every form, submitted for real, and the answer to one question recorded: where did the submission arrive? "The form works" means someone saw the enquiry land in the inbox or CRM — not that the button animated.

Then the failure path. Disconnect the network, submit, and look at what a visitor sees. An error state nobody designed is still an error state — the visitor just meets it without help.

Privacy, accessibility, performance — the basics that are checkable

The full checklist carries the item-level detail; the shape is what matters here:

• Privacy: the policy exists, is linked, and matches what the site actually does. Uploaded images carry no metadata that should not ship.
• Accessibility: the key journey works keyboard-only with visible focus; meaningful images have real alt text; nothing relies on colour alone. These are the basics — passing them is not WCAG conformance, and the checklist should not claim it is.
• Performance: the heaviest page, on a throttled connection, on a phone. Images sized for their containers, not uploaded at camera resolution.

Separate confirmed defects from items needing confirmation

This is the step that turns a pile of findings into something a client can act on. Every finding gets one of three labels before anyone sees it:

×ConfirmedObserved directly, and the observation is sufficient on its own. ?Needs confirmationCannot be resolved from public evidence. Someone has to check. ◆IntentionalThe behaviour is a control working as designed.

The discipline is refusing to let the middle category collapse into the first. A 403 on an admin route, a form that needs a login to test, a claim only the client can substantiate — these are not defects yet. Reporting them as defects spends your credibility; a client who catches one inflated finding discounts the other twenty.

Assign owners, then write the decision

An unowned finding is a finding that ships. The last mechanical step is a name and a date against every open item — including the "needs confirmation" rows, which need a confirmer, not a fixer.

And then the artifact the client actually receives — not the checklist, but the decision:

Decision: ship Thursday, with two known items.

Verified on candidate v2.4.1 by two reviewers on 24 July. Forty-one checks pass. Two items ship as known: the team-page photos await final bios (content, owner: client), and the blog canonical needs confirming after the domain cutover (technical, owner: agency, due Friday).

Ship, ship-with-known-items, or hold — with the reasons. A client who receives that paragraph knows what they are buying with their launch date. A client who receives a forty-row spreadsheet knows only that someone was busy.

What a checklist cannot do

The full checklist — every item, grouped by the same ten dimensions an AgencyProof inspection scores, with the adjudication and handoff steps at the end — is free and printable. No email, no gate.