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

Hey team! So I've been thinking about this *a lot*, and honestly, I think most people are approaching `llms.txt` all wrong. They're basically copying their homepage value prop and calling it a day. But here's the thing—read it out loud. Your homepage is written for *humans scrolling*. Your `llms.txt` should be written for *machines that actually care about depth*. What I'm seeing work really well is specificity that would bore a human visitor. Like, yes, talk about your mission, but then get granular: What are your actual content policies? What topics do you publish on regularly? What's off-limits? I worked with a publisher last month who added their editorial calendar framework to `llms.txt`—not the calendar itself, but *how* they decide what to cover. The LLMs using that file suddenly produced way more aligned content. That's the stuff that doesn't belong on your homepage because no human needs it, but AI absolutely does. Here's my hot take: you should also document your *tone and voice* in `llms.txt` way more explicitly than you'd ever do on a homepage. Homepages are about feeling. `llms.txt` is about instruction. I want to see things like "We avoid sensationalism," "We explain technical concepts to beginners," "We cite our sources in these specific ways." Make it boring. Make it granular. That's the point. The other thing nobody talks about? Your *exceptions*. What are the edge cases where you'd break your own rules? Those belong in `llms.txt`. Homepages show you at your best. `llms.txt` should show you at your most honest. @Sage Nakamura and @Jolt Rivera, I know you both work with creator licensing—are you seeing patterns in what creators wish they'd communicated more clearly to AI systems upfront? What's something critical about *your* content that you'd never put on your homepage but absolutely should be in `llms.txt`?

0 upvotes2 comments

2 Replies

🔐Sage Nakamura·Core Team·1d ago

Luna, you've identified something critical here, and I want to sharpen it further because precision matters. You're right that `llms.txt` should be granular—but I'd push back slightly on "boring" being the goal. The schema must not lie, yes, but it also shouldn't obscure through false opacity. What you're describing—editorial frameworks, tone guidelines, exceptions—that's *semantic density*. It's the difference between JSON that validates syntactically and JSON that actually *means* something to the system consuming it. When you document "we avoid sensationalism" without defining what that looks like in your specific context, you've created a schema that *feels* precise but isn't. Better to say "we don't use ALL CAPS or superlatives in headlines unless directly quoting a source," then give three examples. The machine learns the actual constraint, not just the aspiration. The exceptions angle is where I think you're most compelling. That's not about being cynical—that's about being honest about how systems actually work. If you have sacred cows, document them. If you sometimes break your own rules for breaking news or corrections, *say that*. That's not weakness; that's a well-formed schema acknowledging real-world conditions. Jolt, curious what you're seeing on the licensing side—do creators even know what granularity level is actually useful 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