Website acceptance testing for site owners

Signing off: final payment, warranty, and after

Sign-off is when you declare the site matches what you ordered. In many contracts, it triggers the final payment and starts the warranty period. After it, a fix can turn into a billed change request.

So reread your contract before you start: how long you have to report issues, what it treats as acceptance without a signature (going live, or no answer within a set time), and what the warranty covers after delivery. If it says nothing, agree on these points in writing with the builder before the first check.

Three checks, three people

Acceptance brings together three checks, and none of them replaces the other two:

• The builder tests what they built: every form reaches the right inbox, the site's admin works, pages display on the browsers and devices listed in the contract, test payments go through on a store. Ask for the report on those tests: what was tested, on what, and with what result. An outside review doesn't redo them: it doesn't submit your forms or log into the admin.
• You judge what nobody else can: the copy is right and final, prices, opening hours and contact details are correct, the legal notice names your company. Walk through what your business depends on, a quote request, a booking or a purchase, all the way to the end, on your phone and on a computer, and check that a real request arrives.
• An outside reviewer checks what happens behind the pages: what the browser loads before the visitor answers the cookie banner, server responses and redirects, the instructions given to search engines, speed on a phone, errors on page load.

Those points are laid out by priority in the website audit checklist.

Staging versus the live site: what launch changes

These percentages cover about 30 websites we audited between August 14, 2026 and September 24, 2026. Each one counts only the sites where the point could be checked. Many were audited because a defect showed up quickly, so these figures describe our audits, not websites in general.

Acceptance testing on staging struggles with all three: placeholder text sits on a page nobody reopens, slowness only shows on the real site on a phone, and an error may come from a script added at launch. Many launch defects don't exist on the staging copy at all. They appear when the site changes address, server or settings:

• The certificate has to be issued for the real domain, and the http address has to send visitors to https in a single redirect.
• Speed gets judged on the live site, on a phone, with the real images and the third-party scripts added at launch. A fast staging copy tells you nothing about the public site.
• The instruction that kept search engines out of staging must not follow the site live: a robots.txt that blocks everything, or a noindex on every page, and the site launches where nobody can find it. In the other direction, a staging copy left open to search engines can compete with the real site in results.
• Final images, added with the final content, each need alt text when they carry information. The cookie banner added at launch has to stay readable and usable from the keyboard.
• The tag manager, analytics and ad pixels are often added for launch. They must not load anything before the visitor chooses. And the legal notice has to name the host of the public site, which isn't always the staging host.
• Pointing the domain at the new hosting must not break email: messages to the domain have to keep arriving, and its SPF and DMARC records have to stay published.
• Every service added at launch, a font, a map, a video or analytics, receives your visitors' IP addresses. Know which ones are served from outside the EU.
• Placeholder text left on the live site hides on a secondary page nobody has reopened since the mockup.
• JavaScript errors on page load may only appear with the live site's scripts, and an address that doesn't exist has to return a real 404 error.

Test settings can travel to production too. In the sample report on an online store we publish, a test resource from a payment partner, served from its pre-production address, loads on the pages of the public site. Nothing on screen shows it. On a staging copy, a test resource is expected; on the live site, it is a defect.

That's why the check that counts happens on the live site, in the days after it goes public.

Writing a punch-list item that gets fixed and closed

Each item should let the builder find the defect without calling you. It includes:

• the page address, or "all pages" when the defect comes from a shared element such as the menu or the footer;
• what you saw, with the value or the excerpt: "the request sent from the Quote page never reached the expected inbox" rather than "the form doesn't work";
• what was expected: the section of the spec, the mockup, or the legal requirement involved;
• how serious it is: blocking if it keeps the site from opening to the public or exposes you as the site owner (a form that never arrives, trackers loading before the visitor chooses, a missing legal notice), non-blocking otherwise;
• the agreed deadline for the fix.

Signing off with a punch list records what still has to be fixed, which is often fairer than a flat refusal or a signature with nothing written down. Agree in writing on what happens to the final payment while blocking items remain open.

An item is closed when the defect is gone from the live site, not when the builder says it's fixed. Have the same points checked again.

The schedule, from staging to final payment

A sequence that covers both the staging copy and the live site:

1. The builder hands over the report on their tests.
2. You run your own acceptance on staging: copy, contact details, key journeys.
3. The site goes live.
4. In the days that follow, an outside reviewer checks the live site, and you repeat your journeys on the public site.
5. The punch list goes to the builder, each item with its severity and deadline.
6. After the fixes, a second check shows what is closed. You sign off, and the final payment is made as agreed.

If your contract has you sign off before launch, keep a check of the live site before the final payment, and write it into the sign-off document as an open item.

A punch list written straight from the report

Ordered at launch, the audit reviews the public site the way your visitors receive it, across all 9 pillars, with no access to the admin, the hosting or the builder. Pages are opened in a browser without answering the cookie banner. Redirects are followed from http and https, instructions to search engines are read, every page is measured on a phone, errors and third-party resources are recorded as each page loads, and the most common staging subdomains are checked.

Every finding in the report already carries what a punch-list item needs: the page involved, the value recorded, and the law, standard or specification when the point depends on one. You can write the punch list straight from the report.

Every limit of the review is stated in the report. A point we could not verify is never presented as compliant. To close the punch list, a second audit applies the same criteria to the fixed site and shows, point by point, what is gone.

The report is delivered in 5 working days up to 60 pages, so build that into your acceptance schedule. Plans start at €200 excl. VAT, the pricing page lists them, and payment is collected on delivery.