guides 10 min read

Website QA Checklist: 12 Checks Before You Send the Review Link

Run a 12-point QA pass before you send any review link: check every link and form, test three real viewport sizes, test two browsers, read the copy once out loud, check images and speed, then freeze the site. It takes about 45 minutes and removes roughly 70% of the feedback you would otherwise get, because the obvious bugs are gone before your client ever sees the page.

Contents

The problem: your client becomes your QA department

You know the feeling. You send the staging link on Thursday evening, feeling good about it. Friday morning your phone buzzes with a WhatsApp message: "The button on the contact page doesn't work." Then a screenshot of the homepage, cropped so you can't tell which device it was taken on. Then a voice note, 90 seconds long, that boils down to "something looks off on my phone."

None of this is feedback on your design. It is bug reporting, and you are doing it through the worst possible channel, with the person who is paying you.

Here is what that costs in practice:

  • Your client loses confidence. The first thing they see is a broken form or a missing image. Everything after that gets judged more harshly, including the parts that are perfectly fine.
  • Real feedback gets buried. When a client leaves 14 comments and 9 of them are "this link goes nowhere" or "typo in the footer," the three comments about hierarchy and messaging get less attention from both of you.
  • Rounds get wasted. If your contract includes two revision rounds, a round spent on broken links is a round you can't use for the changes that matter.
  • You can't reproduce what they saw. "It looks weird on my phone" is useless without the device, the browser and the screen size. You end up asking three follow-up questions and waiting a day for each answer.

Most freelancers skip a proper pre-review check because they are tired of looking at the site. You have stared at it for three weeks and your eyes slide over the same mistakes. That is exactly why you need a fixed checklist instead of a vague "I'll click around a bit."

Do these in order. The order matters: content and structure first, then devices, then performance, then the freeze.

  1. Click every link and button. Navigation, footer, buttons, social icons, "read more" links. Open external links in a new tab and confirm they work. Fix any link that points to the staging domain, a # placeholder or the old site.
  2. Submit every form. Fill in the contact form with a real email, submit it, and confirm the notification arrives where it should. Check the success message, the error states (leave a field empty) and the spam protection.
  3. Replace all placeholder content. Search the site for "lorem", "ipsum", "TODO", "XXX", "your text here" and the default stock photo names. Placeholders that survive to the review link are the most embarrassing kind of bug.
  4. Read the copy once, out loud. Typos, double spaces, inconsistent capitalisation, a company name spelled two ways. Reading aloud catches what silent skimming doesn't.
  5. Check images. Nothing stretched, blurry or missing. Every image has alt text. Large images are compressed (more on that in step 9).
  6. Test three viewport sizes. A phone (around 375px wide), a tablet (around 768px) and a laptop (around 1440px). Drag the browser window slowly between them too, because layouts often break at in-between widths nobody tested.
  7. Test two browsers. Chrome plus Safari is the minimum, because Safari renders things differently often enough to matter and most of your client's friends use an iPhone. Add Firefox if you have time.
  8. Check fonts and spacing consistency. Same heading sizes across pages, same button style everywhere, no orphaned single words on a line in the hero.
  9. Check page speed. Run the homepage through PageSpeed Insights or Lighthouse. You don't need a perfect score for a staging link. You need to catch the 6 MB hero image before your client does.
  10. Check the SEO basics. Every page has a title, a meta description and one H1. The staging site is set to noindex so Google doesn't pick it up, and you have a reminder to remove that on launch.
  11. Check accessibility basics. Text contrast is readable, buttons are reachable by keyboard, form fields have labels. Five minutes here avoids the "I can't read the grey text" comment later.
  12. Freeze the site. Stop editing. Tell yourself the version you just tested is the version the client sees. Changing things after QA is how new bugs sneak in.

Print it, paste it into Notion, put it in your project template. The point is that it lives somewhere you can't forget it.

Why the order matters

Freelancers often jump straight to browser testing because it feels technical and therefore important. In practice, the most common problems clients spot first are content problems: a wrong phone number, an old logo, a typo in the first heading. A client who owns the business notices those within seconds, and a wrong phone number feels more serious to them than a 4px alignment shift on Safari.

So spend your first 15 minutes on content and links, the next 15 on devices and browsers, and the last 15 on performance and the freeze. If you are short on time, steps 1, 2, 3 and 6 deliver most of the value.

Deep dive: testing devices without owning twenty phones

You don't need a device lab. You need three things:

Browser dev tools for the quick pass. Chrome and Safari both have a responsive mode where you can pick a phone size. It is good enough to catch layout breaks, overflowing text and tap targets that are too small. It is not good enough to catch Safari-specific rendering bugs, mobile keyboard behaviour or how a sticky header behaves while scrolling on a real phone.

One real phone, preferably an iPhone. Open the staging link on it and scroll the entire site once. This takes four minutes and catches things dev tools miss: 100vh hero sections that get cut off by the browser's address bar, fixed backgrounds that don't work on iOS, form fields that zoom the page when tapped.

A free service for the rest. If you want to see another browser or device, tools like BrowserStack offer free trials or limited free use. For most freelance projects that is overkill, but it is useful for a quick check of an older Android or Edge if your client's audience skews that way.

One more thing: look at what the client is likely to use. A restaurant owner reviewing from an iPad in the kitchen is a different test target than a SaaS founder on a 27-inch monitor. Ask on the kickoff call, or look at the analytics of their current site.

