UAT Testing Plan Template for Websites (Free to Copy)

You need a UAT testing plan your client can actually follow, but most templates you’ll find were written for a bank’s ERP rollout. Below is a complete user acceptance testing plan built for website projects, with example values filled in. After it comes a section-by-section guide to filling it in, and a one-screen checklist for smaller jobs.

What a UAT testing plan is (and why website UAT needs its own)

A UAT testing plan is the document that sets out what the client will test, who tests, where, how issues get reported, and what counts as “accepted”. It turns “have a look and let us know” into a defined round with a clear end.

Enterprise templates don’t fit a website build:

• Testers are client stakeholders, not trained QA staff. Your testers are the marketing lead, the content owner and whoever handles orders.
• The environment is a staging URL, not a test server with seeded databases.
• The risks are visual and cross-device. Think of a menu that won’t open on an iPhone, a form that fails silently, or a layout that breaks at 900px.

Jump to: the template · the short checklist

The website UAT plan template (download)

Download the plan as a Markdown file, open it in any editor or paste it into Google Docs, Notion or Confluence, and replace everything in brackets. The example values are for a fictional small ecommerce site, Fernhill Ceramics, which sells pottery online and takes bookings for workshops.

The rest of this guide explains how to fill in each section.

Scope: what’s in and out of this UAT round

List scope by page template and function, not by individual page. “Product template” covers 200 products; you don’t need 200 test cases.

In scope usually means:

• Every page template (home, listing, detail, blog post, landing page)
• Every form, and where its data goes
• Checkout, booking or signup flows
• Integrations: payments, CRM, newsletter, scheduler
• Global elements: header, navigation, footer, cookie banner, 404

Out of scope is just as important to write down. Typical exclusions are copy rewrites, new features, SEO work, and content the client hasn’t supplied yet.

The rule that protects you: out-of-scope items get logged as change requests, not blockers. When the client asks for a testimonials carousel on day three, it goes on the change list with its own quote. That keeps it from holding up launch or getting absorbed into the fixed fee.

Who tests: client stakeholders, not the dev team

UAT is done by the people who will accept the site and use it every day. Developers already tested it in QA. They fix issues found in UAT, but they don’t run it.

Role	Person (example)	Responsibility
Facilitator	Agency PM	Writes the plan, briefs testers, chases progress
Testers	Client marketing lead, content owner, sales or customer service, whoever handles orders	Run assigned scenarios, log every issue
Triage owner	Agency PM or lead developer	Confirms severity, separates defects from change requests, assigns fixes
Developer	Agency developer	Fixes issues, flags anything ambiguous
Approver	Client decision-maker	Signs off the round

Assign each scenario to the person who owns that job. The person who answers enquiries should test the contact form, and whoever packs orders should test checkout.

Your testers aren’t technical. They need clear tasks and a zero-friction way to report issues, or they’ll fall back to a vague email that says “the menu looks weird on my phone”.

Test environment: the staging site

Testing happens on a staging URL that mirrors production. Before UAT starts, confirm three things.

Access. Use password protection or basic auth so the site stays private. Test the login yourself from an incognito window.

Content. Copy and images should be final or near-final. Testing a layout full of placeholder text wastes a round, because the real content will break it differently.

Test data.

• Payments in sandbox mode, with test card numbers in the brief
• Form submissions routed to a test inbox you can check
• Test user accounts for any logged-in areas

What must match production: themes, plugins, integrations, and tracking scripts that affect behaviour, such as cookie consent. What intentionally differs: the noindex setting, live payment keys and live analytics.

Tip: Send testers one email that contains the staging URL, the password, test card details, their assigned scenarios and the deadline. Every extra message is a chance for someone to get lost.

Test scenarios written as real tasks

This is where most templates go wrong. They list features (“Contact form”, “Navigation”) and ask testers to check they work. Write scenarios as tasks a real visitor would do. Then testers use the site the way customers will, and they find the problems customers would find.

ID	Task	Expected result	Device
S01	Find workshop prices starting from the home page	Prices reached in 3 clicks or fewer	Desktop Chrome
S02	Submit the contact form	Thank-you message appears; email with all fields arrives at the UAT inbox within 5 minutes	Desktop Safari
S03	Buy a product on a phone with the test card	Confirmation page shows an order number; confirmation email arrives	iPhone Safari
S04	Sign up for the newsletter	Success message shows; address appears in the newsletter list	Android Chrome
S05	Search for “blue mug”	Relevant products are listed; an empty search shows a helpful message	Desktop Edge
S06	Use the main navigation on a phone	Menu opens and closes; every link goes to the right page	iPhone Safari
S07	Download the care guide PDF	PDF opens or downloads and is the current version	Desktop Firefox
S08	Book a call with the embedded scheduler	Slot is booked and confirmation is received by both sides	iPad Safari
S09	Check every footer link	No 404s; social links open the right profiles	Desktop Chrome
S10	Visit a URL that doesn’t exist	Branded 404 page with a link back to the home page	Android Chrome
S11	Read a blog post and share it	Images load; share button opens with the right title and URL	iPhone Safari
S12	Return to the cart after browsing	Cart still holds the added items	Android Chrome

