Browser agents are starting to expose a website problem that ordinary crawl checks do not catch. A site can load, render, and explain its content while still being hard for an AI agent to use.
Reading a page is a fairly narrow job. Completing a task is larger. If an agent has to compare plans, fill a form, choose a product variant, understand a login requirement, call an API, or move through checkout, the page needs to explain the action path, not only the visible copy.
That is the gap this post is about. Crawl access matters. A clean llms.txt file may help some tools find important pages. Clear brand facts matter too. Those checks still leave a harder question unanswered: can an agent understand what is possible, what is allowed, what is risky, and what happens next?
I think this is the next practical website audit for AI visibility. The goal is not to rebuild a site for imaginary robots. The goal is to remove hidden assumptions from the paths people may soon ask assistants to navigate.
What makes browser agents different from crawlers
A crawler mainly asks whether it can fetch a page and process the content. A browser agent has a different job. It inspects pages, interprets interface elements, and may take steps on behalf of a person.
That shift adds questions a crawler does not need to answer:
- What action does this page support?
- Which fields are required, optional, or conditional?
- What will this button do?
- Is the user logged in, subscribed, blocked, eligible, or missing permission?
- Will the next step create a quote request, start a payment, cancel a plan, export data, or make an irreversible change?
- Where is the source of truth when the visible page only starts the workflow?
A human user can infer some of this from habit, layout, and patience. They click around, recover from mistakes, and ask support when the site is vague. An agent has to turn the page into an action plan. When the plan depends on hidden JavaScript state, vague labels, or side effects that appear only after submission, the agent is guessing.
The agent standards story is still unsettled
The trend is real. The implementation details are fragmented.
Chrome Lighthouse now has experimental Agentic Browsing audits for llms.txt. Chrome also documents agent-focused checks for forms that lack declarative WebMCP metadata and for interactive elements exposed through the accessibility tree. Those are not proof of a settled standard for the whole web. They are useful evidence that browser tooling is beginning to treat agent usability as its own surface.
Anthropic’s Model Context Protocol approaches the problem from the tool side: agents need structured ways to connect with data, tools, and systems. Google’s Agent2Agent announcement approaches it from coordination between agents. Both point toward a more structured agent ecosystem, while leaving normal websites with a practical near-term question: how much of the task path can an outside system understand?
There has also been a viral claim about Google and Microsoft working on a browser-level navigator.modelContext API. I could not verify an official Google, Microsoft, WICG, W3C, or ChromeStatus source for that specific claim. It may be a misunderstanding, an unpublished idea, or simply wrong. The safer conclusion is narrower: agent-readable interfaces are getting attention, and the public evidence does not support treating one rumored browser API as a fact.
Task state is where many sites get vague
Most websites explain pages better than they explain states.
A pricing page may explain the plans while hiding whether the current user can upgrade, downgrade, pause, cancel, add seats, change billing currency, or keep a discount. A product page may explain the item while burying stock status, substitutions, delivery constraints, return rules, or the final price after a bundle choice. A docs page may describe an endpoint while failing to connect that endpoint to the workflow a user is trying to complete.
The higher the consequence, the more the missing state matters. Clicking a filter or opening a product image is easy to recover from. Other actions need more care:
- Submitting a lead form that triggers sales follow-up
- Starting a paid trial with card details attached
- Changing a subscription plan
- Booking an appointment or reserving inventory
- Deleting data, revoking access, or changing permissions
- Buying a product with shipping, tax, and return implications
For those flows, a clickable button is too thin as an interface contract. The site needs clear labels, visible consequences, confirmation steps, recoverable errors, and permission boundaries. A human may tolerate ambiguity. An agent should not be asked to act on it.
Forms are the first obvious failure point
Forms look simple until an agent has to use one.
A field labeled Company may mean legal company name, store name, domain, billing entity, or employer. A disabled submit button may depend on a validation rule that is not named anywhere. A work email requirement may appear only after a personal email fails. A product configurator may change price, delivery date, or eligibility without making the change easy to inspect.
This is where accessibility and agent usability overlap. Labels, names, roles, descriptions, focus order, validation messages, and specific errors help people using assistive technology. They also give agents stronger signals. When a form relies on layout, color, placeholder text, or post-submit surprise, it becomes fragile for both.
The agent-specific layer is the job of the form. Is this a quote request, account deletion request, newsletter signup, checkout step, product configuration, or support ticket? What information is required? What happens after submission? Can the action be undone? Who receives the data?
A surprising amount of the web still answers those questions through vibes: page context, button color, surrounding copy, or what usually happens on sites like this. That felt normal when humans were the only expected users. It is weak ground for automation.
Checkout flows need explicit stopping points
Ecommerce is an obvious test case because the task has a concrete outcome: help the user choose and buy something.
The product page is only one part of that task. An agent may need to understand variants, inventory, bundles, shipping options, delivery windows, return rules, taxes, discount codes, subscription terms, account requirements, and payment methods. If those details sit in popovers, hidden drawers, policy pages, or validation messages that appear after an attempted checkout, the agent can read the page and still fail the task.
Agent-friendly checkout does not mean agent-completed checkout. In many cases, the safer design is to let the agent collect options, compare tradeoffs, fill reversible steps, and stop before payment or commitment. The site should make that boundary visible.
The basics are not exotic:
- Stable product identifiers and canonical product pages
- Variant names that match what users see
- Machine-readable prices that match the visible price
- Inventory and delivery constraints shown before checkout
- Clear return, warranty, cancellation, and subscription terms
- Confirmation before payment, booking, subscription, or irreversible changes
This work helps humans too. A checkout flow that is easier for an agent to reason through is usually easier for a tired buyer on a phone.
Software sites need docs that explain actions
For software companies, the agent-readable path often runs through documentation and APIs instead of marketing pages.
A product page can say the tool has an API. The docs need to show how authentication works, what scopes are required, which endpoints map to common jobs, what errors mean, and which actions should stop for human approval. If the docs only make sense to a developer who already knows the product, a general-purpose agent will struggle to choose the right path.
MCP-like thinking is useful here even for companies that never implement MCP directly. The practical question is whether the site exposes useful actions in a way an outside system can understand: read this data, compare these options, create this draft, submit this request, call this endpoint, stop here for confirmation.
Protocols, manifests, and metadata can help. They do not rescue confusing docs, vague permissions, stale examples, or actions with unclear consequences. The underlying workflow still has to make sense.
A practical agent usability audit
Start with one task rather than the whole site. Pick something a real user might ask an assistant to do: compare plans, find the right product, book a demo, configure a subscription, look up API limits, request a quote, download an invoice, or start a return.
Then walk the task as if an agent had to complete it with minimal guessing.
- Entry point: Can the agent find the right page from search, navigation, internal links, docs, or a site map?
- Purpose: Does the page explain which task it supports?
- Actions: Are actions named clearly, with visible consequences?
- Forms: Are fields labeled, constrained, validated, and described before submission?
- State: Can the user tell whether they are logged in, eligible, blocked, upgraded, downgraded, subscribed, or missing permission?
- Errors: Are failures specific enough to recover from?
- Documentation: Is there a canonical page for rules, limits, permissions, and API behavior?
- Confirmation: Does the flow stop before payment, booking, deletion, or another high-consequence action?
The useful finding is the first place the agent has to guess. That is the repair list.
Avoid optimizing for imaginary agents
The weak version of this topic tells every site owner to rebuild for a future assistant that may never visit. That is a distraction.
The stronger version is smaller and testable. Make important tasks clearer. Improve accessibility. Make forms less ambiguous. Keep docs current. Label actions and consequences. Expose stable product, pricing, policy, and API facts. Add structured data only when it accurately describes visible content. Consider files or metadata when they help an agent find or understand a real path.
Agent behavior will stay fragmented for a while. Some assistants will ignore metadata. Some will rely on search results, browser automation, partnerships, APIs, or user-granted connectors instead of public pages. A site owner cannot control all of that. They can reduce ambiguity in the tasks that matter.
That makes the work worthwhile even before agent traffic becomes obvious in analytics. Better accessibility, clearer forms, better docs, explicit policies, stable product data, and safer confirmation flows all improve the site for people.
What to test next
Pick three tasks on your site that a user might reasonably delegate to an assistant. For each one, write the ideal instruction in plain language.
Find the right plan for a three-person team, explain the tradeoffs, and stop before purchase.
Then test whether the public website gives enough information to complete that instruction safely. Do not start by asking whether the site has the newest agent file. Start by asking where the agent would get confused, where a human should confirm, and which source of truth the agent should trust.
SurfacedBy is useful after that because AI visibility work starts with seeing what assistants say, cite, compare, and recommend. The website work itself is more basic: make the paths clear enough that humans and agents can understand what is possible, what is allowed, and what happens next.
The web does not need to become a set of robot-only instruction files. It needs fewer hidden assumptions. If browser agents become part of how people research, compare, and act online, the sites that explain their tasks clearly will be easier to trust.
