Agent-Friendly Website UX: A Practical Audit Checklist

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.

Map the journey across three representations

Review the rendered screen, DOM and accessibility tree. Locate the service name, price, eligibility, duration, primary action and validation message in each. A visible label should agree with the accessible name. Use a native link for navigation and a button for an action; associate form labels with their inputs. Keep layout stable while the agent decides where to act. Accessibility testing remains a human-centered practice; an agent passing a task is not proof of WCAG conformance.

Worked example: the consultation that was never booked

Illustrative scenario: Harbor Design Studio offers a 30-minute introduction. The original screen shows an unlabeled calendar icon and a “Continue” button. The redesign gives the control the name “Choose an introduction time,” displays the selected date and time zone, and labels the last action “Request this time.” After a successful response, it displays a request reference and explains whether confirmation is pending. Test that an agent describes the state as a request, rather than a guaranteed appointment.

Write a test script a designer can score

Ask the agent to locate the introduction, identify the cancellation terms, choose a hypothetical time in a test environment, and stop at review. Record the exact point of failure. Score price accuracy, policy accuracy, correct control selection and honest state reporting separately. Repeat with keyboard navigation and a screen reader. Fix the highest-impact shared obstacle before adding an agent-specific integration.

The six-step implementation

1. Choose a journey. Define the visitor’s goal.
2. Inspect the interface. Compare screen, DOM and labels.
3. Fix ambiguous states. Name actions and confirmations.
4. Publish a short map. Link the useful public pages.
5. Run a fresh test. Observe without coaching.
6. Retest with people. Preserve accessible human use.

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.

# Harbor Design Studio

> Find a suitable introductory consultation, explain its conditions, and stop before submitting a booking.

## Useful pages
- [Main information](https://example.com/services/): The current offering and relevant details.
- [Conditions and process](https://example.com/booking/): Eligibility, limitations and how the process works.
- [Next step](https://example.com/policies/): 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 a suitable introductory consultation, explain its conditions, and stop before submitting a booking.

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: Task completion, wrong-control selections, recovery steps and confirmation accuracy. Record sample size and exact agent capability.

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 a suitable introductory consultation, explain its conditions, and stop before submitting a booking. Save the baseline, make one justified improvement and keep the retest evidence. Use the result to choose the next useful change.

Explore UX worksheets →

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.