{"id":418,"date":"2026-11-04T10:00:00","date_gmt":"2026-11-04T09:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=418"},"modified":"2026-11-04T10:00:00","modified_gmt":"2026-11-04T09:00:00","slug":"website-acceptatiecriteria","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/when-is-a-new-website-ready-for-acceptance\/","title":{"rendered":"When is a new website ready for acceptance?"},"content":{"rendered":"

A website is not automatically ready because every page is filled and the design is approved. Acceptance asks whether visitors and administrators can do what was agreed. Make that test concrete before the final project week. This prevents discussions mixing taste, missing content and actual blockers.<\/p>\n

From wish to verifiable scenario<\/h2>\n

\u201cThe contact form must work well\u201d is too broad an agreement. Describe who performs the action, with which data and what result must be visible. For example: a new visitor selects a service, submits a question and sees an acknowledgement; the assigned employee receives enough context to handle it.<\/p>\n

Include an imperfect attempt too. Leave a mandatory field empty, use a long name or visit a deep URL directly. These are normal situations. The website must clarify how to continue and must not lose previously entered information without reason.<\/p>\n

For a fictional consultancy website, the core route consists of service selection, explanation and enquiry. An error in that route may block launch. A secondary photograph still awaiting replacement has a different impact. Discuss that distinction with the client beforehand.<\/p>\n

Include management in the handover<\/h2>\n

Have an editor independently change existing text, build a new page and check publication. Use content that differs from the easiest example. If every longer heading needs technical help, management may not be sufficiently developed. This too can form part of the agreed delivery.<\/p>\n

Also check that ownership and working agreements are available. Who receives notifications, who can fix an error and which components need maintenance? For delivering a website<\/a> the visible frontend is not the whole task. The organisation must also be able to use the result.<\/p>\n

Record discrepancies with their impact<\/h2>\n

A useful acceptance list records the page, action performed, observed behaviour and desired outcome for each finding. Add a responsible person and decision. Avoid isolated comments such as \u201cthis does not feel right\u201d without explaining which expectation is unmet.<\/p>\n