The website QA checklist: 100 checks before launch

How to use this website QA checklist

Run it on the staging build that is about to go live, with the requirements and approved designs open, and record a result for every check instead of ticking from memory. Use it as your pre-launch website checklist for a new site, or as a website testing checklist before each release of a live site or web app.

It assumes someone has to approve the result before it ships, such as a product owner or stakeholder. Each check carries a label:

• Auto a tool can check it reliably on every build.
• Judge a person has to decide, usually against the requirements.
• Auto + judge a tool finds the candidates and a person confirms.

Mark each check passed, failed, needs input or not applicable, and keep evidence (a screenshot, link or tool report) for anything a stakeholder may question later. The numbers let a ticket say "check 40 failed on build 1.4.2". Run the list again after the final content goes in.

Functionality and user journeys

Start with what the site is for: every journey in the requirements must work from start to finish, with the business rules exactly as specified.

1. Every key journey in the requirements works end to end on staging, such as enquiry, booking, sign-up, search and checkout. Auto + judge
2. Each journey meets its written acceptance criteria, not just 'it seems to work'. Judge
3. Business rules match the requirements: prices, VAT, discounts, delivery thresholds, stock limits and eligibility. Auto
4. Menus, footer links, breadcrumbs and buttons go to the right place, with no broken links, missing images or script errors. Auto
5. Site search returns relevant results and handles no results and misspellings sensibly. Auto + judge
6. Registration, log-in, log-out and password reset work, including wrong passwords and expired reset links. Auto
7. Each role (guest, member, editor, admin) sees and can change only what it should. Auto
8. Back, refresh and shared links behave sensibly mid-journey, without losing a basket or form data. Auto
9. Content editors can create, edit, preview and publish every content type in the requirements. Judge

Forms and emails

Forms are where leads and orders are won or lost, so test the whole path: the form, the validation, where the data lands and every email it triggers.

10. Every form submits with valid data, including file uploads, and shows a clear confirmation. Auto
11. Validation catches missing or badly formatted fields, explains each error next to its field and keeps what the user typed. Auto
12. Submissions reach the right inbox, CRM or database with every field mapped, and alerts go to the team that handles them, not a developer's test inbox. Auto + judge
13. Confirmation emails have the right sender, reply-to, subject, links and branding, and display well in major email apps. Auto + judge
14. The sending domain has SPF, DKIM and DMARC set up, so emails stay out of spam. Auto
15. Spam protection stops junk submissions without blocking real people or adding an inaccessible puzzle. Auto + judge
16. Marketing consent boxes are unticked by default, and each consent is stored with its date and wording. Auto
17. Double-clicking the submit button creates one lead or order, not two. Auto

Gmail's email sender guidelines require SPF or DKIM from every sender, and SPF, DKIM and DMARC from bulk senders. The ICO is clear that pre-ticked boxes are not valid consent.

Content and copy

Stakeholders check content first and forgive it least, so compare every page with the approved copy, not with your memory of it.

18. No lorem ipsum, test products, dummy prices or 'TODO' notes remain, including in meta tags and alt text. Auto
19. Every page matches the approved copy deck or CMS entries. Judge
20. Spelling, grammar and house style are consistent, including British or American spelling. Auto + judge
21. Names, prices, phone numbers, addresses, opening hours and company details are correct. Judge
22. Images are the final approved versions, cropped well at every screen size, with no watermarks or stretching. Judge
23. Dates, times, currencies and number formats suit each audience, and bookings and events use the right time zone. Auto + judge
24. Translated pages are complete, and the language switcher keeps visitors on the equivalent page. Auto + judge
25. Shared links show the right title, description and image on social networks and messaging apps. Auto + judge

Cross-browser and device testing

Test on the browsers and devices your audience actually uses, agreed in writing before testing starts, rather than on whatever is on the team's desks.

