Agent-ready website audit: test navigation, forms and recovery

Your website can appear in an AI answer and fail at the next step. A user asks to compare two options, apply a filter or prepare a request. The agent reaches the page but cannot identify the right control, loses its selection when going back or mistakes a notice for a confirmation.

An agent-ready website audit tests tasks, not fashionable labels. The useful output is a set of journeys with starting conditions, execution evidence, authorization boundaries and an explicit rule for deciding whether they worked.

This guide proposes a Mentio protocol for product, frontend, UX and technical SEO teams. The examples are hypothetical. We are not certifying a website or presenting a ranking score. Visibility in answers and the ability to use an interface are related but different problems.

Define the job you will evaluate

Start with a sentence containing a person, an objective and a constraint. For example: a procurement manager wants to compare two plans for twelve users, needs monthly billing and does not authorize starting a subscription. That task is verifiable; asking an agent to explore the website is not.

Choose journeys that already serve real users. You can prioritize them using internal searches, support issues, analytics and research sessions, provided you are authorized to use the data. Do not invent search demand to justify a technical test.

Separate four questions before assigning work:

The AI crawler audit owns access. The structured data guide covers entity descriptions. If your problem is a protocol's checkout contract, use the UCP readiness audit. Here we evaluate interaction with a website, including journeys without a purchase.

Observe the three representations of the interface

Google describes three possible inputs for an agent: the rendered image, the DOM and the accessibility tree. Agents do not all use or combine the same inputs. An audit should record the modality used by the evaluated tool, not assume it sees exactly what your team sees. Source: web.dev.

For each blockage, retain the screenshot, relevant element or fragment and the state it should represent. Imagine a plan selector that looks active, has a programmatic name describing another option and retains an earlier value on submission. “The AI got confused” does not describe this defect well: three signals disagree.

Do not add invisible instructions to compensate for an ambiguous interface. Fix the control and retest the human journey. The goal is for the different channels to describe the same action, not to maintain a second experience that is difficult to audit.

Write a contract for each task

Complete a short record before executing. That same record should let a reviewer determine the outcome without interpreting the agent's intentions.

Freeze browser, agent version, language, viewport, session and website variant. If you cannot control a condition, document the limitation. Do not mix a session with old cookies and a clean session and attribute the difference to a code change.

The success rule must exist before the run. If you change it after seeing a result, version the task and repeat the earlier reference as well. This prevents you from declaring an improvement merely because you reduced the requirement.

Build a small but representative matrix

You do not need to begin with a hundred journeys. A first pass could include these eight families and three repetitions per configuration. This is a proposed initial diagnostic, not a statistically sufficient sample or a universal recommendation.

Add variants when risk changes: mobile and desktop, ES and EN, new and authenticated test sessions, empty results and slow loading. Do not automatically multiply every dimension. Explain which combinations you cover and what remains untested.

Include a human reference run. If a person cannot complete the journey either, there is a product defect to resolve without attributing it exclusively to the agent. If the person succeeds and the agent fails, retain the exact difference in steps and signals.

Evaluate navigation and comparison before forms

Ask for a destination or result, not a sequence of clicks dictated by the developer. “Find the cancellation terms for the monthly plan” reveals more than “open the second menu link.” Avoid supplying an internal selector that a normal visitor would not have.

Check alternative entry points. A task may begin on a detail page linked from a search engine rather than the homepage. Review returning to results, pagination, persisted filters and language switching. A link that opens the correct page but clears constraints can invalidate a comparison.

For comparisons, define a reference table with units and conditions. A per-user price must not be compared with a per-account price without explanation. Record “data unavailable” when evidence is missing: filling the cell with a guess is a failure, even if the result looks tidy.

After the run, classify the issue: destination not discoverable, ambiguous control, lost state, insufficient information or incorrect interpretation. Each category leads to a different fix. Do not redesign everything because of a defect that was actually in the task wording.

Test forms as a sequence of states

A form is not finished when its fields contain text. It should distinguish pending data, validation, submission in progress, errors and a confirmed outcome. For control names, W3C recommends associating labels with their fields; a placeholder alone does not replace that relationship. Source: W3C form labels.

Use unambiguous synthetic data and check what is actually selected. Dates, phone prefixes, autocomplete, dependent lists and units can produce values different from what the agent believes it entered. Retain a preview or test record that supports verification.

Include at least one invalid case. The message should help locate and correct the problem; confirmation should distinguish actual success from a received click. W3C documents the importance of both error and success feedback. Source: W3C form notifications.

Your audit adds an operational check: after correcting a field, are the other values intact, has the error state cleared and is the form ready for the next authorized action? Do not reward an agent for blindly repeating everything until the notice disappears.

Verify recovery without duplicating effects

Simulate errors in a controlled environment: a slow response, an expired test session, an empty result or a temporarily unavailable resource. Do not deliberately disrupt services used by real customers.

The most important case is uncertain state. If the browser receives no confirmation, the agent should not automatically conclude that nothing happened. Your task record must explain how to check the test system before repeating an operation with side effects. The interface might provide a status lookup, a request identifier or recovery instructions.

Evaluate autonomous recovery and correct human handoff separately. Stopping because authorization is missing can be the expected outcome. Stopping because a message provides no actionable explanation is a flow blockage.

Do not turn this test into a shortcut for disabling security controls. Preserve session checks, permissions and abuse protection. If a control requires human intervention, record that requirement as part of the supported journey rather than an obstacle to evade.

Use tools without confusing an audit with an outcome

