Launching a site without QA is like shipping a product without opening the box. Could be fine. Or it could blow up in your face.
There’s nothing magical about QA. It’s just process. Boring, repetitive, precise. But when it’s done right, everything works. Pages render properly. Links don’t break. Forms submit. Nobody gets stuck. And nobody notices. That’s the point.
This checklist doesn’t cover everything because that’s impossible. But it hits the real-world, high-leverage stuff most teams miss when they rush. Doesn’t matter if you’re running an agency, building in-house, or managing freelancers. If the goal is a stable, fast, accessible site that doesn’t suck on mobile, these are the basics.
1. Start QA Early (Way Earlier Than You Think)
Waiting until dev is “done” before testing is how teams paint themselves into corners. The earlier QA starts, the less rework later. Think Figma, not finished code.
Look at wireframes. Click through prototypes. Catch layout friction, interaction dead-ends, and text that reads like AI wrote it. Run it all by someone who didn’t build it. You’ll catch things the designer didn’t even notice.
QA isn’t a cleanup crew. It’s a co-pilot.
2. Use a Real Checklist, Not Just Someone’s Memory
QA without a checklist is just “vibes.” Stuff slips through. Tiny layout breaks. Duplicate fonts. Missing alt text. That broken link in the footer that’s been broken for three months.
Start with something proven, like the BrowserStack checklist. Strip out what doesn’t matter, add what does. Key things: layout consistency, brand colors, heading hierarchy, image compression, alt tags, link behavior, error states (404, 500), favicon, and SEO basics like meta titles and descriptions.
The goal isn’t perfection. Just don’t leave dumb mistakes live.
3. Test on Phones. Lots of Phones.
More than half of traffic hits from mobile. If you’re only testing on a MacBook with a giant screen, you’re missing the point.
Use Chrome DevTools, sure, but don’t stop there. Responsively is solid. So is BrowserStack. Better yet, check it on your actual phone. Especially the stuff that breaks easily: navigation menus, carousels, buttons, forms. Watch for weird zoom issues, collapsed layouts, off-screen elements.
Also, test with bad signal. See what loads and what dies.
4. Stop Assuming Chrome = “It Works”
Cross-browser bugs are still a thing. Safari handles flexbox differently. Firefox has opinions. Edge tries its best. Chrome lets you get away with too much.
Use BrowserStack or LambdaTest to run real tests, not just emulated ones. It’s faster than dealing with support tickets later from clients on Safari wondering why everything looks weird.
No, it’s not overkill. It’s just maintenance.
5. Automate the Boring Stuff
Nobody wants to manually test a signup form 17 times. And nobody should.
Regression tests, login states, form submissions, broken links, cookie banners, CTAs: automate them. Use Cypress or Selenium. Not just to save time, but to stay consistent across releases. Especially important once the site starts getting content updates, new plugins, or layout changes.
And if you’re not updating anything? That’s a bigger problem.
6. Accessibility Isn’t a Nice-to-Have
Accessibility isn’t just for compliance. It’s how real users navigate. Screen readers, keyboard-only navigation, contrast modes, you name it.
Use WAVE, axe DevTools, WebAIM’s contrast checker. Fix color issues. Check focus order. Don’t rely only on ARIA tags. And don’t assume your site is accessible because “it works” on your machine. Try tabbing through a full page sometime. If it’s painful, it’s broken.
People will sue over this stuff. And more importantly, people need it to work.
7. Validate Your Code, Even If It “Looks Fine”
HTML and CSS validators from W3C are still relevant. And still underused.
Syntax errors don’t always show up visually, but they can kill SEO, accessibility, or future compatibility. Especially with complex nesting or third-party embeds. Run a check. Fix what breaks. Most of it is minor, but it adds up.
Broken markup makes your site fragile. Fix it before search engines or screen readers choke.
8. Speed Is a Feature
Slow pages don’t just annoy people. They kill conversions and bury rankings.
Use Google PageSpeed Insights, GTmetrix, or WebPageTest. You’ll see what’s dragging: uncompressed images, unminified scripts, render-blocking CSS, third-party junk loading too early. Defer what’s not critical. Lazy-load images. Cache aggressively.
Don’t just chase the score. Fix what slows real-world users down.
9. Watch Real People Use the Site
Automated tests won’t catch friction. Only people do.
UserTesting and Maze let you observe how real users click, scroll, and get lost. No script can tell you a CTA is too subtle or that the nav is confusing. You have to watch. Not once, but a few times. Different types of users. Different goals.
What feels obvious to a designer is often baffling to a first-time visitor.
10. Track Every Issue. Fix What Matters.
Use a real tracking tool: Jira, Trello, Asana, whichever works for you. What matters is logging bugs clearly. Steps to reproduce. Screenshots. Severity level. And assigning an owner.
Don’t just fix things on the fly and move on. QA isn’t “done” until it’s rechecked, closed out, and confirmed.
And yes, this gets tedious. Still better than chasing ghost bugs two weeks after launch.
One Last Thing
QA isn’t glamorous. But it’s what separates real sites from amateur ones. And it’s where teams either tighten up or fall apart.
If the site matters, treat QA like it matters too.
That includes who’s building it. If you’re looking for people who treat QA as seriously as UX or SEO, we’ve got recommendations. Here’s the list of agencies that actually give a damn.