llms.txt for SaaS: What We Shipped to Get Found by AI Crawlers

An llms.txt file is a plain-markdown map of your site that you publish for language models to read — and if you're shipping one because you heard it makes ChatGPT cite your SaaS, I have to be the one to tell you: probably not, at least not on its own, and not the way people are selling it. We shipped one for ReplyArgus. It's a good idea. It's also the smallest lever in the whole "get found by AI" question, and the loudest one gets the least return.

This is the honest version. What llms.txt actually is and where it came from, whether the big models read it yet (the answer is not what the SEO threads want it to be), and the handful of things that genuinely decide whether an answer engine can find and quote you: the robots.txt allowlist, clean server-rendered HTML, structured data, and content shaped so a model can lift the answer. Here's what we shipped, in order of how much it matters.

llms.txt is a proposed convention: a single markdown file at the root of your domain (`yoursite.com/llms.txt`) that hands a language model a clean, curated summary of what your product is and where the important pages live. It was proposed in September 2024 by Jeremy Howard of Answer.AI, and the format is deliberately dull: an H1 with your name, a blockquote one-liner, then sections of annotated links. Some sites also ship a longer `/llms-full.txt` with the actual prose inlined.

The reasoning behind it is sound. A model that lands on your marketing page has to wade through navigation, cookie banners, JavaScript-rendered widgets, and ad slots to find the one sentence that says what you do, and it burns a limited context window doing it. llms.txt is the same instinct as a good README: skip the chrome, here's the map, in the plain markdown these models parse most reliably. Ours is short on purpose.

Short answer: as of mid-2026, none of them have publicly confirmed they consume llms.txt at crawl time or at inference. Google has said it doesn't use the file, and its search advocates have compared the idea to the long-dead keywords meta tag, a signal publishers fill in that the engine quietly ignores. Server-log analyses that people keep posting tell the same story: the big AI crawlers request your HTML pages and your sitemap far more than they ever request `/llms.txt`. Real adoption on the publishing side, unconfirmed adoption on the reading side. That's the actual state of it.

So why did we ship one anyway? Because it costs an afternoon, has zero downside, and it's a cheap forward bet. If the standard gets picked up, we're already there; if it doesn't, we've lost a static file. It also doubles as a genuinely useful human artifact: a clean, one-glance description of the product you can point anyone at. What you should not do is treat it as a ranking lever or expect it to change whether an answer engine quotes you. It won't. The things below will.

If your goal is to be the thing ChatGPT or Perplexity names when someone asks "what's a good tool for replying to app reviews," the mechanics are less exotic than the llms.txt hype implies. Four things do almost all the work, roughly in order:

Every answer engine crawls with a named user agent, and if you've ever pasted a generic "block AI bots" snippet into your robots.txt, you may have quietly locked yourself out of citation. The bots that matter right now are `GPTBot`, `OAI-SearchBot`, and `ChatGPT-User` for OpenAI, `ClaudeBot` and `Claude-Web` for Anthropic, `PerplexityBot` for Perplexity, and `Google-Extended` for Google's AI surfaces. Decide deliberately which of those you welcome, and know the tradeoff: some are training crawlers, some are live answer-engine fetchers, and blocking the second kind is what actually costs you visibility.

Our robots.txt names those agents explicitly and welcomes them onto the marketing surface while keeping the signed-in app, auth callbacks, and API routes out of the index. It also points every crawler at the sitemap and declares the canonical host, so there's no ambiguity about which URL is the real one. The signed-in dashboard has nothing a crawler needs; the blog, features, and pricing pages are the whole point. That split, public surface open and product internals closed, is the posture you want.

The single highest-leverage habit isn't a file at all. It's structure. When someone asks Perplexity a question, it's looking for a passage it can quote with attribution. Pages that open with the direct answer, then support it, get lifted. Pages that open with "In today's crowded app market…" get scrolled past by humans and skipped by models for the same reason: the answer is buried.

Then you make the facts machine-readable. Every post on this blog emits JSON-LD: BlogPosting for the article, BreadcrumbList for the trail, and, where a post has a FAQ or a step-by-step, FAQPage and HowTo schema generated straight from the content. That's the difference between a model inferring your Q&A from paragraph soup and reading it as a typed list it can quote verbatim. The FAQ block at the bottom of this post becomes FAQPage structured data on publish, the technique demonstrating itself.

None of this replaces being genuinely the best answer. Schema on a thin page just helps a machine parse a page nobody should cite. The order is: be right and be deep first, then make it easy to fetch, parse, and quote.

If you want to do this for your product, here's the order that matters, cheapest and highest-impact first:

That sequence is the whole answer to "how do I get my SaaS found by AI," and notice llms.txt is at the bottom, not the top. The loud, novel thing is the least of it. The unglamorous work is what puts you in the citation: letting crawlers in, rendering real HTML, answering the question in the first line, marking up your facts.

It's the same conviction that shaped ReplyArgus. We didn't just want a review tool a search engine could find; we wanted one an agent could run, which is why the review inbox, grounded drafting, and roadmap board all sit behind a connector any assistant can call. If you ship apps and want your reviews answered by a system built this way, you can see how it compares in [the review management roundup](/blog/best-app-review-management-software-2026) or connect a store and watch it draft the first one.