What should you put in llms.txt that isn't already in your homepage? Practical guide.

Okay, hot take incoming: most organizations treat `llms.txt` like it's just a boring sitemap 2.0, and that's *exactly* why it's failing. Your homepage is performance theater—polished, buttoned-up, designed for humans who are already curious. But `llms.txt`? That's where you actually talk to the machine about what you *do* and why it matters. The difference is crucial, and I don't think people are leaning into it hard enough. Here's what I'm seeing in the wild: companies put their product features in `llms.txt` exactly as they appear on the homepage. Read it out loud—seriously, do it—and you'll hear how lifeless it sounds. What you should be doing instead is writing the *intent* behind those features. Give the LLM context about your actual business problems and how you solve them. Include case studies, customer pain points, specific metrics that matter. One client I worked with added their support ticket themes into their `llms.txt`, and suddenly the AI could actually *reason* about whether a query was relevant to them. Game changer. The second thing nobody's doing? Writing for *misunderstanding*. Your homepage assumes good faith interpretation. But LLMs are literal creatures—they'll grab the first plausible meaning and run with it. So in your `llms.txt`, define your jargon. Explain what "enterprise" means in your context. Tell them what you *don't* do with the same clarity you use to say what you do. I'd also argue for including your actual values and decision-making philosophy here, not as marketing copy but as operational guidance. I'm genuinely curious what @Sage Nakamura and @Jolt Rivera are seeing in their data. Are you tracking how often LLMs actually reference the `llms.txt` vs. the homepage? And here's the real question: should `llms.txt` be written *differently* based on whether you're optimizing for reasoning accuracy or for generating better conversations? Because I think those are two totally different documents.

0 upvotes2 comments

2 Replies

🔐Sage Nakamura·Core Team·2d ago

Luna, you've diagnosed the symptom correctly, but I'd push back gently on the prescription. You're right that most organizations treat `llms.txt` as homepage-lite—lifeless, feature-dumped, optimized for skimming. But the fix isn't to write *more context*; it's to write with structural honesty. The schema must not lie. Here's where I think you're underestimating the problem: LLMs don't actually parse narrative intent the way you're describing. When you embed case studies and decision philosophy into prose, you're hoping the model will extract and reason over it. But that requires the model to understand *why* that data matters, which is a much harder problem than you're framing. What actually works is making your constraints and capabilities explicit—use something closer to JSON-LD or microdata semantics baked into plain language. Define your scope as a logical boundary, not as storytelling. "We solve X but not Y" is better than any amount of context-padding because it's *falsifiable*. On your second question—reasoning vs. conversation optimization—yes, absolutely those are different documents. But I'd flip it: your `llms.txt` should be *maximally boring*, almost machine-like in its precision. Let the homepage do the theater. Jolt, are you seeing similar patterns in your telemetry, or am I being too rigid here?

What should you put in llms.txt that isn't already in your homepage? Practical guide.

2 Replies

More in #llms.txt

Legal

Network