Your website needs to answer the questions an AI assistant asks before a lead arrives

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.

Write for a buying decision

Organize the service page around questions that change fit. Does the offer apply to this type of company? What work is included? What information is needed? What happens after an enquiry? Give specific answers without inventing certainty. Use clear internal links and preserve important information as readable text.

Worked example: a lead with the wrong expectation

Illustrative Northstar Operations offers a workflow diagnosis, not an ongoing managed service. An assistant reads an old landing page and describes monthly support. The team aligns the current service page, redirects obsolete offer material appropriately, and updates the site map. The test asks for a recurring support arrangement. The assistant should state the available scope and identify the enquiry route for anything beyond it.

Connect testing to the funnel you can observe

Keep an agent test log separate from production analytics. Record source availability, answer accuracy and handoff success in the test. In production, measure identifiable AI referrals where available, qualified enquiries and confirmed conversions using the existing consent and analytics setup. Missing referrers and agent actions can limit attribution. Do not count every bot request as a prospect or every visit to llms.txt as a lead.

The six-step implementation

1. Define the buying question. Focus on fit and expectations.
2. Align the offer facts. Resolve conflicting claims.
3. Improve the handoff. One clear next action.
4. Add the site map. Use maintained source pages.
5. Test the explanation. Include a poor-fit customer.
6. Review funnel evidence. Connect to qualified enquiries.

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.

# Northstar Operations

> Decide whether a service fits a business need and locate the correct enquiry step without submitting it.

## Useful pages
- [Main information](https://example.com/services/): The current offering and relevant details.
- [Conditions and process](https://example.com/pricing/): Eligibility, limitations and how the process works.
- [Next step](https://example.com/contact/): 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: Decide whether a service fits a business need and locate the correct enquiry step without submitting it.

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: Correct fit decisions, enquiry quality and confirmed conversion events. Report attribution gaps and campaign changes.

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: Decide whether a service fits a business need and locate the correct enquiry step without submitting it. Save the baseline, make one justified improvement and keep the retest evidence. Use the result to choose the next useful change.

Explore AI workflow support →

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.