A website QA checklist before launch

On this page

A list to work down before a site goes live, in the order that saves the most rework: what the site says, how it behaves, how it is found and measured, then the launch itself. Print it, or copy it into your own project template and cut what does not apply.

How to use it

Test the staging build with final content in it, not the design files and not a build with placeholder text.
Have someone who did not build the page check it. People read what they meant to write.
Write every failure down with the page, the element, the device and what you expected.
After the fixes, test the failed items again, then the main journeys once more from start to finish.

Content

No placeholder text, sample posts or stock pictures left anywhere, including the footer and the 404 page.
Spelling, grammar and house style checked on every template.
Prices, phone numbers, addresses and opening hours match what the client last confirmed.
Legal pages are present and linked: privacy notice, terms, cookie information, and the company details the law requires where the client trades.
Every picture is licensed, and cropped sensibly at each screen size.
The favicon is set.
The 404 page exists and helps a visitor get back.

Links and forms

Every internal link resolves. None point at the staging address.
External links open the page intended. Phone and email links work on a phone.
Each form has been sent with valid details, and again with mistakes in it.
Submissions arrive where the client expects, and the client knows where that is.
Error messages say what is wrong, next to the field that is wrong.
The confirmation message and any confirmation email read correctly and come from the right address.
Spam protection is on and lets a real person through.
Site search returns sensible results, and says so when there are none.
For a shop: a test order placed with each payment method, through to the confirmation email, with delivery, tax and a discount code checked, and a refund.

Responsive layouts

Every template checked at phone, tablet and desktop widths, and at widths between the breakpoints.
Checked on at least one real phone, not only in a narrowed desktop window.
No sideways scrolling at any width.
The menu opens, closes and reaches every item by touch.
Buttons and links are big enough to tap and not crowded together.
Tables, embedded video, maps and long words stay inside the screen.
Checked in the current version of each major browser, including the one each phone ships with.

Accessibility basics

This is a floor, not an audit. The usual target is WCAG 2.2 at level AA, and a full audit is separate work.

Every page can be used with the keyboard alone, in a sensible order, with focus always visible.
Text holds a contrast of at least 4.5:1 against its background, or 3:1 for large text.
Pictures that carry meaning have alt text. Decorative ones have an empty alt attribute.
One h1 on each page, and headings in order with no level skipped.
Every form field has a label. Errors are given in words, not by colour alone.
Link text makes sense out of context: no “click here”.
The page still works zoomed to 200%.
Nothing plays sound by itself. Video has captions. Animation respects the reduced-motion setting.

Performance

Pictures are sized for the space they fill, in a modern format, and loaded lazily below the first screen.
Tested on a mid-range phone on a mobile connection, not only on the office network.
Core Web Vitals in the “good” range on the main templates: largest contentful paint within 2.5 seconds, interaction to next paint within 200 milliseconds, cumulative layout shift of 0.1 or less.
Nothing jumps as fonts, pictures and banners arrive.
Unused plugins, scripts and tags removed. Every third-party script has a reason to be there.
Caching and compression are switched on for the live server.

SEO basics

Every page has a unique title and meta description.
The staging “noindex” setting is off on the live site, and robots.txt allows crawling. This is the one most often missed.
An XML sitemap exists, lists live addresses only and has been submitted to search engines.
Canonical addresses point at the live domain, not at staging.
One version of the domain answers: with or without www, always on HTTPS, and the others redirect to it.
Structured data, where used, passes a validator.
A shared link shows the right title, description and picture.

Analytics and consent

Analytics is installed once, not twice, and reports to the live property.
The events that matter are recorded: enquiries, orders, phone and email clicks.
Your own team’s visits and the staging site are excluded.
A consent banner appears where the law requires one. Nothing that needs consent loads before it is given.
Refusing works, the choice is remembered, and it can be changed later.
The privacy notice names the tools that are really in use.

Redirects

Every old address with visits or inbound links is mapped to its new one. Build the list from a crawl of the old site and its analytics.
Redirects are permanent (301) and take one step: no chains, no loops.
Old files that other sites link to, such as PDFs and pictures, are covered.
The whole list is tested again after launch, not only before.

Backups and rollback

A full backup of the old site, files and database, has been taken and a restore has been tried.
Backups of the new site are scheduled and stored somewhere other than its server.
The rollback plan is written down: who decides, how long it takes, and what would be lost, such as orders placed in between.
You know who holds the DNS and registrar logins. The record’s TTL was lowered ahead of the switch.
The email records (MX, SPF, DKIM) are untouched by the DNS change, and mail still arrives afterwards.
The certificate is valid on the live domain, with and without www.
The launch is timed so that people are on hand afterwards. Not Friday afternoon.
The client has their own admin login. Temporary accounts and shared passwords are removed.
Uptime monitoring is on.
After launch: send a real enquiry or place a real order, and check that analytics sees it.

Collecting the findings

A checklist finds problems. It does not carry them to the person who fixes them. For each failure the developer needs the page, the exact element, the device and browser, and what was expected, in one list with a status. Our guide to annotating a website compares the ways to record that.

We use our own tool, ClickNote, for it. The tester clicks the element that is wrong and writes what they expected. The note keeps the page, the element’s CSS selector, a screenshot, and the device and browser, so “the menu will not close on my phone” arrives with the phone’s details attached. Each note is Open, In progress or Done, so the tester can see what to test again.

Once QA is clean, the client’s own acceptance testing comes next: see the UAT template.

Written in November 2026. Spotted something out of date? Tell us.