What an AI agent sees when it visits your store

When your team reviews a product page, they look at it in a browser, logged in, with the cookie banner long since accepted. An AI agent arriving for a customer gets none of that. Depending on the kind of agent, it reads your raw HTML, looks at the page as it's drawn, or works through the page's accessibility tree. Here is one fictional product page seen all three ways, and what each view gets wrong.

The page

Northwind Outfitters sells running gear at northwind.example. Its product page for the Trail Runner 2 looks good to a person: a large photo, the name, a price of $129, a row of size swatches, an "Add to cart" button and, on a first visit, a cookie banner across the bottom half of the screen. Like many modern stores, the page is built in the browser: the server sends a shell, and JavaScript fetches the product and fills it in.

A shopper asks an AI assistant: "Find me a trail running shoe under $150 in a size 10 that I can get this week." Here is what Northwind's page looks like to the agents that might come to answer.

View 1: the raw HTML

AI assistants that fetch a page because someone just asked a question, and the crawlers behind AI search, usually request the page and read the HTML that comes back. Many don't run JavaScript at all. This is what Northwind's server sends:

<html>
<head>
  <title>Northwind Outfitters</title>
</head>
<body>
  <header><a href="/"><img src="/logo.svg"></a></header>
  <div id="app">Loading…</div>
  <script src="/assets/app.4f9c.js"></script>
</body>
</html>

That's the whole story for this kind of agent. No product name, because the title is the store's name. No price, no sizes, no stock and no structured data. The assistant can't tell the shopper the Trail Runner 2 costs $129 or comes in a size 10, so it recommends a shoe from a store whose page it could read.

Nothing on screen warns Northwind's team about this. The page looks perfect in every browser they own. It's the problem our guide to JavaScript-only content is about, and the reason Product structured data and machine-readable prices belong in the HTML the server sends.

View 2: the rendered page

Browser agents run a real browser. They load the page, let the scripts run, and decide what to do next, often by looking at a screenshot. This agent gets much more:

• The photo, the name "Trail Runner 2" and the price, $129.
• The size swatches, though nothing on screen says which sizes are in stock: sold-out sizes are only a lighter shade of gray.
• The cookie banner, covering the bottom of the screen, including the "Add to cart" button.

The agent has to deal with the banner first. If its buttons are clearly labelled "Accept" and "Reject", that's one extra step. If the only way out is a small "×" drawn in an image, the agent may click the wrong thing or give up. Either way, it costs a step on every visit where the agent starts with a fresh browser, and many do. Our guide to cookie banners and pop-ups covers how to keep them out of the way.

View 3: the accessibility tree

Many browser agents don't act on pixels alone. They read the page's accessibility tree: the same outline of headings, buttons, links and fields that screen readers use, with a role and a name for each item. It's compact, and it tells the agent exactly what it can press. Here is a simplified version of Northwind's:

banner
  link (no name)
  button (no name)
main
  heading "Trail Runner 2" level 1
  text "$129.00"
  generic "8"
  generic "9"
  generic "10"
  generic "11"
  button "Add to cart"
dialog "We value your privacy"
  button "Accept all"
  button (no name)

Read it the way an agent would:

• The logo link and the cart icon have no names. The agent can't tell which button is the cart. An aria-label or visible text fixes both.
• The sizes aren't controls. They're plain boxes with a click handler, so they show up as "generic" rather than buttons or options. The agent may not realize it can choose a size at all, and nothing tells it which sizes are sold out. Real buttons or radio inputs, with the stock state in their names, solve it. See variant pickers AI agents can use.
• The banner's "Reject" button has no name. It's an icon with no label. An agent that wants to decline cookies on the shopper's behalf can't find the option.

The good news is in there too: one clear h1, a price as text, and an "Add to cart" button that is a real button with a real name. Those are the things that let an agent finish the job.

Same page, three stories

What the agent needs	Raw HTML	Rendered page	Accessibility tree
Product name	Missing	Yes	Yes
Price	Missing	Yes	Yes, as text
Sizes in stock	Missing	Only as shading	Sizes listed, stock missing, not selectable
A way past the banner	Not applicable	Depends on the buttons	"Accept all" only
Add to cart	Missing	Covered by the banner	Present and named

No single view is "the" agent view. A shopper's question might be answered from the raw HTML, and the purchase made by a browser agent working from the accessibility tree. A page has to work in all three.

How to see your own pages this way

1. Raw HTML: open a product page, choose "View page source", and search for the price and the product name. If they're not there, agents that read the HTML don't have them.
2. Rendered page: open the same page in a private window at desktop size. What covers it on arrival is what a browser agent meets first.
3. Accessibility tree: in Chrome's developer tools, the Accessibility pane shows each element's role and name. Look for buttons and links with no name and for clickable things that show up as "generic".

AgentScore does this comparison for you. It fetches your home page and key pages as a browser and as AI assistants, renders them in a real browser, and checks names, labels, banners and the add-to-cart button. Checks such as Content loads without JavaScript, Product pages give price and stock in a form agents can read, Buttons and links have names and Pop-ups and banners can be dismissed by agents map directly onto the problems above. How AgentScore renders your pages explains the details.