The expected result must be testable, so that two people would agree on whether it passed.

• Bad: “Contact form works.”
• Good: “After submitting, a thank-you message appears on the same page and an email containing all five fields arrives at the UAT inbox within 5 minutes.”

If your client wants step-by-step test scripts, add a Steps column, as in the template. For most website rounds, task plus expected result is enough.

Browsers and devices to cover

Use the client’s existing analytics to set priorities. If 70% of their traffic is iPhone, iPhone Safari is your first test device, whatever your developers use day to day.

Device	OS	Browser	Priority
iPhone	iOS	Safari	1
Android phone	Android	Chrome	1
Desktop or laptop	Windows	Chrome	1
Desktop or laptop	macOS	Safari	1
Desktop or laptop	Windows	Edge	2
Desktop or laptop	Windows or macOS	Firefox	2
Tablet	iPadOS	Safari	2

Check at common breakpoints of around 375, 768, 1024 and 1440px. Then drag the browser window slowly between them. Layouts often break between standard widths, for example at 900px where the nav doesn’t fit but hasn’t collapsed yet.

You’d normally tell testers to write down their device and browser on every report. With PageProofer they don’t have to, because browser and device info is captured automatically with each note.

Entry and exit criteria

Entry criteria stop you from starting UAT too early. Exit criteria stop it from dragging on forever. Make both measurable.

Entry criteria (UAT starts when):

• Internal QA is complete, with no known blockers
• Final content is loaded, apart from listed exclusions
• Staging is stable, with payments and forms in test mode
• Testers have been briefed and have their access details
• The client has agreed the scenario list

Exit criteria (UAT ends when):

• Every scenario has been run on its assigned device
• Zero open Blocker or Major issues
• Minor issues are fixed, or accepted with a post-launch fix date
• Retest of fixed issues has passed
• Sign-off has been received

Severity levels with website examples

Level	Definition	Website example	Must fix before launch?
Blocker	Stops a key task completely	Checkout fails; contact form doesn’t send	Yes
Major	Key task broken on some devices, or wrong information shown	Mobile menu won’t open; wrong price displayed	Yes
Minor	Visible flaw, but the task still works	Hover state missing; spacing off at one breakpoint; focus outline invisible	Fix or accept with a date
Cosmetic / Suggestion	Preference rather than a defect	Preferred image crop; copy tweak	No, optional or change request

Testers can suggest a severity, but the triage owner sets the final level. A client will often mark a logo they’d like larger as a blocker. Triage also separates defects (the site doesn’t do what was agreed) from change requests (the client wants something different from what was agreed). Change requests go on a separate list with their own estimate.

How testers log feedback

This section belongs in the plan word for word, because how issues are reported decides how fast they get fixed.

Email, spreadsheets and screenshots dropped into Slack all fail in the same way. You get no URL, no browser, a cropped image and a description like “the button is broken”. Your developer then spends 20 minutes working out which button, on which page and on which phone.

Plan wording you can paste in:

Open the staging site and click the PageProofer feedback button. Click the exact element the problem is on and pin a note. Describe what you did, what you expected and what happened. You don’t need an account: you can leave feedback as a guest without an account. Log one issue per note. If the problem only appears in motion or across several steps, such as an animation or a checkout that fails on the last page, record your screen instead.

What each note carries, so nobody has to ask follow-up questions:

1. The exact element. The CSS selector and HTML of the element that was clicked, so the developer can find it in the code straight away.
2. The page URL.
3. Browser, OS, device and screen size, captured automatically. You’ll never have to ask “what were you using?”
4. A pixel-perfect screenshot of the tester’s own screen. It shows exactly what they saw, not a re-rendering from a screenshot service. Re-rendered images can lose the details that matter, such as a font that didn’t load, a cookie banner covering a button, or a layout that only breaks at that exact width.
5. Console and network errors. See console errors and page details captured with each note, which help explain failures that the tester can’t see.

What a good note looks like:

“Tapped ‘Add to cart’ on the Speckled Mug page. Expected the cart count to go up. Nothing happened, and the button stays grey.”

That note plus the captured details is enough to reproduce the bug. A note saying “cart broken” with no context is not.

If you track work in Trello, Asana or Basecamp, notes can be sent there, so issues land in your normal workflow. Integrations are included on the Team plan and above.

If an AI agent built the site: what humans need to check

Coding agents now build much of the web, and they reliably miss what only shows up in a real browser. The code compiles and the tests pass, but the site still feels off. A person catches these problems in seconds.

If an agent did much of the build, add this scenario block to your plan:

• Spacing and alignment: look for gaps that are uneven or elements that sit slightly out of line
• Clicks: check that every button and link actually responds, including small tap targets on mobile
• Hover and focus states: check they exist, are visible and look consistent
• Overlapping elements: look for sticky headers covering anchors and badges sitting on top of text
• Animations and effects: check timing, jank, and anything that flashes on load
• In-between widths: drag the window from 320px to 1600px and note where the layout breaks

