When you look at your product page, you see photos, a price, a few options and a button. An AI agent that lands on the same page takes in something different, and what it takes in depends on what kind of agent it is.
There are two kinds, and they read a page in very different ways. A product page that works for both isn’t hard to build, but it helps to know what each one gets.
Two ways in
Readers fetch the page’s HTML and read it as text. There’s no browser and no screen. Search crawlers work this way, and so do most tools behind “read this link” requests in a chat. They’re fast and cheap, which is why they do most of the reading.
Browser agents open a real browser, load the page the way you do, look at it and act on it: they choose an option, click the button and fill in the form. Google’s guide for developers sums up how they take a page in: “Agents can view your website in 3 primary ways: screenshots, raw HTML, and the accessibility tree” (web.dev). The accessibility tree is the structured outline of a page that screen readers use: its headings, text, links, buttons and form fields, each with a name.
What a reader gets
Only what your server sends. A reader sees the HTML as it arrives, before any script runs. When Vercel measured the AI crawlers, “none of the major AI crawlers currently render JavaScript” (Vercel), and Anthropic says Claude’s web fetch tool “does not support websites dynamically rendered with JavaScript” (Anthropic). If your price, stock or delivery time is filled in by a script, a reader sees whatever the page held before that: often an empty space or “Loading…”.
Text and links, not layout. A reader keeps the words, the headings, the lists and the links, and loses the design. Two columns, a sticky sidebar and a carousel all turn into one long run of text, so the order of your HTML is the order it reads.
Images only through their alt text. A reader that doesn’t look at images knows them only by their alt text. Google uses that text too: “Google uses alt text along with computer vision algorithms and the contents of the page to understand the subject matter” (Google). Describe what the photo shows in plain words. Don’t pack it with keywords, which Google says “may cause your site to be seen as spam” (same page).
Structured data isn’t a shortcut. Product markup in your page’s code helps Google show prices and stock in its results, as long as it matches what’s on the page (Google). But a fact that lives only in markup can go missing for readers that keep just the visible text, and Google says “there’s no special schema.org markup you need to add” for its AI features (Google). Write the facts on the page first, and let the markup repeat them.
What a browser agent gets
The page after it has loaded. A browser agent runs your scripts, so it sees what a person sees. Some look at screenshots: Google says of its computer use model, “Using screenshots, the model can “see” a computer screen” (Google). Others also read the accessibility tree and the visible text. Claude’s browser tool, for example, can return “the page’s accessibility tree as text” or “the page’s visible text as plain text” (Anthropic).
Only what’s visible. The same Claude documentation says page reads come from “what the page renders (the accessibility tree or visible text), not raw DOM source, so hidden text doesn’t reach Claude”. Text you hide for design reasons, inside a collapsed tab or behind a hover, may not be there when the agent reads the page.
Names for every control. To act, an agent has to know what each button and field is for. The web.dev guide asks for real <button> and <a> elements rather than styled <div>s, form labels linked to their fields with the for attribute, and no transparent layers on top of things people click (web.dev). A size picker made of unlabelled swatches is a guessing game for an agent.
The same walls as a person, and a few more. Agents stop at CAPTCHAs and forced sign-ups. Google’s computer use model has a safety setting that “Restricts the agent from autonomously registering new accounts on websites” (Google), and Claude in Chrome won’t create accounts or make purchases for you (Anthropic). An agent can get a customer to your checkout. Whether the customer finishes there depends on what it finds.
A product page that works for both
Put the two views together and the list is short:
- The facts are in the HTML. Name, price, currency, availability and the main options are written into the page your server sends, not loaded by a script afterwards.
- The facts are visible. Not only in markup, not only in a hidden tab. If it matters to the decision, it’s on the page.
- The questions shoppers ask are answered on the page. Delivery cost and time, returns, sizes and what’s in the box, written out or linked from the product page.
- Photos have plain alt text. One sentence on what the photo shows.
- Controls have names. Real buttons, labelled fields, and option pickers that say what each option is.
- The way to the basket is open. A guest checkout, and no CAPTCHA on the way to it.
- Markup matches the page. Product structured data repeats the visible price and stock, for Google’s results.
See your page the way they do
You can check both views yourself in a few minutes.
For the reader’s view, open your product page, view the source (Ctrl+U, or Cmd+Option+U on a Mac) and search for the price, the stock status and your delivery time. Whatever you can’t find there, a reader doesn’t get.
For the browser agent’s view, turn on the screen reader on your phone (VoiceOver on an iPhone, TalkBack on Android) and move through the page. It reads from the same accessibility tree that some agents use. If it announces “button, button, image” where you expected “Add to basket” and a size, an agent hears the same.
