Before you hand over an AI built website, test these seven things

1. Walk the path that earns the client money

Open a private browser window. Start at the page a new visitor is likely to reach, not at the convenient URL you used while building.

1. Find the main offer without using the site map or admin interface.
2. Follow the call to action.
3. Complete the form, booking, enquiry, or test purchase.
4. Confirm that the success message is clear and the promised email or record actually arrives.

If there are three important paths, write them down before testing. A test that changes its goal after seeing the page usually proves whatever the tester wants it to prove.

2. Put the mouse aside

Use only Tab, Shift plus Tab, Enter, Space, and Escape.

• You can see where keyboard focus is.
• The focus order follows the page.
• Every menu, selector, button, modal, and form control can be reached.
• Enter and Space activate controls when expected.
• Escape closes a modal or menu without losing your place.

This catches a common failure that a markup scanner can miss: an element that looks and clicks like a button but is absent from the keyboard order.

3. Make the form fail on purpose

The successful path is usually the one that received the most attention. Try the paths that were not in the happy prompt.

1. Submit required fields empty.
2. Use a badly formed email address.
3. Enter the longest realistic name and company name.
4. Submit twice.
5. Refresh after the success state.

An error must say what happened, point to the affected field, and be available to assistive technology. A red border by itself is not an explanation.

4. Change the screen, the zoom, and the content

Check at 360 pixels wide, a tablet width, and a normal desktop width. Then zoom to 200 percent.

• No horizontal scrolling is needed to read ordinary content.
• The primary action is not covered by a cookie banner or fixed footer.
• Navigation can open and close.
• Long headings, prices, and error messages wrap without hiding controls.
• Touch targets are comfortably separate.

Do not test only with the tidy placeholder copy from the design. Real names, translated labels, and validation messages are often longer.

5. Read what the browser is complaining about

Open the browser console and network panel while repeating the main path.

• Look for uncaught errors.
• Look for requests that return 404 or 500.
• Confirm images, fonts, and scripts are served securely.
• Check that a failed third party request does not make the page unusable.

A page can look finished while its form request fails in the background. The browser usually tells you. Someone still has to look.

6. Check the page people and search engines receive

• The page has one useful title and one clear main heading.
• The document language is declared.
• Images have useful alternative text when they convey information.
• Links make sense outside the surrounding sentence.
• The canonical address points to the page you intend to publish.
• The page is not accidentally blocked from indexing.
• The status code matches the content. A missing page must not return 200.

These are not tricks for ranking. They are basic signals that the published page says what it is and can be understood.

7. Leave evidence another person can retest

A useful finding is not “the mobile page is broken.” Record:

1. The exact page.
2. The browser and screen size.
3. The action taken.
4. The expected result.
5. The actual result.
6. A screenshot, console message, or small code reference.
7. The result of the retest after the change.

That turns feedback into work a developer can finish. It also gives the agency something concrete to include in the client handoff.