A restaurant booking page used to have one job. A person lands, scans for a time, taps a button, gets a confirmation. Now the same page might be read by an assistant acting on someone’s calendar, which needs to know which slots are free, whether the deposit is refundable, and what happens if the party drops to three. The human never sees your carefully art-directed hero image. The task still has to complete.
That gap is where most of the current work on AI agent websites is happening, and it’s messier than the launch posts suggest.
Two products wearing the same label
People use “AI agent websites” for at least two different things. The first is a site built to be used by autonomous software: booking engines, quote comparison pages, claims portals, B2B ordering systems that an assistant can drive end to end. The second is a site that hosts or sells agents, where you assemble a workflow, wire up some tools, and deploy it.
The constraints are nearly opposite. One is about being legible to a machine you don’t control and can’t instruct. The other is about handing a machine enough tools and guardrails to do your work without setting the building on fire. If you’re reading about this because your analytics suddenly show traffic that never loads a stylesheet, you’re dealing with the first kind.
It’s also worth being precise about vocabulary, since “agent” gets attached to everything from a scheduled cron job to a multi-step research system. A useful breakdown of what “agentic” actually adds to the word AI covers the distinction properly: autonomy over steps, not just a language model behind a text box.
The click stops being the unit of work
Web analytics were built around sessions and pageviews, and both assumptions get shaky fast. An agent might hit four endpoints in under a second, skip your CSS entirely, and complete a task that would have taken a human eleven clicks. Your funnel report logs a bounce. The customer got exactly what they came for.
Consider a procurement assistant checking whether a supplier is approved. In a browser, that’s a login, a search, a filter, and a PDF. Through a documented endpoint it’s one request and a JSON response. Same business outcome, wildly different telemetry. Teams that don’t separate agent traffic from human traffic end up “fixing” a conversion problem that doesn’t exist while missing the real one, which is that their agent-facing flow fails at step three.
What makes a page readable to an agent
Markup that survives a redesign
Class names generated by a build tool tell a machine nothing. Labels do. Native form elements do. A <button> that’s actually a button, an input with a real name and an associated <label>, and IDs that don’t rotate every sprint will get you further than any integration project. Agents and the accessibility tree read the same signals, so this work pays twice.
Data where a machine can find it
Schema.org markup for products, prices, availability and opening hours is a decade old and still skipped. Add an OpenAPI or similar spec for your transactional endpoints, publish a sitemap with honest lastmod values, and provide a plain-text index of what’s machine-usable. None of it is glamorous. All of it removes guesswork.
Permissions written down, not implied
robots.txt tells a crawler it may read. It says nothing about whether an agent may add an item to a cart, hold a reservation, or submit a claim. Terms need to name allowed actions, rate limits, and who to contact when something misbehaves. That access layer is turning into its own discipline, and the friction is real; getting websites to let agents in is now as much a policy problem as a technical one.
Errors that say what to fix
A 400 with the body “Invalid request” is a dead end. Return the field name, the expected format, and whether a retry could plausibly succeed. Agents retry blindly when they can’t tell what broke, which turns one bad request into forty and gets you flagged by your own WAF.
Where real flows fall over
The failures cluster in predictable places: a session that expires fifteen minutes into a checkout, a one-time code sent to a phone the agent can’t reach, a date picker that only responds to a specific click sequence, a modal that never closes cleanly. Demos skip these because the demo path is short and the demo data is clean. The reasons agents break down in production tend to be boring, repeatable, and fixable once someone watches a real run instead of a recorded one.
Designing one interface for two very different readers
You don’t get to build a separate site for software. The page has to work for a distracted human on a phone and for a process that reads structure instead of pixels. Design systems are quietly becoming the bridge: documented component states, named tokens, and explicit flow definitions give both audiences the same map. That’s roughly the direction platform tooling is heading, as shown by Figma’s features for defining how agents work on its platform. When a designer names the states of a form, they’re also documenting them for whatever drives it.
If your site is also an agent builder
Different problem entirely. Here the question isn’t legibility, it’s durability: does the thing keep working when your CRM times out, the auth token rotates, and a customer uploads a 40MB scan at 4:55pm on a Friday. Platforms that look identical in a demo diverge sharply under that load, and the ones that survive your actual systems are rarely the ones with the nicest marketing site. Ask for a sandbox with your data shape, not theirs.
What to fix first
Skip the grand roadmap. Start narrow.
- Pick your three highest-value flows: booking, quote, claim, reorder. Whatever money moves through.
- Walk each one as a machine would. Disable images, ignore JavaScript-rendered styling, and see what’s left.
- Add labels, stable IDs and a proper accessible name to every interactive element on those flows.
- Write down rate limits and allowed actions, and publish them somewhere a developer will actually look.
- Fix your error responses so a failed request explains itself.
- Split agent traffic from human traffic in analytics before you draw any conclusions about performance.
The metrics that mean something now
Pageviews per session will fall. That’s fine, and possibly good. Track task completion rate on the agent-facing flows, the step where failures concentrate, containment rate for support requests, and how often an agent hands off to a human. One retailer we spoke with saw mediated sessions complete at 2.4x the rate of browser sessions but escalate twice as often, because a coupon field quietly rejected valid codes. The escalation number was the useful one.
The part nobody puts in the launch post
Making a site work for agents is mostly maintenance: durable URLs, IDs that don’t churn, limits that are documented and enforced, and a monitored inbox for the people building against you. The teams doing it well treat agent access the way they treat their public API, with versioning and a changelog and someone on the hook when it breaks. Pick one flow this month. Watch a real agent attempt it, log the three places it stumbled, and fix those. The second attempt will be shorter than the first, and by the fourth you’ll have a site that finishes work instead of just presenting it.