Back to Blog

Best Practices

How to test whether an AI agent can use your website

A practical walkthrough: see your site the way an AI agent reads it, using tools already in your browser. Five checks, no new software, about twenty minutes.

2 August 2026

10 min read

Ravid, Webply

The short version

You can see your site the way an AI agent sees it using tools already in your browser. Five checks, about twenty minutes, no new software. The fastest one — tab through the page and watch what gets announced — finds most of the problems on its own.

When we measured 116 European business websites, 114 of them had at least one finding that stops a machine from working out what a control is or does. The most common failures were not exotic — unnamed icon buttons, links called "read more", missing page structure.

The obvious next question is whether your site has them. Here is how to check by hand, without buying anything.

First: what you are actually looking at

An agent operating a browser does not see your CSS. It generally works from some combination of three things: a screenshot, the raw HTML, and the accessibility tree — the map the browser builds of every element's role (what it is), name (what it is called) and state (open, checked, disabled).

The accessibility tree is the one that matters most, because it is the only one that states intent outright. A screenshot shows a grey rounded rectangle with a cart icon; the accessibility tree says button, "Add to basket". That difference is the whole game. We covered the mechanism in how AI agents and AI search read your website — this article is the hands-on version.

Everything below inspects that tree.

Check 1 — Tab through the page (2 minutes)

The single highest-yield check, and it needs no tools at all.

Load your homepage and click once on the very top of the page.
Press Tab repeatedly and watch what gets highlighted.

Three things to look for:

Can you see where you are? If the focus ring is invisible on some elements, you have a keyboard problem for humans. Agents don't care about the ring, but its absence usually means the element is a div pretending to be a button — which they very much do care about.
Does Tab reach every interactive thing? Menus, carousel arrows, the cart, the cookie banner, the search toggle. Anything Tab cannot reach is usually not a real control, and is therefore not in the accessibility tree at all.
Does the order make sense? If focus jumps from the header to the footer and back, the DOM order does not match the visual order, and an agent reasoning about "what comes next" will get it wrong.

Anything Tab skips is a candidate for the next check.

Check 2 — Read the accessibility tree directly (5 minutes)

This is the closest you can get to reading what the agent reads.

In Chrome or Edge:

Open DevTools (F12).
Go to the Elements panel.
In the right-hand pane, open the Accessibility tab.
Tick Full-page accessibility tree at the top.

You now have a tree of nothing but roles and names. Scroll it and read it as a stranger would.

What you are looking for:

Entries that read link "" or button "" — a control with no name. This was the sharpest finding in our corpus: 4,735 links and 607 buttons with no machine-readable name at all. They are almost always icon-only controls.
Entries named "click here", "more", "read more", "→". The name exists and says nothing. We found 3,196 of these.
Big blocks of content sitting under generic with no main, navigation, or contentinfo above them.

If a section of your page is a flat run of generic nodes, an agent has no map of your page and is working purely from DOM order.

In Firefox: the Accessibility panel does the same job, and its "Check for issues → Text labels" audit will list unnamed controls for you directly.

Check 3 — Ask an actual agent (5 minutes)

The empirical version. Open any AI assistant that can browse, and give it a task rather than a question:

"Go to example.com and tell me, step by step, exactly which elements you would click to book a room for two nights in September. Name each control exactly as it appears to you."

The instruction to name each control as it appears is the part that matters. You are not testing whether the model can describe your business — it can do that from the page text. You are testing whether it can identify the controls. Watch for:

The agent describing a control by its position ("the button in the top right") rather than its name. That means it has no name to use.
The agent inventing a plausible-sounding label that is not on your site.
The agent stalling at the form step.

Do it twice with different phrasings. A model that succeeds once and fails once is telling you the path is ambiguous, not that it works.

Check 4 — Check your forms specifically (5 minutes)

Forms are where an ambiguous page turns into a lost transaction, so they deserve their own pass. In our corpus, 46 of 116 sites had at least one page with an unlabelled field.

For each input on your most important form — checkout, booking, quote request:

Click the input's visible label text. If focus moves into the field, the label is properly associated. If nothing happens, it is not.
In the Accessibility pane, confirm each field has a name that describes the data, not the format. "Postcode" is a name. "Enter 4 digits" is a hint being used as a name.
Check that placeholder text is not doing the labelling. Placeholders vanish on focus and are not exposed as labels — a field whose only identification is a placeholder is unnamed the moment anyone starts typing.

Check 5 — Confirm the machine-readable basics (3 minutes)

Fast, and each is a one-line fix if it fails.

<html lang> is set and correct. View source, look at the opening tag. 55 of our 116 sites had no lang at all. It tells any language model which language it is reading — which matters more in multilingual markets than in English-only ones.
The page has exactly one <h1>, and it describes the page. Not the company name on every page.
<title> is unique per page.
There is a <main>. One per page, wrapping the actual content.
Your robots.txt does not block the agents you want. Worth a deliberate decision either way: some organisations genuinely want to exclude AI crawlers, and that is a legitimate choice — just make it on purpose rather than by inheritance from a template.

Interpreting what you find

Two things are worth saying about the results, because both are easy to get wrong.

A clean pass is not proof an agent can transact. These checks establish that the agent can perceive and identify your controls. Whether it can complete a purchase also depends on bot protection, CAPTCHAs, step-up verification, and payment flows built specifically to resist automation. Passing means that if an agent fails on your site, it will not be because it could not tell what your buttons were.

A pile of findings is usually a small pile of causes. This is the useful part. 4,735 unnamed links across 79 sites in our corpus is not 4,735 mistakes — it is a handful of shared components rendered many times. One header, one card, one icon-button component. Fix the component, and every page built from it is fixed at once. Start by grouping your findings by component, not by page, and the work usually collapses to an afternoon.

The shortcut

If twenty minutes of manual checking is twenty minutes you don't have, our Instant Check runs the automated portion of the above on your homepage with no signup — it will find the unnamed controls, the missing labels, and the missing landmarks. It will not do checks 1 and 3, which need a human and an agent respectively, and those are the ones that find the interesting failures.

Either way, the fix list is the same list that makes your site usable for screen-reader users and moves it toward European Accessibility Act conformance. That overlap is not a coincidence — it is the whole reason this works.

Frequently asked questions

How do AI agents read a web page?

Production agents generally combine three views: a screenshot, the raw HTML, and the accessibility tree — the browser-generated map of every element's role, name and state. The accessibility tree is the most reliable of the three because it discards visual noise and states outright what each control is and does, which is why it has become the default input for browser-operating agents. It is the same structure a screen reader announces.

Can I see the accessibility tree without installing anything?

Yes. Chrome and Edge have it built in: open DevTools, go to the Elements panel, and open the Accessibility pane on the right, then enable "Full-page accessibility tree". Firefox has an Accessibility panel that does the same. No extension or paid tool is required for any check in this article.

What is the fastest single check?

Tab through the page with the keyboard and watch what gets announced in the accessibility pane. If you reach a control and its name is empty, or it is called something like "link" or "button" with no further detail, an AI agent has exactly as little information as you just got. That one pass finds most of what stops an agent, in about two minutes.

Does passing these checks guarantee an agent can complete a purchase?

No. These checks establish that the agent can perceive and identify the controls, which is the precondition. Completing a real transaction also depends on things outside the page's semantics — bot protection, CAPTCHAs, multi-step verification, and payment flows that deliberately resist automation. What the checks guarantee is that if an agent fails on your site, it will not be because it could not tell what your buttons were.