How to do a website QA review
To do a website QA review, work through five areas in order: design consistency across every page, all links and form submissions, mobile on a real device, content accuracy (not just spelling), and cross-browser rendering. Do this pass yourself before the client sees the site — catching obvious issues now means their first round of feedback is about real decisions, not broken buttons.
Design consistency — every page, not just the hero
Open every page, not just the homepage. Check that headings, button styles, and spacing are consistent — the hero almost always looks right; it's the inner pages that drift. Common failures: an About page with a different link colour, a Contact page where the footer starts too high. A client's eye catches mismatched padding faster than you expect, and it takes thirty seconds to catch here versus twenty minutes to discuss in a feedback thread.
Every link, button, and form — actually click them
Don't scan for links — click every one. Nav, footer, social icons, CTA buttons, in-copy links. Test every form: submit a test entry and confirm it lands in the right inbox or CRM. Check the thank-you state — most designers test input acceptance but not whether the confirmation message renders. For external links (LinkedIn, Maps), verify they resolve to the correct profile. Clients often give you a URL pointing at a deleted page.
Mobile on a real device — not DevTools
DevTools simulates a viewport, not Safari on an iPhone. Put the staging URL on your phone. Specific things DevTools misses: iOS font rendering differences, tap targets under 44px, images that crop badly at 390px, and sticky headers that cover content on scroll. Check one Android device too — Chrome handles text wrapping differently from Safari in the 375–414px range. Most clients look at their phone before their laptop.
Content accuracy — read the actual words
Designers review layout; almost nobody reads the copy during QA. Check: business name capitalisation, phone number (call it), address on Maps, prices against the latest brief. Check meta titles in browser tabs — clients notice when their name is cut off. One trick: paste each page's text into a Google Doc and run spellcheck there. The browser misses domain-specific proper nouns; the Doc catches them.
Cross-browser — at minimum Safari and Chrome
Chrome is almost certainly what you built in. Open the site in Safari on macOS and Firefox before handoff. Common failures: CSS grid gaps render narrower in older Safari, backdrop-filter blur shows as a grey box in some Safari versions, Google Fonts load slower in Firefox's strict privacy mode (the fallback font stack flashes). Test the browsers your client's audience actually uses — not all of them.
Get client sign-off with an annotated review link
After your own QA pass, share the site for client review — but send a reviewable link, not just the staging URL. A bare URL plus 'what do you think?' gets screenshots in iMessage and voice notes on WhatsApp. Send a link they can annotate directly. Ask three specific questions: Is the copy accurate? Does it represent your brand? Is anything missing? Specific questions surface blockers; open-ended ones surface preferences.
The QA pass is the part you control — the client review is where things slow down. If their notes arrive as WhatsApp screenshots and forwarded emails, you spend more time locating what they mean than fixing it. Share the site as a Drafty review link. Your client clicks the nav, the pricing table, or the footer copy and pins a note right there — no account, no extension. Every comment lands anchored to the spot, and when you push the fix, the same link shows the update.
Open a live demoQuestions
- What should I check in a website QA review?
- Five areas: design consistency across all pages, every link and form submission, mobile on a real device, content accuracy (business name, phone, prices), and cross-browser behavior in Safari and Chrome minimum. Do these in this order — visual issues are easiest to miss, and content errors are the most embarrassing for a client to find.
- How long does a website QA review take?
- For a five-to-ten page site, a thorough QA pass takes two to four hours done systematically. Build it into the project timeline as a deliverable, not an afterthought — skipping areas to save time means the client finds the issue first, which costs more in the round-trip.
- What's the difference between a QA review and a client review?
- A QA review is the pass you do before the client sees the site — broken links, inconsistencies, mobile issues, content errors you can fix yourself. A client review happens after: feedback on decisions (copy, direction, brand). Conflating them means the client's first impression is a list of bugs, which undermines confidence in the work.
- Do I need to test every browser for a website QA review?
- No — test the browsers your client's audience uses. For most sites: Safari on iOS, Chrome on Android, and Chrome or Safari on desktop. Firefox is worth adding for SaaS or B2B sites. The most common cross-browser surprises are CSS grid gaps in Safari and Google Fonts fallback stacks in Firefox.
- What are the most common things designers miss in a website QA review?
- In order: inner page design drift (the About or Contact page has different spacing from the homepage), form submissions that accept input but don't deliver to the right inbox, mobile tap targets under 44px, and footer copy with the wrong year or old copyright name. The last one is trivial but clients spot it immediately.
- How do I get written sign-off after a website QA review?
- Ask in the same thread where feedback was exchanged: 'All notes resolved — can you confirm this is approved to go live?' A reply there is your sign-off. Don't send a separate form; the thread record is more robust.
Keep exploring
Stop emailing files back and forth.
Share one link. They comment on the exact spot — no account, always the current version.