Every agency has a QA process. For a lot of them it lives in one person's head, gets compressed into the last afternoon before launch, and quietly drops whichever sections that person happens not to worry about. The result is predictable: the build is fine, and the launch is still messy.
A written checklist fixes that for a boring reason. It doesn't make anyone better at testing — it just stops the sections nobody owns from being skipped when the deadline compresses. Below is the list, grouped into nine sections, with every item phrased as something you can pass or fail rather than something you can interpret.
Before you start
Two ground rules make the difference between a checklist that catches things and one that gets ticked through.
First, the person running QA should not be the person who built the page. A developer testing their own work tests the path they built, because that is the path in their head. Swapping pages between two people on the team costs nothing and catches a category of bug that self-review structurally cannot.
Second, run it on a real staging URL with real content, not on a local build with placeholder text. Half the items below only fail once real content, real images and real form endpoints are in place.
The checklist
Copy this into your tracker as a task list, or keep it as a document you duplicate per project. Delete what doesn't apply — a brochure site doesn't need the commerce items — but delete it deliberately rather than by omission.
# Website QA Checklist — [project] — [date] — [tester]
## 1. Functionality
- [ ] Every link resolves; no 404s, no links to staging URLs
- [ ] Primary navigation works at every breakpoint, including dropdowns
- [ ] Footer links all resolve
- [ ] Search returns results, and returns something useful for no matches
- [ ] Filters and sorting apply, combine, and clear
- [ ] Pagination reaches the last page and back
- [ ] Buttons and CTAs go where their label says they go
- [ ] Login, logout, password reset and account pages work end to end
- [ ] 404 page exists, is branded, and offers a way back
- [ ] Any third-party embed (maps, booking, video, chat) loads and works
## 2. Cross-browser and device
- [ ] Chrome, Safari, Firefox, Edge — current versions, desktop
- [ ] Safari on iOS, Chrome on Android — real devices if possible
- [ ] Small phone width (~375px)
- [ ] Tablet width (~768px), portrait and landscape
- [ ] Laptop (~1280px) and wide desktop (~1920px)
- [ ] No horizontal scroll at any width
- [ ] Nothing overlaps or clips when text wraps to an extra line
- [ ] Hover states have a usable touch equivalent
- [ ] Fonts load; no flash of unstyled or invisible text
## 3. Content
- [ ] Copy matches the approved final version, not an older draft
- [ ] No placeholder text, no lorem ipsum, no "TBC"
- [ ] Spelling and grammar pass on every page
- [ ] Headings run in order (one H1 per page, no skipped levels)
- [ ] Images are the right crop, not stretched, and correctly sized
- [ ] Every image has meaningful alt text
- [ ] Contact details, addresses, opening hours and prices are correct
- [ ] Legal pages present: privacy policy, terms, cookie policy
- [ ] Copyright year is current and not hardcoded to last year
## 4. Forms and data capture
- [ ] Every form submits successfully
- [ ] Submission actually arrives at the real destination inbox or CRM
- [ ] Required-field validation fires and names the field
- [ ] Email, phone and date formats validate sensibly
- [ ] Error messages are readable and appear next to the field
- [ ] Success state is obvious (message or thank-you page)
- [ ] Spam protection is active and does not block real users
- [ ] File uploads accept the right types and reject the wrong ones
- [ ] Autofill works; tab order moves through the form in order
## 5. Performance
- [ ] Core Web Vitals measured on mobile, not just desktop
- [ ] Largest image on each template is compressed and correctly sized
- [ ] Images use a modern format and lazy-load below the fold
- [ ] No render-blocking scripts that could be deferred
- [ ] Caching and compression enabled at the server or CDN
- [ ] Page weight is sane on a throttled mobile connection
- [ ] No console errors on any template
## 6. SEO and indexing
- [ ] Unique title and meta description on every page
- [ ] Canonical URLs set and pointing at the live domain
- [ ] robots.txt allows crawling (the staging block is REMOVED)
- [ ] No stray noindex tags left from staging
- [ ] XML sitemap generated, accurate, and submitted
- [ ] Redirects mapped from every old URL on a rebuild
- [ ] Structured data validates
- [ ] Open Graph and Twitter card images render in a link preview
- [ ] Favicon and app icons present at every size
## 7. Accessibility
- [ ] Whole site navigable by keyboard alone
- [ ] Focus is visible on every interactive element
- [ ] Colour contrast passes WCAG AA for text and UI
- [ ] Form inputs have associated labels
- [ ] Interactive elements have accessible names
- [ ] Page works at 200% zoom
- [ ] Video has captions; audio has a transcript
- [ ] No information conveyed by colour alone
## 8. Analytics, tracking and legal
- [ ] Analytics installed once, firing, on every page
- [ ] Goals and conversion events fire on the right actions
- [ ] Tag manager container published, not left in preview
- [ ] Cookie consent appears and its choices are respected
- [ ] No tracking fires before consent where that is required
- [ ] Test and internal traffic excluded
## 9. Post-launch (run on production)
- [ ] DNS resolved; site loads on the real domain
- [ ] SSL valid on root, www, and every subdomain
- [ ] www / non-www and http / https redirect to one canonical version
- [ ] Forms deliver to the live inbox from the live domain
- [ ] Staging environment blocked from indexing
- [ ] Analytics recording real sessions
- [ ] Search Console verified; sitemap submitted
- [ ] Backup taken and restore testedThe sections that get skipped
In practice the list fails in the same three places, and they are not the ones people expect.
Forms are tested, delivery isn't
A form that shows its success message has passed the front-end test and says nothing about whether the message reached a real inbox. Test the delivery, from the live domain, to the address the client will actually read.
The staging noindex ships
A robots block or a noindex tag added to keep staging out of the index is the single most common launch defect, and one of the slowest to notice — the site simply never appears.
Accessibility gets deferred forever
It is the section most easily postponed because nothing visibly breaks. Keyboard navigation and contrast are cheap to check and expensive to retrofit after a build is signed off.
Deciding what to test on
The browser and device matrix above is a starting point, not a rule. If the site has analytics history, use it: the real distribution of browsers and screen widths for that audience beats any generic list. For a new site with no history, current Chrome, Safari, Firefox and Edge on desktop plus Safari on iOS and Chrome on Android covers the large majority of traffic for most projects.
What matters more than the number of browsers is the number of widths. Most layout bugs are breakpoint bugs, and they show up between the sizes people test rather than at the sizes themselves. Dragging a browser window slowly from narrow to wide across one page finds more than a dozen fixed-width screenshots.
Where the client fits
Client review is a separate pass from QA and should stay separate. QA asks whether the site works; client review asks whether it is right. Mixing them produces a list where “the form errors on Safari” sits next to “can we try a warmer blue,” and both move at the speed of the slower one.
The practical version is to finish QA first, then hand over a working site for review — and make the review itself as low-friction as the checklist. When a client has to describe a visual problem in words, you get another round of questions about which page, which browser and which element they meant. Letting them point at the page instead removes that round entirely, which is what tapko.app does for the review pass: the comment arrives attached to the element, with the URL, browser and screen size already on it. The bug report template covers what a complete report needs, and the new website build use case covers how that fits a launch timeline.
Running it without it becoming theatre
A checklist stops working the moment ticking it becomes the goal. Three things keep it honest: date and sign it, so a pass belongs to a person and a moment; log failures as individual tickets rather than notes in the margin, so they survive the meeting; and re-run the short version on production after DNS moves, because a meaningful number of items pass on staging and fail live.
And prune it. A checklist that grows every project and never loses an item becomes a document people scroll past. If an item has not caught anything in a year, it is costing attention it is not earning.
Launch-day problems are rarely new. They are almost always something that was broken the whole time and had no owner, no line item, and nobody whose job it was to look. The checklist is not there to find clever bugs. It is there to make sure the boring ones have somewhere to be caught.
Frequently Asked Questions
What should a website QA checklist cover before launch?
Nine areas: functionality, cross-browser and device rendering, content accuracy, forms and data capture, performance, SEO and indexing, accessibility, analytics and legal, and the post-launch sweep once DNS has moved. Skipping any one of them is where launch-day surprises come from.
Which browsers and devices should you test on?
Start from the site analytics rather than a generic matrix. For a site with no history, current Chrome, Safari, Firefox and Edge on desktop plus Safari on iOS and Chrome on Android covers the large majority, tested at a small phone width, a tablet width and a wide desktop.
Who runs QA on an agency website build?
Someone who did not build the page. A developer testing their own work tests the path they built, not the paths a user takes. The cheapest version of this is swapping pages between two people on the team before the client ever sees it.
What should you check after the site goes live?
Re-run the short version on production: forms actually deliver to the real inbox, redirects resolve, the staging robots.txt block is gone, SSL is valid on every subdomain, and analytics is recording real sessions. These are the checks that pass on staging and fail in production.