26. The supported browsers and devices are agreed in writing with the people who sign off, based on analytics where available. Judge
27. Current versions of Chrome, Safari, Firefox and Edge on desktop render every template correctly, including fonts, icons, images and video. Auto
28. Safari on iPhone and Chrome on Android are tested on real devices or a device cloud, not only in desktop emulation. Auto + judge
29. Layouts hold at common widths and the awkward ones in between, with no overlaps, cut-off text or sideways scrolling. Auto + judge
30. Menus, pop-ups, carousels, date pickers and video players work with mouse, touch and keyboard in every supported browser. Auto + judge

Mobile checks

Google uses the mobile version of a site for indexing and ranking, and many visitors will only ever see that version, so treat mobile as its own experience: small screens, touch, on-screen keyboards and patchy connections.

31. Pages work at 320 CSS pixels wide without scrolling sideways (WCAG 1.4.10 Reflow). Auto
32. Pinch-to-zoom is not disabled in the viewport settings. Auto
33. Tap targets are at least 24 by 24 CSS pixels or spaced well apart (WCAG 2.5.8), and main buttons are comfortably larger. Auto
34. Fields use the right input types and autocomplete values, so the right keyboard and autofill appear. Auto
35. Sticky headers, cookie banners and chat buttons never cover content, the focused field or the submit button, even with the keyboard open. Auto + judge
36. The mobile version has the same important content, structured data, titles and descriptions as desktop. Auto

Accessibility: WCAG 2.2 AA basics

WCAG 2.2 level AA is the standard most accessibility requirements point to; UK public sector websites, for example, must meet it. Automated tools cover only part of it.

As the W3C puts it: "Tools cannot check all accessibility aspects automatically. Human judgement is required." (W3C WAI). Numbers in brackets are WCAG 2.2 success criteria.

37. An automated scan (for example with axe-core) of every template and key state shows no violations. Auto
38. Everything works with a keyboard alone, in a logical order, with no keyboard traps (2.1.1, 2.1.2). Auto + judge
39. Keyboard focus is always visible and never fully hidden behind sticky headers or banners (2.4.7, 2.4.11). Auto + judge
40. Text contrast is at least 4.5:1, or 3:1 for large text, and controls and meaningful graphics reach 3:1 (1.4.3, 1.4.11). Auto
41. Informative images have alt text that makes sense in context, and decorative images have empty alt text (1.1.1). Auto + judge
42. Form fields have visible labels, and errors are identified and described in text (1.3.1, 3.3.1, 3.3.2). Auto + judge
43. Headings, landmarks and link text give every page a clear structure (1.3.1, 2.4.4, 2.4.6). Auto + judge
44. Each page has a descriptive title and the correct language set (2.4.2, 3.1.1). Auto
45. Text resized to 200% loses no content or function (1.4.4). Auto + judge
46. Videos have captions, auto-playing audio can be stopped, and moving content can be paused (1.2.2, 1.4.2, 2.2.2). Judge
47. Log-in works with password managers and pasting, and no process asks for the same information twice (3.3.8, 3.3.7). Auto + judge
48. Key journeys work with a screen reader such as VoiceOver or NVDA, and custom components expose their name, role and state (4.1.2). Judge

If the business sells to consumers in the EU, the European Accessibility Act may also apply: see European Accessibility Act testing, and AI accessibility testing for where tools stop and people take over.

Performance and Core Web Vitals

Aim for the "good" Core Web Vitals thresholds that web.dev sets out: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads on mobile and desktop.

Before launch you only have lab data, for example from Lighthouse. INP needs real interactions, so web.dev suggests Total Blocking Time as a lab proxy, though not a substitute. Check again with field data once real visitors arrive.

49. Largest Contentful Paint is 2.5 seconds or less on every key template. Auto
50. Interaction to Next Paint is 200 milliseconds or less; before launch, use Total Blocking Time in the lab as a proxy. Auto
51. Cumulative Layout Shift is 0.1 or less, including while fonts, images, embeds and banners load. Auto
52. Images are sized, compressed and in modern formats, and below-the-fold images lazy-load while the main hero image does not. Auto
53. Third-party scripts (tag managers, chat, heatmaps, A/B testing) are audited, and none block the page from rendering. Auto + judge
54. Caching and compression are on for pages and static files, ideally behind a CDN. Auto
55. If a campaign or press launch is planned, the site has been load-tested at the expected peak. Auto + judge

