Website acceptance: a practical checklist before launch

Accepting a website means checking that a visitor can complete the intended task and your business receives the result. An attractive homepage or a success message does not prove that a request reached the sales team. Before launch, list the workflows to test, appoint a business owner and agree which defects prevent release. This guide covers a corporate site or landing page; stores, customer portals and payments need additional scenarios.

1. Compare delivery with the agreed scope

Open the proposal, page structure and latest approved requirements. Check pages, languages, forms, integrations and editable content. Give every requirement an observable outcome: instead of “easy CMS”, use “an editor changes and publishes a price without a developer”. Record newly requested features separately. This keeps a missing deliverable distinct from an extension of the project and gives both teams something concrete to discuss.

2. Follow a request through to the recipient

Agree a test submission so the sales team recognises it. Try valid and invalid input, a repeated click and an unavailable integration. Compare the contact, message, page language and recorded source with the received record. If a CRM is included, check ownership and the next status. A confirmation should reflect actual storage rather than merely a button click, and explain what the visitor can expect next.

W3C guidance supports clear validation and notifications: identify required fields, explain how to fix errors, and distinguish a successful submission from a failure. References: https://www.w3.org/WAI/tutorials/forms/validation/ and https://www.w3.org/WAI/tutorials/forms/notifications/ .

3. Check a phone and both languages

Visit the homepage, a service page and the form on a real phone. Continue to the bottom: navigation, consent, error feedback and footer links are part of the journey. For RU/UZ, compare prices, field labels, confirmations and messages received by staff. Switching language should preserve the current page’s purpose. List untranslated exceptions explicitly rather than treating incomplete content as a finished language version.

4. Separate search access from ranking promises

Ask which pages are indexable, where the sitemap is located and how canonical and language links are configured. Important content must be accessible to crawlers; migrated addresses should lead to relevant replacements. A speed score does not substitute for a working form. Google explains the technical foundations without guaranteeing indexing or rankings: https://developers.google.com/search/docs/fundamentals/seo-starter-guide .

5. Complete an acceptance record

Add a tester, date, status and issue link to every row. Prioritise lost requests, exposed data and blocked core workflows before launch. Agree an owner and date for anything accepted as outstanding. This is a suggested delivery process, not a universal legal acceptance document.

6. Agree ownership and ongoing support

Check who owns the domain, hosting, repository, CMS and analytics. Transfer secrets through an agreed secure channel and record account purpose and responsibility separately. Confirm where backups live, how recovery works and who handles an incident. Distinguish agreed defect fixes from separately priced changes. Receiving an archive alone does not explain how the operating site will be maintained.

Include these criteria in a new project brief: https://samsa.agency/en/services/web-development . For an existing site, discuss review and maintenance at https://samsa.agency/en/services/website-support . Share the URL and the actions visitors must complete to define the review scope.