The complete website QA checklist
63 checks across eight phases, ordered the way you would actually run them. Sweep your staging site, fix what you find, and launch knowing the embarrassing stuff is already caught.
June 12, 2026 · 10 minute read · 63 checks
Launch day has a way of finding the one thing nobody checked. The contact form that posts to nowhere. The hero that crops the founder’s head off on a phone. The noindex tag that quietly rode along from staging and kept the whole site out of Google for a month.
This is the pre-launch pass we run on our own work. It is organized into eight phases so a team can split it up, and each check is concrete enough to tick off with a yes or a no. Run it top to bottom on a small site, or assign a phase per person on a big one.
One note on tooling before you start. You can run this entire list with a browser and a spreadsheet, plenty of teams do. But most of these checks produce visual findings (“this is broken, right here”), and logging those in a spreadsheet throws away the “right here” part. A visual feedback tool lets you pin each finding on the exact element of the live staging site, with a screenshot captured automatically. Each phase below has a short note on how that speeds the sweep. If you want the tool landscape first, we compared the options in our guide to the best website feedback tools.
Phase 1 of 8
Content and copy
Start with the words. Copy mistakes are the cheapest bugs to fix and the most expensive to ship, because they are the ones clients and customers actually notice. Spellcheck catches almost none of the bad ones: the wrong phone number, last year's price, the headline typo everyone's eyes slid past for six weeks. Read slowly, read out loud, and read the pages nobody has looked at since week two.
- 01Proofread every page out loud, not just with spellcheck (typos hide in headlines, not body text)
- 02Hunt down placeholder text: search the build for lorem, TBD, FPO, and xxx
- 03Check names, job titles, and bios against what was actually approved
- 04Verify phone numbers, emails, and addresses by using them, not by reading them
- 05Confirm prices, plan names, and any legal or compliance claims match the latest signed-off version
- 06Update the copyright year in the footer and any dates buried in the copy
- 07Read every button and CTA: the label should match where it actually goes
- 08Confirm the legal pages exist and are linked: privacy policy, terms, and a cookie notice if you need one
Phase 2 of 8
Design and responsive (the three-viewport sweep)
This is the phase that catches the launch-day classics. A layout that looks perfect at your laptop width can break three different ways by the time it reaches a phone, and most teams only ever review at one width. Sweep every page three times: desktop 1440, tablet 768, and mobile 375. Yes, all three. The tablet pass feels skippable right up until the nav wraps onto two lines at 768.
- 09Walk every page at desktop width (1440 is a sensible sweep width)
- 10Repeat the walk at tablet 768: navs, columns, and card grids usually break here first
- 11Repeat at mobile 375: tap targets, font sizes, and anything that causes horizontal scroll
- 12Open and close the mobile menu on every template, not just the homepage
- 13Look for text overflowing buttons, badges, and cards (long names and long URLs love to break these)
- 14Check image crops at every width: faces and products should survive each one
- 15Verify hover, focus, and active states on links, buttons, and form fields
- 16Test the awkward content states: zero search results, a one-post blog, a very long page title
- 17Confirm the favicon, app icons, and social share image are real, not the framework default
Phase 3 of 8
Functionality, links, and forms
Forms are where QA earns its keep. A broken layout costs you some polish; a broken contact form silently costs you every lead until somebody notices, which can take weeks. Test every interactive path twice: once like a well-behaved user, once like a hostile one who pastes a novel into the name field.
- 18Click every nav, footer, and in-content link (run a crawler for coverage, but click the money paths yourself)
- 19Check external links point where the copy promises and open the way you intend
- 20Submit every form with valid data and confirm the user sees a clear success state
- 21Submit every form with hostile data: bad email formats, empty required fields, a 2,000-character message
- 22Confirm form submissions actually arrive, and in the right inbox or CRM
- 23Test search, filters, and sorting with real queries, including ones that return nothing
- 24Walk every checkout, booking, or signup flow end to end, on mobile too
- 25Visit a URL that doesn't exist: the 404 page should look designed and link back to safety
- 26Exercise carousels, accordions, tabs, modals, and video embeds with mouse, touch, and keyboard
Phase 4 of 8
Performance
Performance is a launch issue, not a post-launch optimization. The fixes are far cheaper before the site is live, and slow pages quietly tax everything else you just checked: conversions, rankings, and patience. You don't need a perfect score. You need to catch the unoptimized 4 MB hero image before it ships.
- 27Run Lighthouse on the homepage and your two heaviest templates
- 28Compress and convert images: anything over about 200 KB needs a reason to exist
- 29Give images explicit dimensions so the layout doesn't jump while loading
- 30Lazy-load below-the-fold images and embeds, but never the hero
- 31Make sure the largest above-the-fold element (usually the hero) loads with priority
- 32Strip unused scripts, fonts, and CSS left over from earlier drafts
- 33Load the site at least once on a throttled connection or a real phone on cellular data
Phase 5 of 8
SEO basics
You don't need a full SEO audit before launch, you need the basics not to be broken. Every item here is a five-minute check that becomes a five-week problem if it ships wrong. Number 39 alone has ruined more launches than anything else on this list.
- 34Every page has a unique title tag under 60 characters
- 35Every page has a meta description under about 155 characters
- 36One H1 per page, with a sane H2/H3 structure under it
- 37Canonical URLs are set, and no staging URLs leak into them
- 38The XML sitemap generates correctly and robots.txt doesn't block the live site
- 39The noindex tag from staging is gone (the single most classic launch-day fail)
- 40If this is a redesign, old URLs 301 to their new homes
- 41Content images have alt text (it counts for accessibility too)
Phase 6 of 8
Accessibility
Accessibility checks find real bugs for real visitors, and almost everything here doubles as a usability fix for everyone else. A checklist won't get you to full WCAG compliance, but this pass catches the failures that are both common and cheap to fix before launch.
- 42Navigate the whole site with only a keyboard: you should reach and operate everything
- 43Focus indicators are visible (do not ship outline: none)
- 44Run a contrast check on body text, text over images, and brand-color buttons
- 45Form fields have real labels, not just placeholder text that vanishes on focus
- 46Heading levels don't skip (no jumping from H1 to H4 because it looked right)
- 47Alt text describes what the image does, not its file name
- 48Run a screen reader over the homepage and your main form (VoiceOver is built into every Mac)
- 49Heavy animations respect prefers-reduced-motion
Phase 7 of 8
Cross-browser and real devices
Devtools emulation is a preview, not a test. Real browsers, especially Safari on a real iPhone, have opinions that emulators don't reproduce: scroll behavior, fixed headers, native form controls, font rendering. You don't need a device lab. You need the four big browsers and two real phones.
- 50Chrome, Safari, Firefox, and Edge on desktop
- 51Safari on a real iPhone (emulators don't reproduce iOS scroll and viewport quirks)
- 52Chrome on a real Android phone
- 53Fonts load and render correctly everywhere (a fallback font can shift the entire layout)
- 54Date pickers, selects, and file inputs work in each browser (these are the controls browsers style themselves)
- 55Sticky headers and fixed elements behave on iOS (the classic scroll-jump bug)
Phase 8 of 8
Analytics, tracking, and final pre-flight
The last phase is about what happens after the site goes live: knowing whether it works, whether anyone visits, and whether you could recover if something went wrong. Do these before DNS flips, because every single one is worse to discover missing afterwards.
- 56Analytics is installed and hits show up in the real-time view
- 57Conversion events fire for forms, signups, and purchases: trigger each one yourself as a test
- 58Your own team's traffic is excluded from analytics
- 59The domain is verified in Search Console and the sitemap is submitted
- 60SSL is valid and http redirects to https everywhere
- 61www and non-www resolve to a single canonical version
- 62Uptime monitoring is set up before launch, not after the first outage
- 63There's a fresh backup of the old site (and the new one) before DNS flips
Who runs the sweep (and how not to lose a week)
On a small team, one person can run the whole list in an afternoon. On bigger projects it works better as a bug bash: send the staging link to three or four people, hand each of them a couple of phases, and let everyone log findings into the same project. This is how agencies run it before client sites go live, because the people you pull in (a PM, a copywriter, the intern with the old Android phone) don’t need accounts in Pin Feed. They open the share link, type a name and an email, and start pinning.
Then one person triages: merge duplicates, assign owners with @mentions, and work the list until every pin on every viewport is resolved. Green board, clear conscience, ship it.