How to use this template
Each group below is a test area; each row is a case to verify. Pull them into a spreadsheet, and for each case add three columns: expected result (what must happen), status (pass / fail / not tested) and owner. During acceptance, you tick. A fail opens a defect: that is where a feedback widget like Couac avoids retyping, the tester clicks the problem and the ticket leaves with the URL, the browser, the console and the screenshot. This list is deliberately generic: remove what does not apply, add your business cases.
Before launch: the blockers never to skip
Four checks sink a launch if they slip: is the site accidentally indexable on staging (or wrongly blocked on production)? Do critical forms actually send their emails in real conditions? Does payment, if any, pass a real end-to-end test? Are the HTTPS certificate and redirects in place? These four are not cosmetic: one miss and the site is live but broken where it counts. Treat them as blocking cases in your plan, at the top of the list.
Forms and submissions
Valid submission
Correct data: confirmation shown, email received on target, fields cleared.
Error validation
Empty required field or malformed email: clear error message, no submission.
Anti-spam protection
Captcha or honeypot active, and a legitimate submission is not wrongly blocked.
Recipient and receipt
The email reaches the right address, the sender is readable, any receipt arrives.
Content and media
Spelling and consistency
Copy proofread, no leftover Lorem ipsum, consistent tone and casing.
Images and weight
Visuals sharp, well framed, compressed, correctly sized, alt text filled.
Legal notices up to date
Notices, privacy policy and terms reflect the correct entity.
Responsive and mobile
Breakpoints
Correct display from mobile to desktop, no overflow or clipped text.
Touch targets
Buttons and links large and spaced enough for a finger, at least 44 px.
Mobile menu
The burger menu opens, closes and navigates without trapping focus.
Browser compatibility
Target browsers
Rendering verified on recent Chrome, Firefox, Safari and Edge.
Safari iOS
Special case: check forms, video and viewport heights on iPhone.
Performance
Load time
First useful paint is fast, even on a throttled mobile connection.
Core Web Vitals
LCP, CLS and INP in the green on key pages, measured on mobile.
Optimized images
Modern formats, explicit dimensions, lazy loading below the fold.
Technical SEO
Title and meta description
Unique per page, sensible length, clear intent.
Controlled indexing
robots.txt and meta robots consistent, staging not indexable, production indexable.
Sitemap and canonical
Up-to-date sitemap.xml submitted, correct canonical tags, no duplication.
Structured data
Relevant Schema.org in place and valid where it helps.
Accessibility
Contrast
Text readable, contrast ratio meeting AA level.
Keyboard navigation
Everything reachable and operable by keyboard, visible focus.
Text alternatives
Meaningful images described, form fields labeled.
Privacy compliance
Cookie banner
Real consent: no non-essential tracker before acceptance.
HTTPS everywhere
Whole site on HTTPS, no mixed content, redirect from HTTP.
Data and forms
Purpose stated, consent box where needed, rights explained.
Frequently asked questions
Does this template replace a real acceptance test plan?
It is the raw material for one. A checklist becomes an acceptance test plan when you add, for each row, a verifiable expected result, a pass/fail status kept during acceptance and an owner. Pull these groups into a spreadsheet, fill those three columns, and you have a usable plan. To go further, also see website acceptance testing end to end.
Do you have to test everything at every launch?
No. On a big rebuild, you run the whole checklist. On a small update, you target the affected areas plus the blockers (critical forms, payment, indexing, HTTPS). The point of a checklist by areas is exactly that: replaying only part of it knowingly, without redoing everything or missing anything essential.
How do you turn a failed case into a ticket without retyping everything?
That is exactly what a visual feedback widget is for. When a case fails, instead of copying the URL, the browser and the steps into a spreadsheet, you click the problem from the page: Couac creates the ticket with the screenshot, the console, the network and the exact target, and files it on a board where you track progress to the fix then re-verify the row.