Agent-Ready Website Testing: Measure Task Success

What to build—and what each layer does

Choose the layer that solves the observed problem. llms.txt proposal and format describes the file convention; OpenAPI specification describes HTTP API contracts; Model Context Protocol architecture explains MCP’s client/server architecture. These are different responsibilities.

Build an outcome tree you can actually use

Separate the customer result, the behaviors that support it and the technical conditions underneath. For example: correct onboarding choice; accurate explanation of prerequisites; accessible setup instructions. Measure the result and inspect the supporting conditions when it fails. Avoid substituting the easiest technical count for the outcome you care about.

Worked example: the wrong setup path

Illustrative First Value Workspace has different onboarding paths for individuals and teams. An assistant directs both to team setup. The test team records the failure, clarifies eligibility and labels the links explicitly. The retest includes an individual, a team and an ambiguous request. A correct response to the ambiguous request asks for missing context. Guessing quickly is not a successful completion.

Use guardrails alongside the primary measure

Track incorrect commitments, private-data exposure, excessive retries and misleading confirmation states. Count all attempted tasks, including failures. Keep agent model, tool access, prompts and source version stable where possible. Repeat the test after changes; report the sample and limitations. A small before-and-after result is evidence for the next decision, not proof that the intervention caused revenue growth.

The six-step implementation

1. Define customer progress. Name the useful result.
2. Identify the obstacle. Observe a specific failure.
3. Choose the intervention. Change the smallest cause.
4. Set outcome and guardrails. Count success and harm.
5. Run comparable attempts. Keep evidence and failures.
6. Decide from the result. Expand only when warranted.

A short llms.txt you can adapt

This is an illustrative template. Replace every example.com URL with an existing public page on your own domain. Check the content, not just the link. If your site has no public API, leave API instructions out. Do not publish placeholder endpoints, private URLs, access tokens or customer information.

# First Value Workspace

> Find the correct onboarding path for a specific customer and explain the first useful result without creating an account.

## Useful pages
- [Main information](https://example.com/getting-started/): The current offering and relevant details.
- [Conditions and process](https://example.com/plans/): Eligibility, limitations and how the process works.
- [Next step](https://example.com/support/): The official route for a person to continue.

## Boundaries
This example does not support automated purchases or bookings.
Use the linked pages for current facts; ask when information is missing.

Serve the file at your site root when your hosting setup supports it. In a typical static build, that means placing it in the directory copied to the public root. Verify the deployed URL: a local file alone is not a published file. If your platform already generates one, inspect and maintain that version instead of creating conflicting instructions.

If you need an API, start with a read

The following is a proposed contract, not an endpoint installed on this site. Choose fields that answer the task, document their types and meaning, and return only information you intend to make public. Include a source URL and an update signal where useful. A checked date records a review; it does not guarantee the underlying data is current.

GET https://example.com/api/v1/services
Accept: application/json

{
  "example": true,
  "checked_at": "2026-11-11",
  "items": [{
    "id": "intro",
    "name": "Introductory service",
    "pricing_basis": "Request a current quote",
    "source_url": "https://example.com/services/",
    "available_actions": ["read_details"]
  }]
}

Define no-result and error behavior as carefully as success. Keep private data behind proper access controls. For future actions that change records or spend money, design authentication, authorization, explicit confirmation and duplicate-action protection separately. OWASP API Security Project provides a useful security review starting point.

A better audit prompt

Use an assistant with browsing or request capabilities. If it cannot access the site, it should report the limitation; a fluent response is not proof of inspection.

Review this public website: [URL]. Task: Find the correct onboarding path for a specific customer and explain the first useful result without creating an account.

Use browsing or request tools if available; if unavailable, say what you cannot verify. Inspect the relevant public pages and /llms.txt. Record the URLs you actually fetched and the facts you found. Do not infer success from a 200 response alone. Separate observed facts, missing information and suggested changes. Do not sign in, submit forms, change data, add to a cart or purchase.

Draft a concise llms.txt using only verified public URLs. Include an API example only if a documented public endpoint exists and its read operation is appropriate to test. Do not invent endpoints. Rank the three most useful fixes by customer impact and effort. Explain how to retest each one.

Test what happened, not what the assistant says happened

Measure for this site’s use case: Successful task outcomes divided by all attempts, critical-error rate, recovery effort and time to a verified next step.

Run a baseline before editing. Use fresh sessions and keep the prompt and available tools comparable. Include failed attempts in your denominator. Record whether you explicitly told the agent about llms.txt; that is different from observing spontaneous discovery. A scanner is a diagnostic aid, not a certification.

Avoid the shortcuts that create new problems

• Do not replace readable pages with machine-only content. People still need to evaluate the offer.
• Do not treat robots.txt or llms.txt as authentication. Protect private routes with real access controls.
• Do not tell every crawler it may access everything merely to improve a score.
• Do not duplicate prices and policies into several files without an update process.
• Do not claim a successful booking, lead or sale from a generated answer. Verify the actual system result.

For interface implementation, consult Google web.dev: agent-friendly website UX and W3C: labeling form controls. Preserve descriptive controls, meaningful form labels and visible state changes. Agent testing complements human usability and accessibility testing.

Questions worth answering

Search guidance: Google Search: optimizing for generative AI. Documentation reviewed November 11, 2026. Provider behavior can change; recheck the linked sources when implementing.

Put one improvement to work

Start with this task: Find the correct onboarding path for a specific customer and explain the first useful result without creating an account. Save the baseline, make one justified improvement and keep the retest evidence. Use the result to choose the next useful change.

Explore outcome playbooks →

Sources and editorial notes

• llms.txt proposal and format
• Google Search: optimizing for generative AI
• Google web.dev: agent-friendly website UX
• W3C: labeling form controls
• OpenAPI specification
• Model Context Protocol architecture
• OWASP API Security Project

This guide combines primary-source documentation with original implementation advice and a fictional worked example. It is not a report of measured client results, guaranteed traffic or earnings. The examples use reserved example.com URLs and must be adapted and verified before deployment.