Website acceptance testing: what to check before project handover and launch

A website should not be accepted merely because it looks finished and its main buttons work. Before handover, check compliance with the requirements, critical user journeys, content, the mobile version, accessibility, performance, SEO, analytics, security and readiness for maintenance. Every check needs an expected result, a responsible person and evidence. Approve the launch only when no blocking defects remain unresolved, acceptable shortcomings have been agreed and a rollback plan is ready. This approach to website acceptance testing reduces the risk of customers or search engines being the first to discover serious problems.

What website acceptance testing means

Acceptance testing is the client’s verification that the delivered solution meets the agreed requirements and is ready for its intended use. It should be based not on subjective impressions, but on the technical specification, approved designs, content structure, integration descriptions and acceptance criteria.

It should not be confused with the developer’s quality assurance. The developer checks the code, components and technical operation, while the client approves the business outcome: whether a customer can find a service, submit an enquiry and receive the correct confirmation, and whether the business receives usable data. User acceptance testing, or UAT, is the part of this process in which people familiar with the actual workflow test the solution.

Testing after launch is still necessary because the domain, cache, analytics and external integrations may behave differently in the production environment. However, it does not replace pre-launch testing.

Start with a requirements and test matrix

A checklist becomes useful only when every item can be accepted or rejected unambiguously. Create one acceptance matrix instead of scattering comments across emails, chats and screenshots.

For example, the requirement “the enquiry form works” is not precise enough. A testable criterion is: after the required fields are completed, one enquiry is created, the user sees a confirmation, the responsible person receives a notification and the agreed event is recorded in analytics. Invalid data, repeated button clicks and the unavailability of an external service should be tested separately.

If a feature was not described in the requirements, the acceptance stage is not the right time to make it mandatory without discussion. It should be recorded as a new change requiring a separate decision on scope, deadline and cost.

Prepare the environment, roles and test data

Before testing, agree which version is being tested. Test results lose their value if the development team changes code or content at the same time without recording those changes. The version needs an identifiable release number or change list. After fixes, repeat the specific test and the related scenarios.

The test environment should replicate the production configuration as closely as possible, but real customers’ personal data must not be used carelessly. Prepare controlled test users, email addresses, files, and test modes for payments or integrations. Define the roles as well: who checks the content, who checks the business processes, who checks the technical requirements and who has the authority to make the final decision.

Record known limitations before testing begins. If the test environment cannot verify production email delivery or a payment, for example, plan a controlled check of that scenario during launch.

Test complete user journeys, not isolated pages

A website creates value when a task is completed, so functional tests should be organised around the most important user journeys. For a service business, these may include finding a service, reading the terms, checking contact details and submitting an enquiry. In e-commerce, a journey may include selecting a product, using the basket, choosing delivery, paying and receiving an order confirmation.

For each critical journey, test:

•          a successful scenario from beginning to end;
•          empty, invalid and boundary values;
•          clear error messages next to the relevant field;
•          protection against accidental duplicate submissions;
•          the outcome in email, CRM, payment and other integrations;
•          whether the user can continue after an error or interrupted session;
•          links, downloads, search, filters and language switching if they are within the project scope.

Seeing a “sent” message is not enough. Verify that the data reaches the intended system, retains the correct meaning in each field and does not create a duplicate. If there is an administration interface, also test content creation, previewing, publishing, unpublishing, user permissions and the ability to undo incorrect actions.

Content, mobile experience and accessibility

Finding typographical errors is only one part of content testing. Ensure that names, prices, contact details, opening hours and service terms are consistent. Also check the page heading hierarchy, button labels, image alternative text, file names, the 404 page and content in every language that will be published. Placeholder text, test entries and unfinished pages should be found through a content inventory rather than by browsing only the home page.

Test the responsive design at several real screen widths and in at least the browsers supported by the project. In addition to appearance, assess menu usability, form fields, the effect of the on-screen keyboard, horizontal scrolling, touch targets, modal windows and long headings. An automated device emulator helps, but does not fully replace testing on a physical phone.

Combine automated tools with manual use when testing accessibility. Check keyboard operation, visible focus, a logical focus order, form labels, error identification, colour contrast and whether the content can be understood without images. W3C WCAG 2.2 provides testable criteria, but the target level of conformance should be defined for the project in advance. An automated score alone does not demonstrate full compliance.

Performance must be measured, not judged by feel

A page may seem fast on a developer’s computer and a high-speed office connection while performing poorly on a customer’s device. Test the main page types in mobile and desktop views, using both laboratory tests and real-user data available after launch.

The Google web.dev Core Web Vitals thresholds for a “good” experience are LCP of up to 2.5 seconds, INP of up to 200 milliseconds and CLS of up to 0.1, assessed at the 75th percentile. These metrics provide a consistent way to evaluate loading, interaction responsiveness and visual stability, but they are not the only quality criteria. Also check image sizes, font loading, third-party scripts, caching and server errors.