Then close the loop:

1. The agent builds and deploys to staging.
2. The client and PM review staging and pin notes in PageProofer.
3. PageProofer’s hosted MCP server lets the coding agent (Claude Code, Cursor and others) read each note with its selector, screenshot and browser info, make the fix and reply on the note.
4. A person verifies each fix on retest.

The agent does the fixing and the human does the judging. Read more about how to fix website feedback with your AI agent, or connect a coding agent to PageProofer.

Timeline and sign-off

Here’s a sample schedule for a typical small to mid-sized website:

Day	Stage
1	Briefing call (30 minutes) and testing starts
1–4	Testing window
5–7	Triage and fixes
8–9	Retest of fixed issues
10	Sign-off

For larger sites, or ones with several integrations, extend the testing window to a week and plan for a second fix-and-retest cycle. Don’t stretch the testing window open-ended. Feedback dribbles in for weeks and nobody feels responsible for finishing.

Sign-off wording:

The client approver named in your roles table signs, not whichever tester happens to finish last. For more on this, see our guide to getting client sign-off on live sites.

Tip: Make sign-off the trigger for both the launch date and the final invoice milestone. Write this into the plan, and the client has a reason to finish testing on time.

Website UAT checklist (short version)

For smaller jobs that don’t need the full document, use this UAT checklist.

Before

• Scope agreed, with in and out lists written down
• Staging ready, with final content, test payments and test inbox set up
• Testers briefed, with the link, access details and guest feedback instructions
• Scenarios and device assignments shared

During

• Each scenario run on its assigned device
• Every issue pinned on the page where it happens
• Severity suggested on each note

After

• Triage done, with change requests separated from defects
• All Blockers and Majors fixed
• Retest passed
• Remaining Minors accepted with a fix date
• Sign-off received
• Go-live scheduled

FAQ

What should a UAT test plan include?

A website UAT test plan should include the project and version, objective and scope, testers and roles, test environment, test scenarios, browsers and devices, entry and exit criteria, severity levels, instructions for logging feedback, a timeline, and a sign-off section. Each part answers one question the client would otherwise ask you mid-round, such as “what am I testing?”, “how do I report this?” or “when are we done?”

Who should do user acceptance testing on a website?

The client’s own people should do it: the marketing lead, the content owner, sales or customer service staff for forms, and whoever handles orders or bookings. They know how the business works and how customers behave. The agency PM facilitates and developers fix the issues, but the agency shouldn’t be testing its own work at this stage. That already happened in QA.

What is the difference between a UAT plan and UAT test cases?

The UAT plan is the whole document. It covers scope, people, environment, criteria, process and sign-off. Test cases, or scenarios, are one section inside it: the specific tasks testers carry out, each with an expected result. You can reuse the plan structure across projects, but you’ll write new scenarios for every site.

How long should UAT take for a website project?

For a small to mid-sized site, allow about two weeks: around four days of testing, three days of fixes, two days of retesting and a day for sign-off. Larger sites with ecommerce or several integrations may need a second fix-and-retest cycle. Fix the testing window in the plan so it doesn’t drift.

What are entry and exit criteria in UAT?

Entry criteria are the conditions that must be true before UAT starts, such as internal QA being finished, content loaded, staging stable and testers briefed. Exit criteria define when UAT is finished: all scenarios run, zero open blockers or majors, minors fixed or accepted, retest passed and sign-off received. Making both measurable stops UAT from starting too early or never ending.

Who signs off UAT and what does sign-off look like?

The client approver named in your plan signs off. This is usually the business owner or project sponsor. Sign-off is a short written statement confirming the site was tested against the agreed scenarios and is accepted for launch, listing any known minor issues, followed by their name, role, date and signature. An email reply with the same wording also works.

What is the difference between QA and UAT for a website?

QA is the agency checking that the site is built correctly. It works across browsers, has no broken links and matches the designs. UAT is the client checking that the site does what their business needs and accepting it for launch. QA comes first and is done by the agency team. UAT comes second and is done by client stakeholders.

How should clients report bugs during UAT?

Clients should report bugs directly on the page where they happen, not by email or in a spreadsheet. A visual feedback tool lets them pin a note on the exact element, and it records the URL, browser and device info, so the developer can reproduce the issue without follow-up questions. Ask for one issue per note, with what they did, what they expected and what happened.

Run your next UAT round on PageProofer

With PageProofer, client testers pin notes directly on your staging site with no account needed. Every issue arrives with the element, URL, browser and device details and a screenshot of exactly what they saw. If a coding agent built the site, it can pick up the fixes through the MCP server while you verify them on retest. Every plan includes unlimited sites, and plans start at $39/month (Freelancer, Oct 2026 pricing). See PageProofer pricing to start your 15-day free trial. No credit card is required.

Photos: Edsger W. Dijkstra by Hamilton Richards (CC BY-SA 3.0), Donald Knuth by Alex Handy (CC BY-SA 2.0), both cropped, via Wikimedia Commons. W. Edwards Deming photo is public domain (US FDA).