.boss is live / claim your leadership name today Search .boss
Back to blog
// POST 102 / 133

How to Make Your Website AI-Agent Readable

Published May 5, 2026 Updated September 18, 2026 / AI AGENTS
How to Make Your Website AI-Agent Readable

To make your website AI-agent readable, publish the information a customer needs in accessible text, give it clear links, and explain how to complete the next step. Add Markdown or workflow instructions where they help the clients you want to support. A callable API is a separate project if your site needs one.

Start with a question someone might actually ask: “Can I rent this equipment for Saturday, what will it cost, and how do I request it?” An assistant should be able to find the answer on your site without inventing a delivery charge or mistaking an enquiry for a confirmed booking.

Your website can keep its design. Make the underlying content easier to retrieve and follow. When you also operate an agent or agent-facing service, a Headless Domains name gives that service a public identity connected to its current records.

1. Make one customer question answerable

Choose a useful task before adding files. For example, let's take a hypothetical equipment rental company, the first task might be preparing a weekend rental enquiry. The assistant needs the equipment options, rental period, service area, deposit policy, delivery terms, and enquiry instructions.

Put those facts in the page text. Give prices their currency and billing period. Explain whether tax, delivery, and deposits are included. If availability requires staff confirmation, say so beside the enquiry form. “From $80” is a poor basis for a quote when the rest of the price lives in a picture.

Use descriptive headings, ordinary links with real destinations, and HTML tables for comparisons. Label form fields and buttons clearly. Keep essential facts in the initial HTML where practical so a client that does not render JavaScript can still read them. Check the extracted text as well as the browser view.

Structured data should agree with what the page says. Google's guidance for AI features in Search calls for accessible text and consistent structured data; it does not require special AI files or a new kind of schema markup.

2. Add a short route to the useful pages

A customer should not need to read your entire website to understand a rental. Neither should their assistant. Link the relevant policies from the service page and put the next step where a reader can find it.

For a larger site, consider llms.txt. Version 2 of the publishing proposal supports both a root file and a scoped file such as /docs/llms.txt. Keep it concise, with links to useful documentation and clean Markdown where available. Client support varies, so publish its exact address and keep normal navigation working.

Here is an illustrative root file for our example rental business. Replace the example addresses with pages you actually maintain:

# Example Equipment Hire

> Equipment rental enquiries for customers in our published service area.
> Availability and final prices require confirmation from our team.

## Plan a rental
- [Equipment](https://example.com/equipment/): Models and rental periods.
- [Pricing](https://example.com/pricing/): Rates, deposits, and exclusions.
- [Delivery](https://example.com/delivery/): Service area and delivery terms.
- [Request a quote](https://example.com/docs/rental-enquiry.md): Required details and submission steps.

A small brochure site may already have a clear enough route through its normal links. You can launch without llms.txt.

3. Publish Markdown where it saves work

Long instructions can be easier to retrieve as a clean Markdown document. A stable URL such as /docs/rental-enquiry.md is enough if your intended client can fetch it. Generate it from the same source as the human page where possible, so the two versions stay aligned.

You can advertise the alternate in the HTML page's head:

<link rel="alternate" type="text/markdown"
      href="https://example.com/docs/rental-enquiry.md">

Another option is content negotiation. Cloudflare Markdown for Agents, when enabled, converts eligible HTML responses for requests carrying Accept: text/markdown. Test the returned content type and body. Sending the header to an arbitrary website does not make Markdown appear.

Check that the alternate retains the details a customer needs, including caveats, links, and table labels. If you use Cloudflare's conversion, review its Content Signals behavior too: the documented default permits search, AI input, and AI training when the origin has not supplied its own signal.

4. Describe the next step honestly

Write a short rental-enquiry guide. Ask for the equipment, dates, collection or delivery preference, and contact details your team actually needs. Explain where to submit the enquiry and when to expect a reply. If staff still have to confirm availability, the assistant should report that the enquiry was received, not that the equipment is booked.

You can host that guide as an ordinary Markdown page. If you want to distribute an installable skill, follow the Agent Skills format: a directory containing SKILL.md, with required name and description frontmatter. The client must load it through a supported mechanism. A public page does not install itself or supply tools the assistant lacks.

Preserve exact URL casing. A published /skill.md address and a package's SKILL.md filename are different things.

Only add a callable interface when your business offers one:

What the visitor needs What to provide
Understand services and policies Readable pages with clear links.
Prepare an enquiry A workflow guide and an explicit submission or human handoff route.
Use an existing HTTP API An accurate API contract, access instructions, and a compatible client integration.
Use tools through MCP A working MCP server supported by the intended client.

OpenAPI 3.2.1 was published on September 10, 2026. Use a version your validators and clients support, and keep the description consistent with the live API. MCP can expose tools and other resources to compatible clients. Neither document publication nor protocol support grants permission to place an order; the application and receiving service must enforce access and approval.

If your next step involves building those operations, use our agent-ready API guide. A website whose job is answering questions can stop well before that work.

5. Give the public service a name you can maintain

As your service grows, its website, instructions, and callable endpoints may live in different places. A Headless Domains name connects the offering to its maintained public records, giving people and compatible clients a consistent place to start.

Choose a namespace that fits the service. A conversational assistant might use .chatbot; an operated business process might use .bpo. Other available namespaces include .agent, .boss, and .factory. Your website and API can stay on their existing hosts.

Publish through the supported Headless Domains record controls. Use the documented lookup and resolution routes, then follow the returned links. Do not assume a headless name behaves like an ordinary browser URL or that every service puts its manifest at the same path.

Use the manifest schema your platform documents. For the differences between navigation files, workflow packages, and public manifests, see llms.txt vs SKILL.md vs agent.json.

The Agent Identity Stack explains how public identity connects to service discovery and verification. Keep the records current when endpoints or instructions move; callers with saved URLs may still need an update.

6. Test the website with a real customer task

Give a supported assistant the starting URL and this request, adapted to your business:

Prepare an enquiry for a weekend equipment rental. Find the service area, pricing basis, deposit requirements, and information the rental company needs. Cite the relevant pages. Flag anything that needs confirmation. Do not submit the enquiry.

Compare its answer with the published facts. Did it include the deposit? Did it confuse a daily rate with a weekend total? Could it find the enquiry instructions through the links you provided?

Then change one condition, such as a delivery address outside the service area. The answer should reflect the restriction. Fix the page or missing link that caused the mistake and repeat the affected task. Record the client and configuration you tested; another assistant may fetch or interpret the site differently.

If the client cannot reach the pages, inspect crawler directives and CDN rules. OpenAI documents separate controls for its search crawler and training crawler. User-triggered retrieval is a separate case. Apply your publishing policy deliberately rather than copying an “allow AI” rule.

For a broader access and monitoring review, use the AI crawler readiness checklist. Readability makes the site more usable; it does not guarantee a search position or an AI citation.

Put your first useful page to work

Pick the service customers ask about most. Make its terms readable, connect the supporting pages, and test whether an assistant can prepare the right next step. You will learn more from one missed delivery restriction than from publishing six files nobody has tried to use.

When that service needs a public identity across tools and platforms, send your assistant the Headless Domains getting-started instructions. Ask it to explain the registration options and connect your chosen name to the public records for the service you operate.

#AI agents #llms.txt #machine-readable content