How to accept a website: scenarios and evidence, not “all done”

A common acceptance problem is discussing the meaning of “ready” for the first time when the website is already built. Before work starts, list the actions the project exists to support: finding a relevant service, understanding a product, sending an inquiry and editing terms in the CMS. Each action needs starting conditions, an expected outcome and a person who will verify it.

An illustrative row: “A new visitor opens a service on a phone, selects a project type and submits a valid contact. The working system confirms receipt; the visitor sees the agreed feedback and the manager receives context.” The outcome depends on the delivery contract you select.

Demonstrating one successful submission is insufficient. Check an empty required field, an invalid contact, a slow response and a temporary server failure. People should understand what to correct, and their input should not disappear unnecessarily. W3C recommends clear feedback after submission and understandable error notifications.

Review resubmission separately: agree what represents the same operation and what is a new inquiry. If an external service accepted the data but its response was lost, a straightforward retry can create a duplicate. Retain observable delivery evidence rather than relying on a green notification. Agree and label any real test inquiries in advance.

Open a working product or service rather than a demonstration template. Change its name, a long description, an image and a link. Check preview, publishing and restoration of the previous version if that feature is in scope. This reveals constraints that a polished mockup cannot show.

A catalogue needs checks for an empty category, long names, missing images and discontinued products. The published Milerd case includes a catalogue, product variants, a cart and an administration panel. Those different journeys illustrate why looking correct is only part of acceptance.

Agree browsers, devices and viewport widths before testing. Complete the main journey on a phone, with its on-screen keyboard, and using only Tab, Shift+Tab and Enter. Review visible focus, dialog closure, long text and reduced-motion behaviour. An automated report does not replace this walkthrough.

For performance, retain the conditions of the lab measurement: page, device, network and website version. Core Web Vitals distinguish laboratory and field data. A good result from one run does not establish every visitor’s experience; missing field data means insufficient measurement, not perfect performance.

For a redesign, create a mapping from old URLs to their new equivalents. Check important services, cases and articles, not just the homepage. Do not redirect unrelated pages to one section simply to eliminate 404 responses: Google warns that such redirects can be treated as soft 404s.

Separate HTTP availability, canonical URLs, language versions and accidental noindex from actual inclusion in a search index. Indexing and search positions are not guaranteed release outcomes. Access to Search Console and webmaster tools lets you observe the next stage without removing that limitation.

Transfer the domain, repository, hosting, CMS and necessary work accounts through an agreed secure process. Document account owners, recovery methods, backups, known constraints and incident contacts. Avoid putting secrets into a shared handover document or message.

Separate launch blockers from agreed later improvements. For each issue, retain a specific scenario, expected behaviour and owner. After launch, reconcile incoming inquiries with the working system and monitor errors in real traffic. Further development should respond to observations and sales outcomes rather than the formal completion of a checklist.