Two visually identical pages, ten files to download, and Claude in Chrome as the test subject. I assumed JavaScript rendering, onclick handlers, and an iframe would stop the agent cold. None of them did — and that failure turned out to be the most useful result I could have gotten.
The plan was simple. Build two pages that look the same to a human. Make one agent-ready and break the other one on purpose. Send an AI agent to both. Watch it sail through the good page and get stuck on the bad one. Record it, show clients, end of theory — beginning of proof.
It didn't work. And that is the interesting part.
Why I wanted this in the first place
Agent-readiness has a communication problem: everyone nods, nobody pictures it. You say "semantic HTML," "machine-readable structure," "content agents can parse," and you watch the polite incomprehension settle over the room. The words land in a vacuum because there's no image to attach them to.
The image showed up the moment I started running an AI browser agent live in front of people. The agent opens a page, gets a task, and either does it or doesn't. Jaws drop. No slides, no explanation — one screen. So I needed a scenario worth recording: two pages, identical to the eye, where the agent breezes through one and trips on the other.
The setup
I picked the most ordinary business I could think of — a beauty salon — specifically so there'd be zero industry jargon in the way.
The task for the agent: "Download every post-treatment care instruction."
The files: ten PDFs, one per treatment — brow lamination, henna, lash extensions, gel manicure, pedicure, waxing, peeling, mesotherapy, HIFU/RF lifting, brow styling. Why ten and not one? Because one file isn't a task. Ten is the kind of thing a human does, annoyed, over several minutes. An agent — if the page lets it — should finish in seconds.
The good page: semantic HTML. Descriptive links like <a href="care/brow-lamination.pdf" download aria-label="Download post-care instructions for brow lamination">, files named for what they contain.
The bad page: visually identical. But the download list was rendered by JavaScript (the raw HTML said only "Loading…"), the buttons were <button onclick="downloadFile(3)"> instead of links, and the files were named document_01.pdfthrough document_10.pdf.
That, I figured, was a solid trap.
Round one: a 503 on both pages
First run returned a 503 on both pages. Cause: the host blocks directories without an index file, and the PDFs were sitting in subfolders the server refused to serve.
Fix: I embedded all ten PDFs as base64 directly in the HTML. Two standalone files, ~300KB each, zero external dependencies. Clean slate.
Round two: the trap caught nothing
Pages work. The agent visits both. It downloads all ten files. On both pages. In the same amount of time.
The JavaScript rendering and the onclick handlers did not slow Claude in Chrome down at all.
Here's why. The agent sees the page after JavaScript has run — the list was already rendered by the time it looked. It clicked the onclick buttons without trouble. And the meaningless filenames (document_01.pdf) were no obstacle, because the agent read the visible labels on the cards — "Brow lamination," "Henna," and so on — and simply knew which button was which.
In other words: my bad page was too good. The thing I built to confuse the agent still told the agent everything it needed to know.
Round three: the iframe
Next hypothesis: hide the download section inside an <iframe srcdoc="..."> — a separate browsing context the agent shouldn't be able to reach through the main page's DOM.
Result: it handled that too. Claude in Chrome entered the iframe, saw the contents, clicked the buttons.
At this point the experiment had comprehensively failed to prove what I set out to prove. Which is when it started telling me something true.
What this actually means
A few things worth keeping.
Claude in Chrome is better than I assumed. JavaScript rendering, onclick, nonsense filenames, an iframe — none of them stopped it, as long as the visible text labels were readable. The agent doesn't read your code. It reads the rendered page the way a human sees it, and acts on what it sees.
Traps that work on crawlers don't work on agents. Googlebot doesn't execute JavaScript, or does it on a delay. Claude in Chrome executes the JavaScript, sees the result, and acts on the result. It's a different class of tool, and your old mental model of "what confuses a bot" doesn't transfer.
The real barrier for an agent is missing context, not missing access. If the cards on the bad page had said "Product 1," "Product 2" instead of the treatment names, the agent wouldn't have known what it was downloading. If the page hadn't signaled there were files to download at all, the agent wouldn't have gone looking. Semantics isn't just valid HTML — it's whether the page communicates what is here and why in the first place.
A good experiment is one that fails to confirm your hypothesis. I assumed the iframe and the onclick handlers would be enough. They weren't. That's useful information, and it's honest. I don't know anyone who has shown this live and then told you what actually happened, rather than what they expected to happen.
What would actually stop an agent
Based on this experiment and the follow-up tests, three things genuinely cause problems:
No context for the action. The page doesn't say it has files to download. The links exist, but they're buried behind unlabeled navigation, behind tabs with no description, behind modals opened by a single "more" button. The agent can't act on what the page never announces.
A form gate before the content. "Enter your name and appointment date so we can send you the right instructions" — now the agent has to understand form state, fill it, and wait for a response. That's a different order of difficulty than clicking a button.
Content that exists only as images or text-free PDFs. The agent sees a picture, not text. Scanned documents with no OCR layer are black boxes to it — though, unnervingly, it will sometimes get around even this by screenshotting the page it's operating on and reading that.
The one conclusion that matters
Agent-readiness is not about blocking bad agents from your data. It's about letting a good agent — one acting on behalf of your customer — operate your site smoothly and without errors, wherever you want it to be able to act.
If your site is built so that an agent gets lost on it, you lose the customers that agent represents. You won't see it in your analytics. You'll see it only when someone shows you, live, how an agent handles — or fails to handle — what you built.
That's what this experiment shows. Even though it didn't fail nearly as spectacularly as I'd hoped.
This is a field note from an ongoing series of agent experiments — empirical tests of what AI agents actually do on real pages, with the results reported straight, including the ones that don't go to plan. The pattern data and agentic-web terminology behind this work come from the Polish-language research engine at cyberflux.pl and webflux.pl.