A Pre-Launch Website QA Checklist You Can Hand to a Client

Launch day problems are rarely new bugs. They're almost always things that were there all along and nobody checked for, a broken contact form, a stray "Lorem ipsum" paragraph, a favicon that's still the default. A short checklist run the day before launch catches nearly all of it.

Functionality: does everything actually work

• Every form submits and sends to the right inbox, tested with a real submission, not just a glance at the field layout
• Every navigation link and button goes where it should, including footer links
• Any search, filter, or interactive element behaves as expected
• Checkout or booking flows complete end to end if the site sells or books anything

Content: the easiest things to miss

• No placeholder text left anywhere (search the whole site for "lorem" and "TODO")
• Every image has loaded, has reasonable alt text, and isn't stretched or cropped oddly
• Phone numbers, addresses, and business hours match what's current, not what was in the original brief
• Page titles and meta descriptions are filled in, not left as the template default

Technical basics

• SSL is active and the old http version redirects to https
• Old URLs from a previous site redirect to their new equivalents, not a 404
• A real 404 page exists and doesn't just show a blank screen
• Analytics and any tracking scripts are installed and firing

Accessibility and performance

Two checks are worth running even on a tight timeline. Text color against its background should meet a contrast ratio of at least 4.5:1 for normal-size text, the standard set by the W3C's Web Content Accessibility Guidelines (WCAG) for AA compliance, since below that threshold a meaningful share of visitors genuinely struggle to read it. And page load speed matters for more than patience: Google's Core Web Vitals guidance considers a Largest Contentful Paint under 2.5 seconds "good," with anything past 4 seconds flagged as poor, which affects both user experience and search ranking.

Neither check requires specialist tools. A free contrast checker and a Lighthouse scan in Chrome's dev tools cover both in a few minutes, and both are worth running even on projects with no formal accessibility requirement, since the underlying problems, text that's hard to read and pages that load slowly, hurt every visitor, not just the ones a compliance checklist is written for.

Build the checklist once, reuse it on every project

Recreating this list from memory for every launch is where items quietly fall off. Keep one master checklist as a template, duplicate it per project, and check items off as you go rather than relying on remembering what you checked last time. It also makes handing launch-day QA to someone junior on the team far safer, since the list carries the judgment calls instead of requiring them.

Run the checklist with time to actually fix what it finds

A QA pass the morning of launch only has room for emergencies. Run it two or three days earlier instead, so anything it turns up, a broken redirect, a typo in the footer, a contrast issue on the pricing page, has time to get fixed and re-checked without anyone rushing. Treat launch day itself as a final confirmation, not the first look.

Hand a shorter version to the client

Your technical pass and the client's review aren't the same checklist. Give them a shorter, plain-language version: does every page read correctly, are the photos the right ones, does the contact form reach the right inbox, does the site look right on your own phone. Point them at the actual pages, not a document, and let them pin anything they find directly on the page it's on. Roundmark works well for exactly this last pass, since issues found during a pre-launch review land with their exact location attached instead of in a final flurry of emails the night before launch.

Keep both checklists somewhere you'll actually reuse them. A checklist that lives in last March's project folder doesn't get run again; one pinned in your own process doc does.