If a target is not met, record the specific page, device profile and test conditions. An isolated result without context is not a reliable basis for an acceptance decision.

SEO, indexing and analytics

Before launch, check that every indexable page has a unique title, meta description, one main H1, a clear URL and internal links. Ensure that the canonical points to the intended URL, links between language versions are consistent and a map of 301 redirects has been prepared for old addresses. Test redirects through to the final address, avoiding unnecessary chains or loops.

Mechanically transferring test-environment protection to production is particularly dangerous. Before and immediately after launch, check robots.txt, noindex, the canonical, the XML sitemap and server response codes. Google’s documentation emphasises that robots.txt controls crawling access; it does not reliably prevent a URL from appearing in search results. A confidential environment should be protected through authentication, not merely through instructions to robots.

Create a separate test plan for analytics. Check that page views and key events are recorded once, contain the required parameters and do not include unnecessary personal data. Also verify the agreed behaviour of the consent solution, internal traffic rules and the retention of campaign parameters. After launch, compare test events with the corresponding real action in the system, such as a received enquiry.

Security and personal data processing

Acceptance testing does not replace a professional security audit, but basic controls must not be ignored before launch. Check HTTPS and redirection from HTTP, administrator access, role permissions, password recovery, file uploads, input validation, error messages, dependency updates, backups and activity logs. Test accounts, default passwords, debugging mode and publicly accessible configuration files must not remain in production.

The OWASP Web Security Testing Guide can provide a structured basis for more thorough testing, but the required scope depends on the risk. A public information website and a system with customer accounts, payments or sensitive data cannot be tested to the same depth.

For forms, check what personal data is requested, where it goes, who can access it and how long it is retained under the company’s approved process. The European Union’s General Data Protection Regulation defines principles for processing personal data, but technical acceptance testing does not establish legal compliance. A competent specialist should assess the legal basis for the privacy notice, cookies and consent solution.

The launch plan is part of acceptance

Even a thoroughly tested version can cause problems if deployed incorrectly. The launch plan should specify the sequence of actions, responsible people, access permissions, expected downtime, DNS or domain changes, data migration, cache clearing and communication with stakeholders.

The rollback plan should answer three questions: what signal will stop the launch, who will make the decision and how the previous working version will be restored technically. A backup is not enough if its restoration process is unknown and it has not been verified to contain the required data.

Immediately after launch, perform a short production check:

•          open the most important pages and check the server responses;
•          submit a controlled enquiry and verify the complete data flow;
•          check redirects, the canonical, robots.txt and noindex;
•          confirm analytics events and the consent mechanism;
•          review error logs and the status of key integrations;
•          check administrator access and the creation of a backup.

This check should be brief and prepared in advance. The production environment is not a suitable place for uncontrolled experimentation.

How to make a go/no-go decision

The number of defects alone is not a sufficient decision criterion. One defect that exposes customer data or prevents an enquiry from being submitted matters more than several cosmetic shortcomings. Define priorities in advance for the project, such as a blocking defect, a major defect, an issue with an acceptable temporary workaround and a cosmetic imperfection.

Launch may be considered if:

•          the mandatory acceptance criteria have been met;
•          no blocking security, data or core-functionality issues remain unresolved;
•          every known issue has an owner, a deadline and an explicitly accepted risk;
•          the launch and rollback plans have been prepared and understood;
•          the handover documents and required access permissions have been received.

If the company knowingly launches with minor defects, the decision should be documented. “We will fix it later” without a responsible person and a deadline is not risk management.

What to receive at project handover

An accepted website is not yet a manageable website. Depending on the project, the handover package should include access permissions and their owners, the location of the code and configuration, deployment instructions, domain and hosting information, a list of integrations, backup procedures, the analytics configuration, a list of licences and external services, and known limitations.

The warranty period or ongoing maintenance process should also be agreed: where to report a defect, how to set its priority and who may approve changes. Passwords should not be handed over in a single unprotected document; access should be granted in a controlled manner and reviewed after handover.

Limitations and risks

No checklist can prove that a website contains no defects. The result is limited by the quality of the requirements, the selected devices and browsers, the test data and the availability of external systems. Automated tools identify only some accessibility, security and performance problems, while a test environment cannot fully reproduce real traffic.

Acceptance is therefore a risk decision, not proof of absolute perfection. Higher-risk features require more thorough security, load, legal or accessibility testing by a specialist in the relevant field.

Conclusion

Effective website acceptance testing connects requirements, real user journeys, evidence and a clear launch decision. With one test matrix, defined defect priorities, responsible roles and a verifiable rollback plan, project handover is no longer a subjective review. It becomes a controlled transition from development to a maintainable production system.