Deep dive: what "good enough" looks like for performance

There is a trap here. Performance work can eat a whole week, and clients rarely ask for it at review time. For the review stage, aim for three things:

  • No single image above roughly 400 KB unless it is a deliberate full-bleed photo, and even then compress it.
  • No layout jumps while loading. If text moves when the font or image loads, set dimensions on images and use a fallback font.
  • A homepage that loads in under three seconds on a decent connection.

Anything deeper (caching, script deferral, critical CSS) belongs in the launch checklist, not the review checklist. Our website launch checklist for freelancers covers that stage.

Deep dive: make the client's feedback testable

Even after a perfect QA pass, clients will find something. The difference is that what they find will be real feedback, and you need it in a form you can act on.

The problem with WhatsApp and email is that feedback lacks a location. "The heading is too small" could be about the homepage, the about page, or the third section down on mobile. Every vague comment costs you a round trip of questions.

A better setup is to let clients click directly on the thing they are talking about and leave a comment pinned to that exact spot. With a visual feedback tool, the comment arrives with the page URL, the element, the browser and the screen size already attached. That means no more "which device were you on?" emails. If you want more detail on setting that up, see our guide on how to get clear client feedback.

This is where a pre-review QA pass and a feedback tool reinforce each other. The QA pass removes the noise. The tool makes the remaining signal precise.

Mira is a freelance web designer in Rotterdam. She was building a 6-page site for a physiotherapy practice. Her usual routine was to finish the build, send the staging link by email, and wait.

On the first project of this kind she got back 23 pieces of feedback by WhatsApp over two days. Eleven of them were things she would have caught herself: two dead links in the footer, a contact form that sent to her test email instead of the clinic's, a placeholder address on the location page, and a hero image that didn't fit on an iPhone SE. Four were duplicates of the same issue described differently. Only eight were real design or content opinions.

Mira spent an afternoon sorting the messages into a spreadsheet, replying to each, and asking follow-up questions about devices. The client felt the project was "still a bit rough," even though the design itself was solid. One of her two revision rounds was gone before she touched anything creative.

For the next project she wrote a 12-point checklist, ran it for 45 minutes before sending the link, and switched to pinned comments on the live staging page. The client left 9 comments over one evening. Every one of them was a real opinion about layout, tone or imagery. No dead links, no placeholders. She resolved them in 90 minutes and used only one revision round.

Same freelancer, similar project. The difference was that the client reviewed a finished-looking site instead of testing a draft for her.

The bottom line

Your client should review your design decisions, not your typos and dead links. Run a fixed 12-step QA pass before every review, keep it in your project template, and collect the remaining feedback as pinned comments on the page itself. You will spend less time sorting messages and your clients will trust the work from the first click.

FAQ

What should I check before sending a website to a client for review?

Check links, forms, placeholder text, spelling, images, three viewport sizes, two browsers, basic speed and basic SEO. Then stop editing. This is the core of any website QA checklist before client review, and it takes around 45 minutes for a small site.

How long should a website QA check take?

For a 5 to 10 page brochure site, plan for 45 to 60 minutes. Larger sites or shops take longer, but you can limit the work by testing templates rather than every single page. If a check takes much longer than that, the checklist is too detailed for the review stage.

Which browsers should I test a website in before client review?

At minimum, Chrome and Safari, because together they cover the large majority of visitors and Safari handles several CSS features differently. Add Firefox if time allows. Test on one real phone as well, since desktop dev tools cannot reproduce every mobile bug.

Should I fix everything before the client sees it?

Fix everything that is objectively broken: dead links, forms, placeholders, typos and layout breaks. Do not try to perfect subjective things like spacing or colour choices, because that is exactly what the client's review is for. Share the site once the objective problems are gone.

Is a staging site enough for a client review, or do I need a live site?

A staging site is the right place for review, as long as it is password-protected or set to noindex so search engines ignore it. Make sure the link works without the client creating an account, because every extra login step lowers the odds that they leave useful feedback. Our guide to staging site best practices explains the setup.

What is the best way for clients to report website bugs and feedback?

Pinned comments directly on the page, because they carry the location, browser and screen size with them. Email and WhatsApp strip that context and force follow-up questions. A visual feedback tool such as dotts lets clients click anywhere on the site and comment without creating an account.

How do I stop clients from reporting bugs I should have caught?

You can't stop it entirely, but a written pre-review checklist cuts it dramatically. Run it every time, in the same order, and keep it in your project template. Over a few projects, you will also learn which mistakes you personally repeat and can add them to the list.

Do I need a separate QA step if I use Webflow, Framer or WordPress?

Yes. No platform guarantees correct links, working forms or clean content, and each has its own quirks, such as Webflow interactions on mobile or WordPress plugins affecting layout. The checklist stays the same, only the details of step 7 and step 9 change.

Send clients a finished-looking site and collect their feedback as pinned comments, no login needed. Try dotts free →

Further reading

Leon Eikmeier

Leon Eikmeier is co-founder of dotts and has been building websites for freelancers and agencies for over 8 years.

Start Collecting Feedback in Seconds with dotts

Forget messy email threads and unclear revision requests. dotts makes feedback fast, clear, and organized so you can focus on what matters—getting work done.

Try it for Free