Website QA before client handoff

Short answer: before you hand a website to a client, check every public page on a phone and a laptop for broken links, layout overflow, missing images, console errors and basic SEO; turn each problem into a ticket with the page, steps, expected and actual result; fix and re-check; then give the client a short summary of what was checked, what was fixed, and what still needs manual testing (forms, payments, logins, email).

QA means quality checking: making sure the site works the way it should before real visitors see it. This page is for owner-led agencies and freelancers delivering marketing and brochure sites.

1. Check the public pages

• Every navigation, footer and in-content link opens a working page. Proofday checks this
• No page scrolls sideways at a 390px phone width. Proofday checks this
• Every image, script, stylesheet and font loads. Proofday checks this
• No JavaScript errors in the browser console. Proofday checks this
• Each page has a title, a meta description and one H1; images have alt text. Proofday checks this
• Pages load in roughly 3 seconds on a normal connection. Proofday checks this
• Copy proofread: names, phone numbers, prices, dates, legal text.
• Staging/preview URLs and placeholder text removed.

2. Test what an automated check can’t

• Every form submits and the message actually arrives in the client’s inbox.
• Booking, checkout or signup completed end to end with a test transaction.
• Logins and member areas, if any.
• Safari and Firefox, and at least one real phone.
• Analytics and consent banner behave as intended.

3. Write problems as tickets, not notes

A useful ticket lets whoever fixes it act without a call. Include:

• Title that names the problem (“Contact page: phone number link 404s”).
• Severity: high (blocks a visitor), medium, or low.
• Pages and viewport where it happens.
• Steps to reproduce, then expected vs actual.
• Evidence: a screenshot or the failing URL and status code.
• Suggested fix, if you know it.

4. Re-check after fixes

Re-run the same checks on the same pages after fixes go in, so you can show what changed. A before/after comparison is easier for a client to trust than “we fixed it”.

5. Hand over a short, honest record

Clients rarely want a 40-row spreadsheet. Give them one page: the overall result, the top issues found and fixed, and a plain list of what was not tested. Avoid words like “bug-free” or “certified”; say what was checked, on which pages and screen sizes, and when.

FAQ

What should I check before handing a website to a client?

Working links, mobile layout without sideways scrolling, images and scripts loading, no console errors, titles, meta descriptions and H1s, load time, proofread copy, and a manual test of forms, payments and logins.

How do I show a client that a site was tested?

Give a short summary of what was checked (pages, screen sizes, date), what was found and fixed, and what was not tested. Screenshots and a re-check after fixes make the record easier to trust.

Does Proofday fix the problems it finds?

No. Proofday reports issues with tickets and screenshots; your developer makes the repairs, and the included retest re-checks the updated public pages.

Does an automated check prove the site works?

No. It documents the automated checks performed on public pages. Forms, payments, logins, email delivery, other browsers and real devices still need separate testing.

Updated 2026-10-16 by Steven Jackson, who runs Proofday. Related: 36-item website launch checklist · Webflow QA before launch · Framer launch checklist · Client handoff QA · Proofday vs free tools