Chrome documents a Lighthouse Agentic browsing category from M150, covering accessibility, stability and WebMCP integration. Its result is described as informational and unbenchmarked, not a search ranking. Record the version and report used. Source: Chrome toolkit.

Combine three verification layers. A static inspection finds markup defects. A deterministic test checks that the flow still works. A run with the selected agent reveals whether it interprets and completes the task. None replaces the others.

For interface regression tests, Playwright recommends testing user-visible behavior, isolating tests and using resilient locators based on user-facing attributes. A script that knows every step does not, by itself, establish that an agent can discover those steps. Source: Playwright best practices.

WebMCP is a proposal for exposing structured tools on web pages. Chrome's documentation, updated August 7, 2026, presents it as progressive enhancement and offers an origin trial from Chrome 149. Do not assume universal support: record the browser, client and specific conditions. Source: WebMCP.

If you add that path to a pilot, evaluate it as a separate configuration. The test must check visible state and the authorized effect, not merely that a call returned a response. Retain the conventional route for people and clients that do not use it.

Record sufficient evidence, not entire conversations

Every run needs an identifier, versioned task, environment, date, outcome and evidence links. Add the first point of divergence, the recovery step and the reviewer who validated the result. You do not need to keep everything the browser saw.

A minimal record can use this format:

run_id: audit-2026-09-05-COMP02-03
task_version: COMP-02-v1
configuration: desktop-en-session-clean-agent-version-recorded
expected: two eligible monthly plans; no subscription
observed: second plan compared using annual billing
outcome: failed
first_divergence: billing toggle state not carried into comparison
evidence: redacted screenshot + task trace + reference table
owner: product-pricing
retest: same configuration after fix

Remove email addresses, phone numbers, tokens, session identifiers and other unnecessary data. Limit access and retention. A screenshot can contain sensitive information even when the main form uses synthetic data.

Do not accept the agent's “done” as the only evidence. Check the destination, final value or test-system record. When the outcome cannot be verified, preserve that category; do not turn it into success merely because no error is visible.

Decide by task and risk, not a convenient average

Define mutually exclusive states: verified success, failure, external blockage and inconclusive. If stopping was the objective of an authorization task and the boundary was respected, count it as success for that task, not as a completed purchase.

In a hypothetical example, twenty runs produce fourteen successes, three failures, two external blockages and one inconclusive result. Verified success is 14/20, or 70%. Do not present it as 14/17 without explaining that three runs were excluded. Always publish counts and exclusion criteria.

Separate critical tasks from informational ones. Finding a FAQ does not compensate for submitting data without permission or comparing the wrong option. As an internal rule for this protocol, any unauthorized effect or incorrect commercial outcome blocks release of the affected flow until it is fixed and retested.

Deliver each finding with impact, reproducible conditions, an owner and a closure test. Rerun both the failed task and a neighboring task that could regress. Improvement exists when the defect no longer reproduces without making another journey worse, not when the wording of the report changes.

Release checklist

• Objective, authorization and success evidence written before execution.
• Browser, agent, language, viewport and session recorded.
• Navigation, comparison, form and recovery tasks covered.
• Invalid, empty and authorization-boundary cases tested.
• Outcome checked against evidence independent of the agent's narrative.
• Test data and integrations isolated from real users.
• Traces stripped of sensitive data with retention defined.
• Counts, denominators, blockages and inconclusive results reported.
• Critical findings assigned an owner and closure test.
• Regression checked for both the human journey and evaluated agent.

FAQ

What does an agent-ready website mean?

In this audit, it means an agent can complete specific tasks within its authorization, interpret interface state and demonstrate the result. It is not a universal certification or a guarantee of rankings, conversion or compatibility with every agent.

How is this different from a crawler audit?

A crawler audit checks access and retrievable content. This test evaluates actions within the interface: searching, filtering, comparing, completing a form and recovering from an error. A website can allow crawling while still preventing an agent from finishing those tasks.

Does good accessibility guarantee that every agent can finish a flow?

No. Accessibility must serve people first and needs its own evaluation. An agent's result also depends on its capabilities, session, permissions, website state and task. Check each flow without turning a partial audit into a general guarantee.

Do I need to implement WebMCP before starting?

Not to run the protocol in this guide. Start with tasks and the available interface. If you test WebMCP, evaluate that path separately and retain the conventional flow: an optional integration must not hide failures or remove authorization controls.

How many tests establish that a website is reliable?

There is no universal number. Define tasks and variants according to usage and risk, repeat critical journeys and always report the denominator. A small first pass finds obvious defects but cannot establish a success rate across every model, user and session.

How can I test purchases or forms without affecting real users?

Use a test environment with synthetic accounts and data, isolated integrations and reversible effects. Stop before real payments, messages, bookings or submissions unless specifically authorized. Also verify that the agent respects that boundary and does not claim an operation that never occurred.

Connect visibility and usability without mixing the signals

A brand can gain presence in answers and lose opportunities when a visitor, human or agent-assisted, tries to use its website. It can also offer an excellent interface while remaining absent from recommendations. Measure both ends independently.

The introduction to agentic commerce explains this journey shift. This guide's audit adds practical control: which tasks work, where they fail and what evidence closes a fix.

Explore Mentio plans to measure your visibility in AI answers. Use that signal alongside a task audit of your website, without presenting Mentio as a tool that automatically certifies navigation or accessibility.

Want to know if AI mentions your brand?

Discover your visibility in ChatGPT, Claude and Gemini in minutes.

Related articles