How to accept a finished website: a checklist before final payment

A website can look finished while leaving questions about forms, mobile usability, analytics or access handover. Acceptance should therefore be based on the agreed brief and the main visitor journeys.

Your task as the client is to confirm that the agreed result has been delivered and can be used. A specialist can help with technical checks, while your business team can assess whether the content is clear and enquiries actually arrive.

Acceptance and final payment should follow your agreement with the provider. The practical review plan below is worth agreeing before development is complete.

Gather the latest agreed brief, the page and function lists, approved designs and decisions about changes.

If some requirements were discussed in messages, transfer the confirmed decisions into a shared list. Otherwise, participants may review the website against different expectations.

For each task, record three things:

• what should be implemented;
• how it will be checked;
• who confirms the result.

For example: “An enquiry from the service page reaches the CRM with the selected service; the head of sales verifies the result.”

If the project is just starting, include these criteria in the website development brief.

Review the page list and the initial amount of content. Open pages through menus, cards and internal links, as well as through the direct URLs supplied by the developer.

Make sure that:

• the agreed copy and images are in place;
• prices, contacts and terms are current;
• temporary content has been replaced;
• links lead to the intended pages;
• service names are used consistently;
• the language switcher leads to the corresponding version, where provided.

For pages using a shared template, check several challenging examples: a long name, extensive text and no optional image. Review every unique page against the list.

Compare the implementation with the approved designs. Focus first on readability, placement of important information and the ability to complete an action. Record differences together with an explanation of the agreed requirement they affect.

Submit a test enquiry through every form and follow it through to the responsible employee.

Check:

1. Whether fields can be completed and errors corrected.
2. Whether required information is clearly identified.
3. What happens after submission.
4. Whether the enquiry reaches the agreed channel.
5. Whether the required fields and selected service are retained.
6. Whether repeated clicks are handled correctly.
7. Whether there is a clear alternative way to get in touch if submission fails.

A successful submission message does not confirm that the business has received the enquiry. The check ends in the inbox, CRM or other agreed destination.

Label enquiries as tests and notify your employees. Afterwards, handle the test records so they do not distort operational data.

Also check phone links, email, messaging services and booking buttons. Every important action should have a clear destination.

For bookings, check service selection, dates and times, confirmation, staff notifications and the agreed rules for changing a booking.

For an online store or paid service, check:

• order contents and the final total;
• the selected payment method;
• successful and unsuccessful payment flows;
• consistency between payment and order statuses;
• customer and staff notifications;
• data transfer to connected systems.

Use the service's designated test environment. If a real payment is required, agree on the amount and how the transaction will be handled beforehand.

Returning to a “Thank you” page does not by itself confirm payment. Verify the result in the order system and payment service too.

Open the website on a computer and phone without administrator access. Agree with the provider which browsers and devices will be used for acceptance.

Pay particular attention to:

• opening and closing menus;
• reading long headings;
• completing forms with the on-screen keyboard;
• buttons and links positioned close together;
• fixed elements and pop-ups;
• cards, lists and tables;
• horizontal scrolling.

Check an intermediate window width: a problem may appear between the prepared desktop and mobile layouts.

Observe how the main pages load. If text remains absent, a button shifts or the page does not respond, record the conditions and submit the issue for diagnosis. A single speed-tool score cannot replace checking the user journey.

If analytics setup is included in the project, ask to see a test action recorded in the intended property.

For a form, distinguish between:

• a button click;
• a successful submission;
• an enquiry actually received.

A validation error should not count as a successful lead. Also check whether a single action is recorded more than once.

In Google Analytics 4, events can be checked in DebugView after debug mode is enabled. Their visibility also depends on consent and privacy settings, which need to be considered when diagnosing issues. Google's DebugView instructions.

Record which events are configured and what each means. “Analytics is installed” does not explain what your team will be able to measure.

Many checks can be performed on a staging URL before launch. After publication, check the main domain again: forms, links and integrations can depend on the website address.

Within the agreed SEO setup, check:

• availability of important pages;
• titles and descriptions;
• primary page URLs;
• internal links and the sitemap;
• redirects where previous URLs have changed;
• absence of unintended indexing restrictions.

Ask a specialist to check robots.txt and noindex separately. They perform different tasks: blocking crawling does not replace a directive that prevents indexing. Google must be able to access the page to process noindex. Google's documentation on noindex.

A new website's indexing should not be treated as an outcome that must occur on handover day. Even a recrawl request does not guarantee inclusion in search. Acceptance checks the implemented settings; subsequent processing is monitored separately. Google's guidance on requesting a recrawl.

For a broader assessment of readiness for advertising and SEO, use our website audit plan before promotion.

The company should have the agreed access to the project and related services. Open them under your own account and confirm that the necessary actions are available.

Record:

• where the domain is registered and who renews it;
• who owns the project on the platform or hosting service;
• where analytics and connected services are located;
• which subscriptions and licences need to be paid for;
• which designs and source files are handed over;
• how to save and restore data within the platform's capabilities;
• what employees can edit independently.

Ask for a practical demonstration of changing text, an image and one repeating item, such as a service or article.

For non-standard functions, clarify where the code and maintenance instructions are kept. The materials to be handed over depend on the development approach and should be agreed for your project.

Each issue should include the page, conditions, reproduction steps and expected result.

Illustrative example:

Separate feedback into:

• errors that block the main user journey;
• departures from the agreed brief;
• additional requests.

Assign an owner, deadline and verification method to each item. Estimate new functions separately from corrections to the agreed work.

After fixes, check the complete modified journey and related elements. In the final record, document the accepted version, materials handed over, remaining agreed tasks and support terms.

• Pages, functions and initial content have been checked against the scope.
• Main user journeys work on the agreed devices.
• Test enquiries reach the responsible employee.
• Bookings and payments have been checked, where included.
• Agreed analytics events have been confirmed.
• Live URLs and SEO settings have been checked.
• Access and materials have been transferred and can be opened by the client.
• The team can make the necessary updates.
• Issues have been fixed or recorded in an agreed plan.
• Support terms and the process for requesting help are clear.

If you need an independent technical review, consider a website audit. When commissioning it, define which requirements, pages and workflows are checked, whether a follow-up review is included and how issues are documented.

Acceptance is meaningful when the business understands what it has received, how it works and who is responsible for ongoing maintenance. This process helps move from development to using the website with clear agreements.