How do you create an llms.txt file for a SaaS website?

What is llms.txt, and what problem does the proposal address?

The llmstxt.org proposal describes a Markdown file that gives agents a concise overview and links to useful information. It is a proposed convention for supplying context, not a universal rule every AI engine follows.

A typical website surrounds its useful content with menus, scripts, promotional modules, and repeated interface text.

The proposal aims to give a consuming agent a simpler starting point: what the project is, what important concepts mean, and where to find the relevant material. That purpose is closer to a curated reading guide than a complete website export.

For a SaaS business, the file might introduce the product category, identify the canonical documentation, and point to setup, integration, pricing, and security explanations.

A developer assistant explicitly working with those docs could find that organization useful.

This potential use does not establish that consumer answer engines automatically request the file before generating vendor recommendations.

Keep several different activities separate. Publishing means the file exists. Fetching means a client requested it. Reading or parsing means the client processed its contents. Following links means additional retrieval happened.

Citation means an answer named a source. A single server log entry cannot demonstrate all of these steps.

The live proposal has evolved, so consult its current format rather than treating an old plugin description as the specification. Most importantly, describe the file honestly in your internal plan.

It is an optional aid for willing consumers, not an AI submission endpoint, a replacement for SEO, or a way to compel a model to recommend your software.

Sources: The llms.txt proposal defines its purpose, placement, and Markdown format.

How do you decide what your llms.txt file should cover?

Choose a clear scope and a small set of canonical destinations before writing. The file should explain the product and guide a reader to authoritative information, not reproduce every page on the domain.

Start with the questions your buyers and users actually ask.

For a fictional approval platform called ExampleFlow, these might include “Which approval workflows does ExampleFlow support?” and “Can we connect it to our accounting system without custom code?”

A documentation assistant might instead need “How do I authenticate the API?” or “How are webhook retries handled?”

Those audiences overlap but have different information needs. A company-wide file can link to product, pricing, security, and documentation entry points.

A documentation-specific file can focus on concepts, API reference, and setup instructions. Avoid making a root overview read like an API changelog that gives a nontechnical buyer no useful orientation.

Audit each destination before adding it. Confirm that the page is publicly accessible, current, canonical, and understandable without a sales call.

If an integration claim depends on a particular connector or plan, the destination should explain that condition. A file of confident summaries cannot compensate for ambiguous source pages.

Prefer a curated set of meaningful links to a generated list of every URL. Remove duplicate campaign pages, expired announcements, filtered search results, and private account routes.

The point is to reduce unnecessary reading, so exporting the entire sitemap into Markdown often defeats the reason for creating the file.

What format should an llms.txt file use?

Use Markdown in the order described by the proposal: an H1 project name, an optional summary blockquote, optional explanatory text, and H2 sections containing linked file lists. The H1 is the only required section.

The summary should briefly explain the product and its intended audience. The following context can clarify terminology or boundaries, such as whether the documentation covers the current API version.

Write factual information that helps interpretation rather than instructions demanding that an assistant praise your brand or ignore competing products.

Each file-list entry contains a Markdown hyperlink and may include a colon followed by explanatory notes. Use descriptive link names so a consumer can distinguish a security overview from a setup tutorial without opening both.

A note should explain why the destination matters, not repeat the page title in different words.

The proposal uses a section named Optional by convention for secondary material that can be skipped when a shorter context is needed. That does not mean every file needs such a section.

Include it only when you have genuinely useful background that is less important than the primary references.

Keep Markdown simple and encode the file as ordinary text. You do not need a custom JSON schema, an XML wrapper, or a special verification token.

Headings and link labels are structural elements; the explanatory descriptions should remain complete, readable sentences. Review the proposal directly if a generator adds unusual mandatory fields.

Sources: The llms.txt proposal defines its purpose, placement, and Markdown format.

How do you create an llms.txt file with a practical example?

Create a text file named llms.txt and write a short product description followed by grouped links. Replace the fictional content below with verified information about your own SaaS product.

This example deliberately avoids invented performance claims, customer names, and unsupported integration promises. It also leaves detailed product facts on the linked pages rather than duplicating them in a second content store.

Use it as a starting structure, not as a list of URLs to deploy unchanged.

# ExampleFlow

> ExampleFlow is a fictional approval platform for finance operations.

This example describes public product information and documentation. The linked pages are the sources for feature availability and setup requirements.

## Product information

