Website acceptance testing checks whether the delivered site supports the business tasks agreed with the owner. Write the expected outcome, perform the task and save evidence before signing off. A site that looks finished can still fail to deliver an enquiry or create a correct order.
When I review a release, I want the owner to try what a customer would do. “Everything is ready, take a look” puts the burden on someone who does not know where failures usually hide. A short acceptance sheet gives the conversation a clear basis.
Define website acceptance criteria before the final review
Choose the routes that matter to this release: find a service, request a quote, book, buy or open a file. State supported devices and browsers based on your customers. Explain which integrations are included and which tests need a provider sandbox.
Turn vague approval into a testable result
“The contact form works” is vague. “A mobile visitor submits once and the office receives one usable enquiry” can be checked. Record the tester, date, environment and expected destination. Use test data rather than a customer's identity.
The Marker.io UAT checklist separates preparation, environment, test cases, execution and sign-off. For a small business, those stages can fit in one shared sheet. You do not need a large QA department to agree what ready means.
Website UAT checklist for the owner
| Customer task | Expected result | Evidence |
|---|---|---|
| Find the service from mobile navigation | Correct page and clear next step | URL and short test record |
| Submit an enquiry | One record reaches the recipient | Test label and office confirmation |
| Follow a current advertising link | Correct offer opens | Destination and offer comparison |
| Complete a supported order test | Amount, item and state agree | Matching provider and store records |
| Use the route with keyboard or enlarged text | Essential action remains usable | Device, settings and observed issue |
Test the destination, not just the button
A clickable phone number may dial the wrong line. A download button may open an outdated document. An email notification may go to the developer instead of the business. Ask the person receiving the result to confirm it. This is also why enquiry delivery belongs in acceptance.
Expected results and launch blockers
What evidence would let you accept the work?
Mark only checks for which you have evidence. This is a working list, not a website quality score.
Mobile enquiry
Expected: one submission reaches the agreed office destination with usable contact details. Evidence: test label, time and destination record. Owner: developer plus the office recipient. A success message alone is insufficient.
Booking or purchase
Expected: the selected service or item, amount and status remain consistent. Evidence: matching customer confirmation and back-office record. Owner: operations plus developer. A duplicate or missing record blocks acceptance.
Release and recovery
Expected: someone can restore service without silently discarding new records. Evidence: documented recovery procedure and a safe rehearsal where appropriate. Owner: release lead. Define who can stop or reverse the launch.
Decide which defects stop the launch
A missing enquiry, incorrect charge, exposed private data or unusable primary customer action needs immediate review. A minor spacing issue can have a different priority. Agree severity from impact, not from how easy the fix looks.
Keep a defect record that another person can repeat
Include page, device, steps, expected result, actual result and supporting evidence with private data removed. Assign an owner and retest the same steps after repair. “Still broken” is understandable frustration, but it is not enough information for a reliable retest.
Make conditional acceptance explicit
If a noncritical issue remains, record the limitation, owner, due date and who approves proceeding. Do not let a chat reaction replace a clear release decision. A repair deadline and a launch date are separate commitments.
Website handover and post-launch verification
Confirm business-controlled access to the domain, hosting, CMS and relevant providers, plus documented permissions and recovery contacts. Check that credentials are transferred through a suitable secure channel. Keep them out of the acceptance spreadsheet.
SEO migration needs its own technical checks; use our website redesign SEO checklist rather than treating a working homepage as proof that old destinations survived. After release, repeat essential tasks in production using agreed safe methods. Compare page experience when the new interface changes loading or interaction.
At W-MAX, acceptance is where development and the owner's operating reality meet. The useful handover is a site, a verified customer route and a clear list of who handles the next issue.
Frequently asked questions
Is UAT the same as developer testing?
No. Internal testing checks implementation; acceptance checks agreed business tasks with the relevant users or owner. Both are useful.
Should I approve a site with small bugs?
Only after impact is assessed and remaining issues, owners and deadlines are explicit. Primary customer failures should not be treated as cosmetic defects.
Do tests on staging prove production will work?
No. Domains, mail, payment and other settings can differ. Repeat essential safe checks after deployment.