SEO basics for launch

Check the simple things that do the most damage when they go wrong at launch: a staging noindex left on, a robots.txt that blocks everything, missing redirects from old URLs, or canonicals pointing at the staging domain. Google says robots.txt is not a way to keep a page out of its results; use noindex or a password instead.

56. Staging is kept out of search with a password or noindex, not only with robots.txt. Auto
57. At launch, production has no leftover noindex, password or 'Disallow: /' rule from staging. Auto
58. Every indexable page has a unique, descriptive title and meta description. Auto + judge
59. Canonical tags use absolute URLs on the production domain and point to the preferred version of each page. Auto
60. Every old URL with traffic or links has a permanent (301 or 308) server-side redirect to the closest new page, with no chains or loops. Auto + judge
61. HTTP and HTTPS, and www and non-www, all redirect to one version of the site. Auto
62. The XML sitemap lists only canonical URLs that return 200, is referenced in robots.txt and is submitted in Search Console. Auto
63. Structured data passes Google's Rich Results Test and describes only content that is visible on the page. Auto
64. Missing pages return a real 404 or 410 status, not a 200 'soft 404', and the 404 page helps people find their way. Auto
65. Search Console is verified for the production domain, with the business that owns the site as an owner. Judge

Security and privacy

Confirm the basics before launch: HTTPS everywhere, sensible security headers, locked-down admin areas, no leaked secrets, and cookies that wait for consent where the law requires it.

66. HTTPS works on every page with a valid certificate, no mixed content and automatic renewal. Auto
67. Security headers are set: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and frame protection. Auto
68. Admin, CMS and hosting accounts use strong passwords and multi-factor authentication, with default accounts removed and least-privilege access. Auto + judge
69. Users can see and change only their own data: try another user's order or account ID in the URL or request. Auto + judge
70. No API keys, secrets, debug output or stack traces appear in page source, scripts or error pages. Auto
71. The CMS, plugins, themes and dependencies are up to date with no known vulnerabilities, and unused ones are removed. Auto
72. Form and upload validation also runs on the server, not only in the browser. Auto + judge
73. Non-essential cookies and trackers wait for consent where the law requires it, and rejecting is as easy as accepting. Auto + judge
74. The personal data each form collects matches the privacy notice, is stored securely and has an agreed retention period. Judge

Check 69 deserves extra time: broken access control is ranked first in the OWASP Top 10:2025. The OWASP HTTP Headers Cheat Sheet gives header values, and the ICO's guidance on managing consent covers UK cookie banners.

Analytics and tracking

Tracking mistakes lose data that can never be recovered, so check that every key event fires once, with the right values, into accounts the business owns.

75. Analytics and tag manager are installed once on every page and report to production accounts the business owns. Auto + judge
76. Key conversions (enquiries, sign-ups, purchases, bookings, downloads, calls) fire exactly once with the right parameters. Auto
77. E-commerce values (revenue, tax, shipping, currency, product IDs) match the order in the back office. Auto
78. Staging and internal traffic stay out of production reports, and tags respect each visitor's consent choice. Auto + judge
79. The business has admin access to its own analytics, tag manager, Search Console and ad accounts, and access for anyone outside the business is recorded. Judge

Integrations and payments

Test payments and integrations in the provider's test mode first, including the failure paths, then confirm production keys and webhooks at launch.

80. Payments work in test mode with successful, declined and 3D Secure test cards, plus refunds and abandoned payments. Auto
81. Each order is recorded once, and stock updates and confirmations still happen if the customer closes the tab straight after paying. Auto
82. Production uses live keys and webhooks, staging uses test keys only, and any live check follows the payment provider's rules. Auto + judge
83. CRM, email marketing, booking and stock integrations receive the right data in the right fields on production accounts. Auto + judge
84. Maps, video, reviews, chat and booking widgets run on accounts the business owns and fail gracefully if the service is down. Auto + judge
85. Any AI chatbot answers from approved content, declines off-topic requests, hands over to a person and never reveals personal data. Auto + judge

