How to review a client website
Reviewing a client website has two phases most designers conflate: your own QA pass before delivery (design consistency, mobile, broken links, content accuracy) and collecting the client's feedback afterward. Do the QA pass yourself first — it saves a round-trip on obvious issues — then share a link the client can annotate directly instead of emailing screenshots.
Do your own QA pass before sharing
Open the site on desktop and on your phone. Check that fonts, colors, and spacing are consistent across every page — not just the hero. Verify every link, form submission, and CTA actually works. Read every heading and paragraph for typos; spellcheck misses homonyms ('their' vs 'there') that a client will notice. This round is yours to catch — you don't want the client's first notes to be on broken links or wrong phone numbers.
Test on a real device, not just browser dev tools
Browser dev tools show a simulated viewport, not Safari on an iPhone. Load the site on an actual phone — yours and ideally one Android device. Check tap targets, text legibility without pinching, and image load speed on mobile data. Most clients check on their phone before their laptop. A design that breaks on iPhone will be the first piece of feedback you get, so catch it here.
Check the content layer, not just the visuals
Designers often review the layout and skip the words. Read every page for accuracy: business name, address, phone number, opening hours, prices. If the client gave you copy, verify it matches the brief — clients routinely send a final round of edits that never made it into the design file. Check meta titles too; they show up in browser tabs and Google, and clients notice when their name is cut off.
Share a link, not a screenshot
Screenshots force your client to describe a location by feel: 'the text near the logo' or 'the bit underneath the button.' Share the live staging URL or a review link instead — they can point at the exact element. Avoid emailing a Figma link unless the client is already set up in Figma; most aren't, and you'll spend the first hour of their review in onboarding, not reading their notes.
Ask three specific questions, not 'what do you think?'
Clients rarely know what you want them to check. Ask: Is the copy accurate? Does this represent your brand? Is anything missing from the homepage? Left to their own devices, they'll either send 'looks great!' (unhelpful) or spiral into redesigning the navigation (out of scope). Specific questions surface blockers; open-ended ones surface preferences. Address blockers first.
The part that slows down most reviews isn't the QA — it's collecting the client's feedback afterward. They email screenshots, send voice notes on WhatsApp, and follow up with 'did you see my message?' Share the site as a Drafty review link instead. Your client clicks the exact element they mean — the header, the pricing table, the footer copy — and pins a note right there. No screenshots, no forwarded emails, no guessing which 'bit near the top' they meant. Every note lands in one thread, anchored to the spot.
Open a live demoQuestions
- What should I check when reviewing a client website?
- Check design consistency (fonts, colors, spacing), all links and forms, content accuracy (correct business name, address, phone, prices), mobile behavior on a real device, and meta titles/descriptions. Do this yourself before sharing with the client — you'll catch most obvious issues and the client's notes will focus on real decisions, not typos.
- How do I collect client feedback on a website without email chaos?
- Share a URL they can annotate directly rather than emailing screenshots back. When feedback arrives as pinned comments on the actual page rather than as 'see attached' emails, every note is tied to the exact element — you spend zero time asking 'which button do you mean?' Tools that allow guest commenting (no account) get higher response rates from clients.
- How many rounds of revision should I include in a website project?
- Two rounds is the industry standard for most freelance web projects. Define this in the contract before you share anything for review — 'two rounds of revisions after initial delivery.' Without a cap, reviews can stretch indefinitely as clients re-open feedback they already approved.
- How do I get a client to actually review and approve a website?
- Reduce the friction: send a single link (not a PDF attachment), ask three specific questions they can answer by clicking rather than writing paragraphs, and give them a deadline. 'Can you send notes by Thursday?' gets a faster response than an open-ended share with no prompt.
- Do I need to review the website on mobile?
- Yes, on a real device — not just a browser viewport simulation. Safari on iPhone renders fonts and touch targets differently from Chrome's dev tools. Most clients will look at the site on their phone before their laptop, so a mobile issue is almost always the first note they'll send.
- How do I get written sign-off from a client?
- Ask in the same thread where feedback was exchanged: 'All your notes are resolved — can you confirm this is approved to go live?' A reply in that thread is sufficient written sign-off for most freelance projects. Keep the message thread; it's your record if the scope changes after launch.
Keep exploring
Stop emailing files back and forth.
Share one link. They comment on the exact spot — no account, always the current version.