The website launch QA checklist: 60 checks before you go live

Launches go wrong in predictable ways. The contact form sends to a test inbox. The staging site’s “noindex” tag ships to production. A redirect is missing and the old pricing page 404s for every link from your newsletter. None of these are hard to catch — they’re just easy to forget when everyone is focused on the design.

This checklist is for the final QA pass before a website goes live. It assumes the content and design have already been reviewed and approved; the goal now is to make sure everything works, everywhere, and that nothing from the build environment leaks into production.

Split it across your team, tick items off as you go, and log every failure as its own issue.

How to run a launch QA pass

Freeze content first. QA on a site that’s still changing is wasted effort. Agree a content freeze, then test.

Test the environment you’ll launch. If production is a different server from staging, run the critical checks on both — before launch on staging, and again on production immediately after.

Assign areas, not pages. One person owns forms, another owns cross-browser checks, another owns SEO and analytics. Areas get tested more thoroughly than pages.

Log as you go. Every issue gets one ticket or comment, with the page, the steps, what happened, what should have happened, and the device and browser you used. (See how to write a good bug report.)

Decide what blocks launch. Before you start, agree which categories are launch blockers (broken checkout, wrong legal text, forms not arriving) and which can be fixed in the first week.

1. Functionality

No broken internal links (run a crawler over the whole site)
No links still pointing at the staging domain
External links work and open where intended
Main navigation, footer and breadcrumb links are correct
The custom 404 page works
Email and phone links are correct

3. Cross-browser and device testing

Test on the browsers and devices your audience actually uses — check your analytics if you have them. At minimum:

Latest Chrome, Safari, Firefox and Edge on desktop
Safari on iPhone and Chrome on Android
A tablet in both portrait and landscape
Large desktop width (1440px and up) and a small laptop (around 1280px)
Mobile navigation opens, closes and works with touch
No horizontal scrolling on phones
Touch targets are comfortably sized
Hover-only interactions have a touch alternative

When you find a layout bug, record the exact width and device. A comment tool with desktop, tablet and phone previews helps the team see the same width you saw, but always note your real device and browser too — those details make reproduction much faster.

4. Content final checks

No placeholder text, images or “TBC” anywhere (search the site for “lorem”, “TODO”, “test”)
Legal pages are final and approved: privacy policy, terms, cookie policy, accessibility statement if required
Company details are correct in the footer, contact page and structured data
Copyright year is current
Prices, offers and dates match what’s live in your other channels
Images have alt text where they carry meaning

5. SEO essentials

The staging “noindex” tag or password protection is removed on production
robots.txt allows crawling of the pages you want indexed
An XML sitemap exists and lists the live URLs
Every page has a unique title tag and meta description
Each page has one clear main heading
Canonical tags point to the production URLs, not staging
Open Graph and social preview images are set
301 redirects are in place from every old URL that’s changing (map them in a spreadsheet: old URL → new URL)
Structured data validates, if you use it

Redirects deserve special attention. If you’re replacing an existing site, export the old site’s URLs (from a crawl, your analytics and your sitemap), and make sure each one either still exists or redirects to the closest new page.

6. Analytics and tracking

Analytics is installed on every page and recording visits on production (check real-time reports)
Test or staging traffic is excluded or in a separate property
Conversion events fire: form submissions, purchases, sign-ups, key button clicks
Marketing pixels and tag manager containers are published, and respect consent
Search engine webmaster tools are verified for the production domain

7. Performance

Pages load quickly on a phone over a typical mobile connection
Images are compressed, appropriately sized and lazy-loaded below the fold
No huge files (uncompressed videos, multi-megabyte PNGs) on key pages
Caching and compression are enabled on the server or CDN
Third-party scripts are limited to what you actually need

8. Security and infrastructure

HTTPS works on every page with a valid certificate, and HTTP redirects to HTTPS
The www and non-www versions redirect to one canonical domain
Admin areas are protected and default passwords changed
Test accounts and test data are removed or disabled
Backups are configured and a restore has been tested
Uptime monitoring and error alerts are set up
DNS changes are planned, with time-to-live lowered in advance if you’re switching servers

9. Accessibility spot check

Every interactive element works with the keyboard alone
Focus is visible when tabbing
Colour contrast is sufficient for text and buttons
Form fields have labels and errors are announced clearly
Headings are in a logical order

10. Launch day

A named person owns the launch and makes the go/no-go call
Launch at a time when the team is available for a few hours afterwards — not late on a Friday
Re-run the critical checks on production straight after go-live: home page, forms, checkout, analytics, redirects, HTTPS
Submit the sitemap to search engines
Tell support and sales the site is live, and what changed
Keep a short list of known, non-blocking issues and a date to fix them

Tracking QA issues without losing them

A 60-item checklist on a medium-sized site can easily produce dozens of issues. A few habits keep them under control:

One issue, one record. Never bundle.
Attach evidence. A screenshot of what you saw, the page URL, and the steps.
Prioritise. Low, medium and high is enough. High means “blocks launch”.
Assign every issue to a person, not a team.
Resolve, then verify. The developer marks it fixed; the person who found it confirms.

If your team reviews on the page itself, comments can carry most of that automatically. In ClientTweak, for example, each comment is pinned to the element, can save a screenshot of what the reviewer was looking at along with the viewport size, and can be assigned and prioritised — and if you live in Jira, comments can create Jira issues so QA findings land in the engineering backlog.

Printable summary

Area	Launch blocker if…
Forms & flows	Any form, checkout or sign-up fails
Links	Key pages 404 or point to staging
Devices	Navigation or key actions broken on a major browser or phone
Content	Legal text, prices or contact details are wrong
SEO	noindex left on, redirects missing
Analytics	No tracking or conversions on production
Security	No HTTPS, test accounts still live

Run the list, log what fails, fix the blockers, and launch with confidence — then check it all again on production.