llms.txt: The 20-Minute Job That Makes AI Assistants Notice You
What llms.txt is, what belongs in it, where it lives by framework, and how yeet detects a citation gap, ships the fix, and verifies it landed.
llms.txt is a small, Markdown-formatted file that sits at your site's root and tells AI assistants and answer engines what you actually have — which pages matter, what they cover, and how they're organized. It isn't a ranking file like robots.txt, and it isn't a technical requirement anywhere yet. It's an emerging convention: a growing number of sites publish one, a growing number of crawlers and assistants read it when they find it, and it costs you about twenty minutes to do properly. That ratio is why it's worth doing even though nobody can promise you exactly what it does for any specific AI answer.
What actually goes in it
A useful llms.txt isn't your full sitemap. It's a curated, human-readable index: a short description of your product at the top, then your indexed pages grouped by type — docs, blog, product — each with a one-line description. The point is to give an assistant enough context to judge whether your page answers the question it's working on, without fetching and parsing every page on your domain first.
A reasonable shape:
- Site name and a two-sentence description of what you do
- A "Docs" section listing key documentation pages with short descriptions
- A "Blog" or "Guides" section listing your best evergreen content
- A "Product" section for pricing, features, or comparison pages
Keep the descriptions specific. "Pricing plans and what's included in each" tells an assistant more than "Learn more about our pricing" ever will.
Where it lives
Convention places llms.txt at your domain root — yoursite.com/llms.txt — the same idea as robots.txt or sitemap.xml. Where that maps to in your codebase depends on your framework: for Next.js and most React frameworks it's a static file under public/; for Hugo, Jekyll, and several static-site generators it's under static/, which gets copied to the site root at build time. If you're not sure, the test is simple — whichever directory already serves your favicon or robots.txt at the root is the same directory llms.txt belongs in.
How yeet notices you're missing
yeet doesn't treat "no llms.txt" as an automatic problem on its own — plenty of sites do fine without one, and the file alone isn't what gets you cited. What yeet actually watches is a downstream signal: your citation checks. yeet runs Perplexity-based citation checks roughly every eight hours as part of its AI-visibility watchers, alongside LLM-mention probes covering ChatGPT-style and Google AI Overview prompts, GA4 referral traffic from AI sources (chatgpt.com, perplexity.ai, claude.ai, gemini.google.com, copilot, and similar), and prompt-rank tracking roughly every twelve hours.
If those checks come back with zero citations two checks in a row, that's the trigger. At that point yeet looks at whether a missing or thin llms.txt is one of the plausible gaps and, if your fix types and autonomy mode allow it, drafts — and for eligible autonomy modes, opens — a PR that adds one.
yeet can ship it as a PR
llms_txt is one of the fix types yeet can auto-apply as a pull request against your connected GitHub repo, alongside meta_tags, schema_markup, technical_seo, and cannibalization fixes. Depending on your autonomy mode: on propose_only you get a card with a ready-to-apply file and merge it yourself; on auto_apply_safe or auto_apply_aggressive, if yeet's confidence on the fix clears the mode's threshold, the PR opens without you asking. Either way, opening the PR costs one auto-apply-PR credit — see the credits guide for what that means for your monthly budget.
After it ships: verify, then watch
Adding the file isn't the finish line, and yeet doesn't treat it as one. Once the PR merges, yeet re-checks that llms.txt is actually live at your domain root — a PR that never got deployed, or a build config that dropped the file, doesn't help anyone. Once the file is confirmed live, the card moves into yeet's normal review cycle (see how yeet verifies fixes for the full lifecycle), and the citation watchers keep running on their normal roughly-eight-hour cadence. If citations start showing up where there were none, that counts as a verification signal alongside the usual Search Console metrics. If nothing changes, the card doesn't get marked verified — it sits as applied-but-unconfirmed, which is an honest state to be in, given how little anyone outside the AI labs actually knows about how these systems choose what to cite.
Should you just do this manually today
Nothing stops you from writing llms.txt by hand this afternoon — for a site with a normal amount of content it genuinely is a twenty-minute job. The advantage of letting yeet handle it is less about the file itself and more about the loop around it: detection when you fall off AI answers, a PR instead of a manual edit, and a verification check afterward instead of "we did this once in 2026 and never looked again." For the separate problem of getting into Google's index in the first place, see get indexed on Google fast.
Quick FAQ
Does having llms.txt guarantee AI assistants will cite me? No. It's a convention, not a ranking signal with a guaranteed effect, and no tool can promise a specific citation outcome. It's a low-cost, plausible piece of a much larger visibility picture.
What if I already have an llms.txt but I'm still getting zero citations? yeet's citation checks don't stop at "file exists." If citations stay flat, the card won't verify, and yeet keeps watching rather than assuming the job is done.
Does it cost credits if I write the file myself instead of letting yeet PR it? No. Writing it yourself outside yeet costs nothing — credits are only spent when yeet performs an action: a check, an investigation, or an auto-apply PR.