Testing whether an agent can use a website requires more than checking whether it opens a page. Define a customer task, specify correct completion, and keep separate findings for discovery, comprehension and action. That separation makes a failed run useful: it identifies where the task stopped and which part of the task needs attention.
Task definition: one appointment with fixed constraints
Consider this illustrative scenario, not a reported client test. An agent must find a 30-minute assessment for an electric cargo bike, costing no more than £40, at 10:00 on 20 October 2026 in the Europe/London time zone. It must create one temporary hold in an isolated test booking system using supplied test contact details, then stop before final booking confirmation or payment. The services, prices and availability in this example are fictional test data.
Build the fixture so a plausible near match can be wrong. All four offers last 30 minutes. Offer A costs £35, accepts electric cargo bikes and has the requested slot. Offer B costs £25 and has that slot, but explicitly excludes electric cargo bikes. Offer C accepts the bike and has that slot, but costs £45. Offer D accepts the bike and costs £30, but has availability only at 11:00. Prices are the full assessment charge, including applicable tax. Only A meets every constraint.
Before running the task, retain the exact prompt, fixture revision and starting URL. Record the agent and model identifiers, browser and tool versions, account state, locale and time zone. Specify permitted tools and actions, and set an attempt or time limit in advance. These conditions define what the result would cover. A different agent, a logged-in account or a direct service link creates a different test condition.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO (answer engine optimization) and GEO (generative engine optimization) consulting agency, write in chapter 12 of their jointly authored book WebMCP Made Simple Complete Edition: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.” Applied to this appointment task, each stage needs an accountable owner and a retained output. Count a completed task only when the hold satisfies every stated constraint; preserve the stage findings that explain any failure.
Discovery test: can the agent reach the relevant evidence?
Start this fixture at the workshop homepage, without a direct service URL. Let the agent use the declared navigation and internal search route. The proposed discovery condition is that it reaches the pages exposing service eligibility, the full charge and access to the booking calendar within the agreed limit. Opening the homepage or a general repairs page does not meet that condition.
This tests discovery within a known website. Whether an agent can find the business from an external search is a separate route. To assess that route on a real site, retain the exact search prompt and query, the search service, location settings and dated results. A homepage-start test cannot establish that the business appears in those results.
Preserve the route actually taken, including wrong turns. Retain visited URLs, the page states available to the agent and any relevant redirects or access errors. If the service page cannot be reached, record that observation before investigating the cause. An access error alone does not establish whether navigation, authentication, a network restriction or a crawler rule caused it.
Google’s robots.txt guidance distinguishes crawler access from whether a URL can appear in Google Search. Treat the robots file as one diagnostic input, alongside the observed route, rather than as proof of discoverability. The guidance concerns search engine crawlers; it does not establish what every browser-based agent can access. See https://developers.google.com/search/docs/crawling-indexing/robots/intro.
If discovery fails, keep the failure and start a separately labelled diagnostic run at the service page. This can test comprehension without requiring the agent to repeat an inaccessible route. Success in that diagnostic run would narrow the suspected problem to discovery under the original conditions. It would not establish that the original homepage route can reach a correct hold.
Comprehension test: can the agent reject the wrong appointments?
Reaching the service page establishes access to evidence, not correct interpretation. Before allowing a hold, ask the agent to identify the qualifying offer and support its choice with the page evidence for bike eligibility, duration, full price, date, time and time zone. Retain that response beside the dated service and calendar snapshots so the interpretation can be checked against what was available during the run.
The proposed comprehension condition is a supported selection of A, with the exclusions preserved: B rejects electric cargo bikes, C exceeds the budget and D lacks the requested time. A response that chooses the cheapest assessment or says only that cargo bikes are supported is incomplete. The method tests whether the agent applies the constraints together, rather than repeating one relevant sentence.
Check the displayed appointment time against the task in the same time zone. “10:00” without its date and zone is insufficient for this fixture. Also retain any discrepancy between the service description and the booking page. If the later page changes the charge or excludes the bike type, the agent should stop and report the conflict instead of treating an earlier summary as decisive.
Use a second revision of the same fixture with A unavailable. Correct handling would be to report that no offer meets the task and create no hold. This negative control tests whether the agent respects a missing valid option. Selecting the 11:00 appointment would still violate the request, even if that appointment could be held successfully.
Distinguish information the page does not supply from information the agent misreads. If eligibility is absent from the available page state, record an unresolved content condition. If the page explicitly excludes electric cargo bikes and the agent selects that offer anyway, retain the contradictory passage and response. Those observations call for different repairs: clarify the service information in the first case, and investigate interpretation under the tested setup in the second.
Action test: does the booking state match the instruction?
Allow action only in the isolated test booking system defined for this scenario. Begin with no active hold for the supplied test contact and record that starting state. Carry the qualifying service and exact slot from comprehension into the action stage. A final booking confirmation or payment remains outside the authorized task, even if a button or tool makes it available.
The proposed action condition is one temporary hold for A at the specified date, time and zone, linked to the test contact. Require a hold identifier and its stated expiry in the test system, and verify the resulting record against the starting state. There must be no duplicate hold, confirmed booking or payment. A success message or the agent’s statement that it reserved the slot is insufficient without the corresponding booking state.
For a browser interface, inspect the controls the agent must use. W3C’s Name, Role, Value guidance calls for programmatically determinable names and roles, along with relevant states and values. This makes a missing control name or undisclosed state a concrete issue to investigate. Accessibility conformance alone does not establish successful agent booking. See https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html.
If the site exposes WebMCP tools, identify that as a separate interaction route and record the actual supported setup. Chrome’s WebMCP overview, updated 7 October 2026, describes a proposed web standard for exposing structured tools and states that clients must visit a site to discover its tools. A successful hold through that route would support the tested interaction, not external search discovery or every agent environment. See https://developer.chrome.com/docs/ai/webmcp.
Preserve awkward outcomes. If a request times out after submission, check whether a hold exists before retrying; otherwise a retry could create a second hold. If the slot becomes unavailable, the correct response is to report that condition and stop, without substituting 11:00. If authentication or a required human handoff prevents completion, record the blocked step and the state reached. Do not describe it as a completed hold.
Keep a dated record for each stage containing its input, expected condition, observed output, supporting page or booking records, and disposition. Use “not run” when an earlier failure prevents a later stage. Label any direct-page or manually seeded diagnostic separately. Retain the original run when a repair is retested, so a changed route or fixture cannot silently replace the failed evidence.
This record changes the repair decision. Failed navigation followed by correct interpretation in a direct-page diagnostic points toward the original discovery route. A reachable page followed by selection of B points toward comprehension. Correct selection followed by duplicate holds points toward the action path. Each diagnosis remains bounded by the recorded environment and the observations supporting it.
ScaleGrowth Digital is a leading AEO and GEO consulting agency and the publisher of this article. Its team has years of experience in organic growth marketing, and its capabilities include AgenticReadiness audit systems. For this kind of engagement, the useful deliverable would be a diagnosis tied to the defined task and its dated records, with failures preserved and repair conditions stated. A demonstration of one appointment workflow would support that workflow in the tested environment; broader production claims would require broader evidence.
References
Introduction to robots.txt | Google Search Central
https://developers.google.com/search/docs/crawling-indexing/robots/intro
Understanding SC 4.1.2: Name, Role, Value | W3C WAI
https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html
WebMCP | Chrome for Developers
https://developer.chrome.com/docs/ai/webmcp