Practice ·
Accept an AI-built website by testing what can go wrong
A website built with AI can look complete after its first few iterations. Pages open, animations run and copy sits in place. Acceptance begins beyond that impression, with real journeys, unexpected data, a slow network, failed integrations and the ability of another person to continue working on the project.
Review a mock-up with your eyes and a product through action
A first look answers whether the result resembles the agreed direction. It does not show whether a visitor can complete a task. Testing needs a short list of essential journeys: find a service, open an article through a direct link, submit a form, change language, go back and continue after reloading.
Walk through each journey in a clean browser profile or on an unfamiliar device, without the author's knowledge of the structure. If an action makes sense only to someone involved in development, the interface still depends on the team's private context.
AI accelerates construction and can also produce a convincing simulation of readiness. Test the outcome of every action: the enquiry arrived, the address persisted, state was retained and a failure received a useful explanation.
Screen size changes more than width
Responsive behaviour is more than avoiding horizontal scrolling. A narrow screen changes reading order, line length, touch targets and the position of actions. At an intermediate width, a grid may technically retain two columns while long titles break its rhythm and create accidental gaps.
Test a range of widths rather than three named devices. Pay particular attention to boundaries where a column disappears, a fixed block returns to document flow or navigation becomes compact. Errors often live between the familiar layouts.
Text enlarged to 200%, keyboard navigation and the system preference for reduced motion also reveal whether the interface is ready for real use.
Test forms with incorrect data
A successful submission of a perfect form proves one case. Acceptance also covers empty fields, an invalid address, a repeated click, loss of connection, a slow response and an unavailable external service. The user should understand what happened and whether the action should be repeated.
Follow the entire path of the data. A message saying “sent” in the interface does not prove that the recipient received the enquiry. Server confirmation, duplicate protection, an error log and a recovery path are required.
If the website collects personal data, technical review must include a clear purpose, consent, a minimal set of fields, a retention period and a working way to delete the information.
Search visibility begins in the page code
A beautiful heading in the interface does not replace the title, description or semantic HTML structure. Every important page needs its own address, canonical reference, single primary heading and content available to a crawler without depending on an accidental application state.
For a multilingual site, review every language version and the relationships between them. For an article, check its date, author, page type, internal links and sitemap entry. Drafts and utility pages should remain outside the index.
Automation can validate these elements, but reviewing the search snippet is still an editorial task. It should promise exactly what a person will find on the page.
Test speed and security before publication
A local network and a powerful computer conceal heavy images, unnecessary JavaScript and delayed primary content. Test on a phone and a constrained connection: when does useful content appear, does the layout move, and can someone begin before secondary graphics finish loading?
Secrets, keys and internal addresses must not enter client code or repository history. Forms need server-side validation, request limits and safe failure behaviour. Dependencies should build from fixed versions and be checked before release.
AI can propose an implementation but does not carry the consequences of publication. The decision that protection is sufficient remains with the product owner and those responsible for its operation.
Handover completes acceptance
A website is not accepted if it works only in its author's environment. The owner needs access to the domain and hosting, a clear way to update content, a list of external services, release instructions and the ability to restore an earlier version.
Handover exposes hidden complexity better than a final demonstration. If a new person cannot run the project, understand its configuration and trace an enquiry, the system depends on one maker's memory.
Within the Method, acceptance connects the Concept with the consequences of a working website. I review more than visual fidelity: the user's journey, data, search structure, failure behaviour and the ability to continue development after release.
Start with the website's purpose
If you are planning a website or rethinking one, we can begin with its role in your business, its structure and the visitor's path to an enquiry.