Website QA Checklist for Agencies: What to Check Before Client Review

On this page

1. Who runs QA, and when
2. Design fidelity
3. Responsive and cross-browser checks
4. Forms, emails and analytics
5. Speed basics
6. SEO basics
7. Accessibility basics
8. Logging and tracking issues

When your development partner says a build is ready, it's tempting to forward the staging link straight to the client. Resist it. Clients judge the whole project on that first review, and a broken form or a stretched image costs more trust than it takes to fix. This is the internal QA checklist to run before the client sees anything. It's different from the website launch checklist, which covers going live; this one happens earlier, on staging, so the client review can focus on content and feel rather than bugs.

Who runs QA, and when

• When: after the developer has done their own testing and marked the build ready, and before the client gets the link
• Who: someone who didn't build it. The designer is best placed to check fidelity, and a project manager can test functionality.
• Where: on a password-protected, noindexed staging site; see staging sites explained
• Timing: leave room for a fix round before the client review date, not after it

Design fidelity

• Compare each page with its Figma frame at the same width: spacing, font sizes, weights, line heights and colours
• Check interactive states: hover, focus, open menus, accordions and tabs
• Look for placeholder text, dummy images and leftover demo content
• Check image crops, sharpness and aspect ratios, especially where real photos replaced design mock-ups
• Review templates beyond the main pages: blog post, archive, search results, 404 and legal pages
• Check the favicon and the social share image

Side-by-side screenshots of design and build make differences easy to spot and easy to report.

Responsive and cross-browser checks

Check	How to do it
Breakpoints	Resize the browser slowly from wide to narrow and watch for layouts breaking between the designed widths
Real phones	At least one iPhone in Safari and one Android phone in Chrome, since browser emulation misses some issues
Browsers	Everything on the agreed browser list, typically current Chrome, Safari, Firefox and Edge
Navigation	The mobile menu opens, closes and scrolls, and sticky headers don't cover content
Touch	Buttons and links are big enough to tap and not crowded together
Overflow	No sideways scrolling, overlapping text or cut-off headings

Forms, emails and analytics

• Submit every form with test data, including deliberate mistakes to see the error messages
• Confirm the thank-you page or message appears
• Check notification emails reach the right inbox and don't land in spam; on staging they may go to a test address, so note what changes at launch
• Test autoresponders, CRM or Google Sheets connections, and any booking or payment flows in test mode
• Tap click-to-call, WhatsApp and email links on a phone
• If analytics is set up on staging, confirm key events fire using DebugView in Google Analytics 4 or Tag Assistant, and make sure staging visits won't pollute live reports
• If there's a cookie consent banner, check it appears and that tags respect the visitor's choice

Speed basics

• Run key templates through PageSpeed Insights, or Lighthouse in Chrome's developer tools if staging is password-protected
• Look for oversized or uncompressed images
• Check how many font families and weights load
• Question heavy sliders, background videos and third-party widgets
• Remember that staging may not have the live server's caching or CDN, so treat results as a guide and recheck after launch

SEO basics

• Each key page has a unique title and meta description
• One H1 per page, and headings chosen for structure rather than size
• Alt text on images that carry meaning
• URL slugs match the agreed sitemap
• For redesigns, the redirect map is ready and checked against the old site's important pages
• No links or images hard-coded to the staging domain
• Noindex: staging should be noindexed now, so add removing it to the launch task list. A site that goes live with "Discourage search engines" still ticked won't be indexed, and a redesigned site can drop out of search results.

Accessibility basics

• Tab through each page with the keyboard: is the focus visible, and can you use menus, forms and pop-ups?
• Check the colour contrast of text and buttons, especially text over images
• Form fields have proper labels, not just placeholder text
• Link text says where it goes, rather than "click here"
• Zoom the browser to 200% and check nothing breaks or overlaps

For a deeper review, use the website accessibility audit checklist.

Logging and tracking issues

A QA pass is only useful if the findings reach the developer clearly. Keep one list, in a spreadsheet, your project tool or a visual feedback tool, and record for each issue:

• Page URL, device and browser
• A screenshot with the problem marked
• What you expected, and what happened instead
• Severity: blocker, major, minor or polish
• Type: bug, design mismatch or new request, since new requests may fall outside the agreed scope
• Status: open, fixed, retested or closed

Send issues in one batch rather than a trickle of messages, retest every fix, and only then share the staging link with your client. Save the sheet as a template for the next project. The same habits help when your client's feedback arrives; see giving clear website feedback.

I test agency builds against a checklist like this before handing them over, and a second pass from your team is always worth it. See WordPress development for agencies and Elementor development.