An llms.txt file is a proposed, plain-text reading guide that points an AI-capable tool toward useful pages. It can make a website easier for an agent to navigate if that agent encounters and chooses to use it. It does not, by itself, make a business appear in Google's AI answers. At WaveHello, we treat it as one optional route into verified public information—not a substitute for a website that answers your customers' actual questions.
What is llms.txt, in ordinary terms?
llms.txt is a proposed, plain-text reading guide that points an AI-capable tool to useful site resources. It can help an agent that encounters and chooses to use the file. It is not a replacement for public service pages, a sitemap, or clear answers to customer questions.
We would first make the ordinary website accurate, accessible, and useful. Then we can add a concise agent-facing guide if there is a real route for a tool to discover and use it.
Imagine arriving at a large website and finding a short guide that says what the business does and which page answers each kind of question. That is the core idea behind llms.txt. The proposal places a Markdown file at /llms.txt, with a title, a short description, and links to relevant resources. Its newer version also describes files for specific site paths and clean Markdown versions of individual pages.
The name can sound like a command to every AI system. It is not. A tool has to encounter the file, retrieve it, and decide the links are useful for the task. The file is a map of information supplied by the site owner, not independent evidence that the business is the best choice.
How is llms.txt different from a sitemap or robots.txt?
A sitemap gives search crawlers an inventory of URLs. Robots.txt expresses crawl permissions. An llms.txt file is a curated reading path: it tells a capable reader which resources might answer which questions. One file does not replace the other two, and placing a page in any of them does not guarantee indexing or an AI citation.
The official proposal was especially useful for documentation: an agent working on a technical task can use the guide to find the relevant instructions without reading an entire site. A business website has a different challenge. The agent first has to find the business among alternatives, and then establish that the business actually offers what the customer needs.
The key distinction: being discovered versus being understood
Suppose a person asks, 'Who can build a website with a form that connects to my current CRM?' Before an assistant reads WaveHello's special files, a search system must consider one of our public pages relevant enough to retrieve. A file that is never encountered cannot influence that particular answer through its contents. That is why the ordinary website needs to describe the service, the conditions, and the customer's question clearly.
After a relevant page is encountered, a clear link or a machine-readable route may help the assistant find deeper details. The opportunity is to make that next step understandable: what the linked page answers, what information it needs, what it establishes, and what remains unknown. That is a possible use of llms.txt and related page representations; it is not a claim that every AI assistant currently follows the route.
Does llms.txt improve Google rankings or AI Overview visibility?
No file can guarantee that outcome. Google currently says Google Search does not use llms.txt for rankings or its generative AI features. A file may still be useful to another tool that reads it, but that is a different claim.
For Google discovery, focus first on public, crawlable pages that explain your services, conditions, and evidence in language customers understand. Measure discovery, correct use, and inquiries separately.
Google currently says it does not use llms.txt for Google Search, including its generative AI features. Google may crawl or index many kinds of files, but that does not give this one special ranking or AI-answer treatment. We will not sell a file upload as a shortcut to appearing in AI results.
Google's guidance instead emphasizes accessible, indexable pages and distinctive, useful content that answers people well. A public service page can be considered for discovery; a relevant section can help a system understand the answer after retrieval. Both jobs require real information. A neat Markdown copy of an empty claim is still an empty claim.
Could another AI agent use llms.txt even without special training?
Possibly. If an agent can read text, follow links, and decide which source answers the person's question, it may use a helpful page or file without having memorized that filename. A site can make the route easier by explaining it in the page or response headers. The proposal suggests a described-by link to the applicable llms.txt and a Markdown alternate for a page.
There are limits: some systems never expose the file to the model, some do not follow the link, and others already have enough information from the public page. We separate the possibility from observed behavior. The useful test is whether an unfamiliar, unbriefed agent discovers the route, interprets the facts correctly, and gives a better answer—not whether we can persuade an agent after telling it exactly where to look.
How WaveHello connects the file to the actual website
WaveHello publishes service information and customer answers in ordinary HTML first. Our /llms.txt points to canonical service pages, the public FAQ, and a reading directory. The FAQ has text-only versions for readers that prefer them. Those routes are different presentations of the same published facts, not a hidden set of more flattering claims.
We also distinguish a service we offer from a technique we are explaining. A page about what CRM integrations can do is not proof that every CRM and workflow has been implemented for a client. We state conditions, link to the relevant service and contact path, and leave unknowns visible. If a source changes, the public page and alternate representation need to agree.
What should a small business do before adding llms.txt?
Start with the questions customers ask before they choose a provider: what you offer, who it is for, where it applies, what it costs or how pricing is determined, what the limitations are, and what happens when someone contacts you. Answer those on public, crawlable pages. Link related pages when they resolve a real next question; do not force a reader to follow five links to learn whether you can do the job.
Then check the foundation: the pages return successfully, important text is available to search tools, canonical URLs and navigation make sense, and the contact route works. If an llms.txt file would help an agent explore your information, add a concise guide that points to those same truths. Do not create hundreds of near-identical Q&A pages or promise that the file changes rankings.
How would we know whether this approach helps?
We would test different questions separately. Can an unbriefed assistant find the business? Once it reaches a page, can it identify the right supporting answer and preserve its limitations? Do real visitors then reach the contact path and submit suitable inquiries? Those are discovery, interpretation, and business-outcome tests; one success does not prove the other two.
That is the opportunity we care about at WaveHello: not a magic file, but a website whose verified information survives the journey from customer question to retrieved source to useful answer. llms.txt can be part of that journey when a particular tool uses it. The public website has to stand on its own when it does not.