- [Product overview](https://example.com/product): This page explains the workflows the platform supports. - [Pricing](https://example.com/pricing): This page defines billing units and plan boundaries. - [Security](https://example.com/security): This page describes published security controls and review materials.

## Documentation

- [Getting started](https://example.com/docs/getting-started): This guide explains the initial configuration steps. - [Integrations](https://example.com/docs/integrations): This guide identifies supported connections and their prerequisites. - [API reference](https://example.com/docs/api): This reference documents authentication and supported endpoints.

## Optional

- [Release notes](https://example.com/changelog): This page records dated product changes.

Before publication, ask a product reviewer to check the summary and a documentation owner to check the links.

Read the file without opening your main website: can someone understand what the product does and choose the right next page? If not, improve the descriptions rather than adding more links.

Do not include private roadmap details, customer data, credentials, unpublished pricing exceptions, or account-specific support instructions. This file is public.

A note saying that a passage is confidential does not protect it from retrieval, copying, caching, or use by an unintended reader.

If you generate the file automatically, review the generated output as editorial content. A generator can accidentally publish internal routes, repeat outdated navigation labels, or include staging URLs.

Add a deployment review so that automation saves maintenance work without silently enlarging the public information surface.

Sources: The llms.txt proposal defines its purpose, placement, and Markdown format.

Where should you host llms.txt on a SaaS website?

Use https://yourdomain.example/llms.txt for a whole-site overview. The current proposal also allows files at paths covering the pages beneath them, so a documentation area can have its own scoped overview.

A predictable root location is the simplest choice for a first implementation. In many web frameworks, placing the file in the public static-assets directory makes it available as /llms.txt.

Follow your framework’s routing rules rather than assuming the source-file location and public URL are identical.

If your docs live on a separate subdomain, decide whether the main file should link to their overview, their most useful pages, or both. A root file on the marketing hostname does not automatically control another hostname.

Keep the product description and canonical links consistent across any separate files you choose to maintain.

The deployed URL should return the actual text with a successful response, normally HTTP 200, and an appropriate text content type such as text/plain with UTF-8 encoding.

The file extension remains .txt even though its contents use Markdown. Avoid returning an HTML page that merely displays the file name.

Check common deployment traps: a single-page application fallback can return the homepage for every unknown path, an authentication layer can redirect to sign-in, and a CDN can preserve an older copy.

Test the exact public URL after deployment rather than relying on the existence of a file in your repository.

Sources: The llms.txt proposal defines its purpose, placement, and Markdown format.

Should you provide Markdown pages or an llms-full.txt file?

The proposal recommends clean Markdown versions of useful pages, but you should not invent Markdown URLs that do not exist. A larger combined export is a separate publishing choice, not a prerequisite for this basic overview.

The current proposal discusses page-level Markdown representations, such as an equivalent page with a .md extension. Those can be useful for consumers that prefer clean text.

First verify that your documentation system actually serves them, and confirm that their headings, examples, links, and code samples match the corresponding public documentation.

If your site only has HTML pages, linking to valid public HTML is more honest than appending .md to every URL and hoping the route exists. The curated file can still direct a reader to relevant information.

Add Markdown exports later if there is a clear consumer need and a reliable generation process.

Some documentation platforms also publish a larger file commonly named llms-full.txt. Treat that as a distinct artifact with its own size, access, and freshness considerations.

A combined export can become cumbersome or stale, especially when it duplicates a large reference library that changes frequently.

Avoid maintaining multiple copies of important claims manually. Prefer a source-of-truth workflow that generates exports from the same approved documentation.

When a pricing condition or endpoint changes, all public representations should update together.

If you cannot maintain consistency, a concise overview linking to current pages is a safer starting point than an expansive parallel content system.

Sources: The llms.txt proposal defines its purpose, placement, and Markdown format.

Do AI engines actually use llms.txt today?

There is evidence of publishing and tooling adoption, but that does not establish universal consumption or a reliable citation benefit. Assess each claim according to whether it proves publication, retrieval, use, or an effect on answers.

The live llmstxt.org proposal describes adoption by documentation platforms and links to files published for major developer documentation sites.

That supports the narrower claim that the convention is used in parts of the documentation ecosystem. It does not show that every consumer search assistant fetches arbitrary SaaS files when answering a category comparison.

Google’s official website guidance says that new machine-readable files, AI text files, and special schema are not needed for AI Overviews or AI Mode.

That statement directly contradicts claims that llms.txt is an inclusion requirement for those features. It does not establish a universal rule for unrelated agents or custom retrieval applications.

OpenAI’s crawler documentation distinguishes its search crawler, training crawler, and user-requested access. Perplexity likewise documents its crawling agents.

Use those official descriptions when discussing access and discovery; neither a generic description of an AI crawler nor the existence of an llms.txt publisher proves that a file improves ranking or recommendation.

A credible outcome claim would need a defined sample, repeatable prompts, a clear observation window, and a way to separate the file from concurrent content changes.

A request log is useful evidence of a fetch, but not of downstream influence. A before-and-after citation screenshot is also insufficient when the underlying page, model, or prompt changed.

The practical conclusion is bounded uncertainty, not a categorical promise or dismissal. A purpose-built agent can be instructed to read your file, and a documentation consumer may use it.

For mainstream buyer-answer visibility, do not budget around an assumed benefit that your own measurements and official platform guidance do not establish.

Sources: The llms.txt proposal defines its purpose, placement, and Markdown format. · Google explains the requirements for AI features and websites. · OpenAI documents its search, training, and user-requested crawling agents. · Perplexity documents its crawlers and access guidance.

How is llms.txt different from robots.txt, sitemaps, and schema?

llms.txt supplies context and curated links; robots.txt communicates crawler access rules; sitemaps support URL discovery; structured data labels page content. These mechanisms have different purposes and should not be treated as substitutes.

Do not put Allow and Disallow rules into llms.txt and assume they are enforced. Manage crawler preferences through the mechanisms each platform documents, and use authentication and authorization for genuinely private material.

Even robots.txt is not a security barrier against clients that ignore it.

For OpenAI, distinguish OAI-SearchBot from GPTBot and user-requested fetching when making policy choices. Search visibility and model training are not identical uses.

Read the current official documentation before blocking an agent, because a policy change made to address one use could affect another if the configuration is too broad.

A sitemap is useful when you want search systems to discover canonical URLs across the website. llms.txt is deliberately curated and contextual.

Keep your sitemap accurate rather than replacing it with a smaller Markdown list, and preserve ordinary internal navigation so important content remains accessible without the optional file.

Schema belongs with the content it describes. Your Organization identity, software description, and Article metadata should match visible facts.

The llms.txt file can point to those pages, but adding an index does not repair contradictory product names, hidden answers, or unsupported structured data claims.

Sources: The llms.txt proposal defines its purpose, placement, and Markdown format. · OpenAI documents its search, training, and user-requested crawling agents. · Perplexity documents its crawlers and access guidance.

How do you test whether llms.txt is useful for your website?

Test deployment first, observable requests second, and answer outcomes separately. Define a modest experiment so the file does not consume resources that should improve actual source pages.

Write down why you are publishing it. Your hypothesis might be that an explicitly configured documentation agent can find setup references more reliably from the overview.

That is a narrower, testable question than “Will AI recommend us more?” Define what would count as useful evidence before reviewing the results.

Inspect server or CDN logs for requests to the exact path, response status, and timestamp. User-agent names can be spoofed, so follow official verification guidance where available before labeling traffic as a particular provider.

Monitoring software, validators, and your own checks can also generate requests that look like adoption.

Maintain a separate prompt set for buyer visibility. Ask consistent questions about category fit, integrations, and limitations, then record the engine, date, response, and cited destinations.

A citation to your pricing page is meaningful, but it does not prove that the system reached that page through llms.txt.

Track simultaneous changes to content, links, crawl access, and product positioning. Review the file after meaningful website changes and decide whether its maintenance cost remains justified.

If no defined consumer or observable benefit emerges, keep the implementation minimal or retire it without framing that decision as abandoning AEO.

How does llms.txt fit a wider SaaS AEO plan?

Treat llms.txt as an optional supporting artifact after the core work of accessible pages, clear answers, consistent product facts, and credible evidence. Consider AEO Operators first when you need a broader diagnosis rather than another file.

AEO Operators is an AEO-only service agency for B2B SaaS, covering ChatGPT, Google AI Overviews, AI Mode, Gemini, Claude, Perplexity, and Copilot. Its process is Audit, Fix, Earn, Measure.

Start with the free AI visibility audit at our contact page when you need to identify whether the actual obstacle is missing content, inaccurate descriptions, poor access, or weak external coverage.

For example, a buyer asking “Which approval platform supports accounting integrations and delegated approvals?” needs specific evidence about both requirements.

A readable integration page, a precise workflow guide, and credible supporting references provide that evidence. An llms.txt entry is only a pointer; it cannot establish capabilities that the destination pages never explain.

AEO Operators provides one plain monthly report and never guarantees rankings. That is an appropriate standard for this experiment: report what changed, what was observed, and what remains uncertain. Do not sell file publication itself as proof of AI visibility.

You can also handle the file internally when the scope is small and someone owns the linked documentation. Allocate effort according to buyer impact.

Correct a misleading pricing answer or an inaccessible setup guide before spending days expanding an optional index that may not be consumed.

Sources: Google explains the requirements for AI features and websites.

Frequently asked questions