What Is llms.txt, and Does Your Website Need It?

llms.txt is an optional guide for agents using your website. It is not a prerequisite for appearing in Google or its AI search features. For most small businesses, it belongs behind accurate service pages, useful articles and a website that visitors can read and use.

If you maintain extensive product documentation, it can still be a sensible addition. The decision should depend on a real use case, not fear that a missing file makes your business invisible.

Updated October 29, 2026: this guide replaces earlier claims that llms.txt is essential for AI visibility. It distinguishes the proposal's documentation use case from Google's published search guidance.

What is llms.txt?

Jeremy Howard's proposal describes a Markdown file containing brief context, guidance and links for agents. The current v2 proposal allows it at the site root or within a section such as /docs/llms.txt. It can point to clean Markdown versions of detailed pages. It is a proposed convention, not a requirement imposed on every website. Read the llms.txt proposal.

Think about the task you want someone to complete. A developer asking an assistant how to connect an API needs an accurate starting point and working documentation links. A buyer researching a local service needs clear information about the service itself. Those are different problems, even though both people might use an AI tool.

Does llms.txt help Google rankings or AI search?

Google explicitly says Search does not use llms.txt or require special AI files. Its guidance says maintaining one for other systems neither helps nor harms Google Search visibility or rankings. That is a statement about Google, not proof that every other agent ignores the file. Google's official AI search guidance.

We would not buy an SEO service whose main promised result is installing this file. Ask what measurable problem the work solves. “Our customers' coding agents need help finding the right setup guide” is specific enough to test. “Every AI will recommend us” is not a credible acceptance criterion.

Should your business add one?

These are editorial recommendations, not measured rankings. They are meant to help a small team spend its time on a concrete customer need.

A small example you can understand

This fictional software company uses a short guide to point an agent toward its setup instructions. The domains are examples, not live resources to copy into your own file.

# Example Booking

> Appointment booking software for independent service businesses.

## Documentation
- [Getting started](https://example.com/docs/getting-started.md): Create a booking page.
- [Website installation](https://example.com/docs/install.md): Add booking to an existing website.
- [API reference](https://example.com/docs/api.md): Endpoints and authentication.

## Support
- [Troubleshooting](https://example.com/docs/troubleshooting.md): Diagnose common setup problems.

The proposal describes headings, an optional summary and organized links; check its current format before implementation. See the format specification. Our example deliberately leaves prices and promises out. Those belong on authoritative pages the business already maintains, unless the team has a reliable way to keep copies synchronized.

How to create and maintain it without another project

1. Choose the reader's task. Write down one or two things an agent should be able to help a customer do. Avoid starting with a dump of every page on the website.
2. Select authoritative destinations. Prefer the current installation guide over an old announcement. Have someone familiar with the product check each link.
3. Write descriptions that distinguish the pages. “Set up a booking page” is more useful than calling every link an essential resource.
4. Publish through the system you already use. Ask your developer or documentation owner to serve the file at the intended path. Check that an ordinary signed-out request returns the text you expect.
5. Test a real documentation task. Give your chosen assistant the file and ask it to locate the relevant instructions. Check the answer against the actual documentation. This tests that workflow, not organic search discovery.
6. Assign an owner. Review the file when documentation moves, a feature changes or an important guide is replaced. A tiny file still becomes outdated if nobody owns it.

Do not include private credentials, internal notes or unreleased product details. If a page is not intended to be public, a public file should not become a convenient list of its location. Keep the guide focused on information you already intend customers and agents to use.

Measure a real outcome

For a documentation project, keep a small checklist of representative questions and record whether the assistant reaches the correct current guide. Save the date, tool and exact question. Compare like-for-like tasks after a change.

A file request in server logs does not tell you that an assistant recommended your product. An accurate answer in a test does not tell you how many new customers found you. Keep usage, answer quality, site visits and enquiries separate. If a metric is unavailable, leave it unknown.

For search work, our research review of JavaScript and AI crawlers explains how to check page delivery and bot access without confusing those checks with rankings. That is a more useful diagnostic path when your concern is whether the website's actual content can be read.

What should you prioritize instead?

Start with the questions that keep coming up in sales conversations. Does your website answer them clearly? Can a buyer tell whether the service fits their situation? Is there a useful next step after they finish reading?

Then review the articles you already have. Correct outdated explanations, add evidence where a claim needs support and connect useful related pages. Use the Search Console planning workflow to turn actual search observations into a shortlist of work, rather than adding files because another checklist says so.

If finding topics and publishing consistently is the bottleneck, outwrite.ai researches and writes articles and can publish them through a connected CMS. You can try it free for seven days without a credit card. Keep optional technical experiments small enough that they do not replace the content your customers need.