Read your provider's terms before any live check. Stripe, for example, prohibits testing in live mode with real card details and provides test cards for declines and 3D Secure instead.

Legal pages

The business and its advisers approve legal content, but the delivery team often notices first when it is missing, so check that each page exists, is linked and matches what the site does.

86. A privacy notice is linked from every page and form and matches the data the site actually collects and shares. Judge
87. The cookie policy lists the cookies and trackers the site actually sets, checked against a cookie scan. Auto + judge
88. Terms and conditions, and for shops the delivery, returns and cancellation terms, are supplied or approved by the business. Judge
89. Legally required company details are shown; UK limited companies, for example, must show their registered number and registered office address. Judge
90. An accessibility statement is published where required; UK public sector websites must have one. Judge
91. Licences for fonts, photos, video, icons and plugins cover production use on this site. Judge

General information, not legal advice: the business and its advisers decide what its legal pages say. See GOV.UK on company details and public sector accessibility.

Launch day and post-launch monitoring

Treat launch like any other release: a named decision-maker, a rollback plan, a smoke test on production straight after go-live, and monitoring that someone actually watches. Put a name against every step of your website launch checklist.

92. The launch window, a named go/no-go decision-maker and a rollback plan are agreed with stakeholders. Judge
93. The old site and database are backed up, and a restore has been tested. Auto + judge
94. DNS changes are planned, with TTLs lowered in advance and every record carried across, especially email (MX, SPF, DKIM). Auto + judge
95. Straight after go-live, a smoke test on production covers the home page, key journeys, forms, payments and log-in. Auto
96. The SEO checks (57 to 64) are rerun on production, and caches and the CDN serve the new version. Auto
97. Uptime, certificate expiry and error monitoring are on, with alerts going to a named person. Auto
98. For the first weeks, someone watches Search Console for crawl and indexing problems and analytics for drops in traffic or conversions. Auto + judge
99. The sign-off records what was checked, on which build, what was not covered and who approved it. Judge
100. Logins, documentation and a support contact are handed over, and a post-launch review is booked. Judge

For check 99, use our UAT sign-off template.

Which website QA checks can be automated?

Of the 100 checks, 43 are marked Auto, 38 Auto + judge and 19 Judge. Tools can do much of the legwork, but more than half the checks still need a person at some point, because the answer depends on the requirements, the brand or real people's experience.

Even strong tools go only part of the way: Deque says its axe-core accessibility engine finds on average 57% of WCAG issues automatically. That is a good start, and a clear reason to keep a person in the loop.

ShipperAG is designed the same way. Deterministic checks decide pass or fail, and a language model's opinion alone never marks anything verified. Unclear or contradictory requirements are marked needs input instead of guessed, and anything outside what was checked is listed as not covered. See how ShipperAG works.

How the checklist maps to 13 quality areas

Every section of this website QA checklist falls into at least one of the 13 quality areas ShipperAG organises QA around. Mapping a checklist this way makes gaps visible, such as nobody owning monitoring after launch.

ShipperAG picks AI QA specialists for each release, across these areas. Meet them in the specialists overview.

Sources (checked 19 September 2026): web.dev, Web Vitals and Interaction to Next Paint; W3C, WCAG 2.2, Understanding Target Size (Minimum), Understanding Accessible Authentication (Minimum) and Selecting web accessibility evaluation tools; Deque, axe-core; Google Search Central, robots.txt, noindex, title links, canonical URLs, redirects, sitemaps, structured data, HTTP errors and mobile-first indexing; Google, email sender guidelines; ICO, valid consent and managing consent for cookies; OWASP, HTTP Headers Cheat Sheet and Top 10:2025 A01; Stripe, testing; GOV.UK, company details and public sector accessibility requirements.

A note on browsers: ShipperAG's own browser checks run in Chromium today, including phone and tablet sizes. The Safari, Firefox and real-device checks in this list still need other tools or people.