Website launch QA checklist for small agencies

1. Write a small coverage agreement

Start with a named release, the exact site address and the person who can authorize testing. Separate public production pages from staging and signed-in areas. An agency’s yes and a public URL are enough for an ordinary public-page Snapshot; obtain written site-owner authorization before checks beyond ordinary public-page views, including staging, login and journeys; keep passwords and private access details out of the checklist and email.

List actual URLs rather than saying “the whole site.” Choose the home page, main services, important landing pages, contact information and any page linked from a primary call to action. Add a page that uses each distinct layout, such as a long article, pricing comparison or portfolio item. If your review is limited to ten routes, name the ten and record what was left out.

Choose one or two important journeys and write the expected final screen. “Home → services → service detail → contact information” is testable. “Check conversion” is too vague. Stop before an action creates a real message, order or account.

2. Check the pages a client will actually use

• Open every agreed URL directly. Confirm the intended page loads, rather than a generic error or unrelated redirect.
• Follow the logo, main navigation, footer and primary buttons. Check the destination and visible heading after each step.
• Look for missing images, broken downloads, empty cards, placeholder text and links to a staging domain.
• Compare service names, prices, business identity and contact details with the client's approved copy. Flag a discrepancy for the owner; do not silently decide a new price.
• Read a long heading, a long paragraph and a crowded card. Check that text remains readable and controls remain visible.
• Open the public policy and support links that the page promises. Record a missing document as a finding.

A status code alone is insufficient. A server can return 200 while showing an error message. Record both the response and the content that an ordinary visitor sees.

3. Compare desktop and phone-width views

Choose explicit dimensions, such as 1280 × 900 and 390 × 844 CSS pixels. Check the same pages and steps at both sizes. Look for clipped headings, navigation that cannot be reached, overlapping buttons and tables that push the entire page sideways. A table may scroll within its own labelled region while the rest of the page stays readable.

Record the browser and version separately from the viewport. Chrome at 390 pixels is still Chrome. Chrome's Device Mode documentation explains that desktop emulation approximates a mobile experience; it does not run the page on a physical phone. Where another browser engine is included, name it and retain its evidence. Do not label a resized Chrome window as Safari or a real iPhone test.

4. Keep form checks safe

On a live client site, ordinary page viewing can establish whether a form is present, its labels are readable and its submit control is visible. It cannot prove that a message reaches the right inbox. Do not submit a real form, buy a product or create an account to finish this checklist.

If a journey requires interaction beyond public page views, agree the written authority, staging environment, owned test recipient and stopping point first. Mark downstream delivery as untested when those conditions are absent. A test fixture can demonstrate the method without sending anything to a real customer.

5. Turn an observation into an actionable finding

Use this example format, not an invented client result:

Assign severity by the effect on the agreed task. Keep a reproducible navigation failure separate from a copy suggestion. A screenshot should support the written steps, with private customer information removed before any authorized sharing.

6. Close the release and retest the correction

• Coverage: URLs, journeys, browsers, dimensions, date and release version.
• Outcome: findings, owner decisions, and any release-blocking issue within that coverage.
• Limits: untested pages, states, devices and downstream actions.
• Retest: repeat the original steps against the corrected version and mark resolved, still present or untested.

A second reviewer is useful when the builder has repeatedly seen the same pages, the handoff is near, or the agency needs a separate evidence record. The agency remains responsible for fixes and the release decision. This checklist does not cover security, legal compliance, accessibility certification, load testing or every possible user state.

Related resources

• How to check an AI built client website before launch
• How to read a website QA report