# LLMs.txt Setup: Check and Fix /llms.txt Fast *By The Strand CMS Team · 2026-07-20 · 9 min read* Canonical: https://www.strandcms.com/blog/does-your-site-have-llms-txt > **Summary:** LLMs.txt setup is simple: point machines at the pages that explain the site, keep the file short, and treat it as a helper, not a ranking trick. A good llms.txt setup starts with a small file and a clear reason for each link. The fastest way to check for `llms.txt` is to open `https://yourdomain.com/llms.txt` or run `curl -s https://yourdomain.com/llms.txt`. If the file exists, you should see a short index of pages, not a wall of marketing copy. This belongs in the same cluster as [best CMS for AI search](/blog/best-cms-for-ai-search-visibility). If you have to squint to understand what the file is for, it is probably too long. ## LLMs.txt setup: what it is for The proposal behind `llms.txt` is simple. Give LLMs a small, readable entry point to your site so they do not have to infer the shape of the whole thing from a giant homepage. The file is supposed to help at inference time, not replace the public page itself. It is also not a ranking hack. Google says `llms.txt` does not affect Search visibility. ## What to check 1. Does `/llms.txt` return a 200 response? 2. Does it list the pages you actually want machines to read? 3. Are those pages canonical and up to date? 4. Does `robots.txt` still allow crawlers to reach them? 5. Does the file stay short enough to be useful? If the answer to any of those is no, fix that first. ## What to put in it A useful `llms.txt` file is not long. It usually includes: - a short site description - the main docs or blog index - one or two key product pages - any pages that are especially useful to answer engines The point is guidance, not exhaustiveness. ## A few concrete examples A news site might list the homepage, the latest stories, and the editorial standards page. A documentation site might list the docs home, the API reference, and the getting-started guide. A product site might list the homepage, pricing, integrations, and one strong use case page. The common pattern is the same. Point the model toward the pages that best explain the site and let the rest of the site stay discoverable through normal crawling. ## What not to do Do not paste the entire site map into `llms.txt`. That turns a helpful index into another file nobody wants to maintain. Do not use the file as a substitute for crawlable HTML. If the page itself is broken, the helper file will not rescue it. Do not treat the file as proof that your SEO work is done. Google has already said it does not change Search visibility. ## Where Strand fits Strand keeps this simple by pairing a Git-native content model with a machine-readable surface. That is useful because the human process and the crawler surface stay close together. If the site already has a source-of-truth article like [Introducing Strand CMS](/blog/introducing-strand), `llms.txt` can point there instead of forcing a model to infer the structure from scratch. ## A quick fix path If your site does not have one yet, start with the pages that matter most: - the homepage - the main docs or blog hub - one or two high-value articles - a concise explanation of what the site is for Then keep the list small and boring. That is better than trying to make the file impressive. ## A complete rollout A good rollout is boring on purpose. Start with the pages that already do the best job explaining the site, then make sure the file points there and nowhere else. If you run a documentation site, that usually means the docs home and the getting-started page. If you run a product site, that usually means the homepage, pricing, and one or two pages that answer the most common questions. Once the file is live, treat it like a small control surface. If the homepage changes direction, update the description. If the docs get reorganized, update the links. If a page stops being useful, remove it. The file should reflect the site as it is now, not the version you wish it still was. ## A practical file shape A useful `llms.txt` file often has four parts: a one-sentence description of the site, a docs or blog hub, a small list of high-value pages, and links that help a model understand what to read next. That format keeps the file short and easier to maintain than a full sitemap dump. If your site changes often, build the file around pages that are stable and explanatory. A homepage, a docs index, a pricing page, and a few cornerstone posts usually do more for the model than twenty near-duplicates. ## How to audit it Open the file, read it as if you were an external assistant, and ask whether the path from the file to the page is obvious. Then check whether `robots.txt` still allows access and whether the canonical page is still the best entry point. If a page became stale, remove it rather than hoping the file will compensate. ## What to list first The pages that usually earn their place are the homepage, the docs or blog hub, a pricing page, and the single best explainer for what the site is. If the site is a publication, the editorial policy page is often more useful than a giant archive. If the site is a product, the integration or use-case page is often more useful than the marketing homepage alone. ## How to keep it honest Update the file whenever the site structure changes. If the page no longer reflects the current site, remove it. The value of `llms.txt` is that it stays short enough to inspect quickly. The moment it starts looking like a sitemap, it stops being useful. A good rollout is boring on purpose. Start with the pages that already do the best job explaining the site, then make sure the file points there and nowhere else. If you run a documentation site, that usually means the docs home and the getting-started page. If you run a product site, that usually means the homepage, pricing, and one or two pages that answer the most common questions. Once the file is live, treat it like a small control surface. If the homepage changes direction, update the description. If the docs get reorganized, update the links. If a page stops being useful, remove it. The file should reflect the site as it is now, not the version you wish it still was. ## What good looks like A good `llms.txt` file is short enough to scan in a few seconds and clear enough that a model can use it without guessing. It should not feel like a project in itself. It should feel like a map you could hand to someone and trust them to get moving. That is why Strand ships this kind of surface next to the content model. The source of truth and the helper file stay close together, so the maintenance cost stays low. ## A practical maintenance loop Check the file whenever the homepage changes, the docs tree gets reshaped, or the pages that matter most change their purpose. If a link stops earning its place, remove it. If a better source-of-truth page appears, swap it in. That sounds trivial. It is. But that trivial work is what keeps the file useful instead of decorative. ## A complete example A small software site might list the homepage, a getting-started guide, the main docs index, and the pricing page. A content site might list the homepage, the article hub, the editorial policy page, and one or two cornerstone posts. Those are the pages a model is most likely to need. The file should guide the model to the pages that explain the site in the fewest steps. It should not compete with the sitemap or duplicate every internal link on the site. ## Keep the list short A company home page, a docs hub, a pricing page, and one or two high-value product pages are often enough. If the file starts to look like an internal sitemap, it has gone too far. The better test is simple. If a new visitor or a model can use the file to find the pages that explain the site fastest, the file is doing its job. If it just mirrors the whole site, it is wasting space. ## Why brevity matters A useful `llms.txt` file makes the site easier to map without pretending to be something it is not. That matters because a model only gets a small budget of attention. If you spend that budget on a noisy index, you waste the part that should have pointed the model at your best pages. A short file also makes maintenance easier. You can tell at a glance whether the homepage changed, whether the docs index is stale, and whether a product page still belongs in the list. That is the kind of boring maintenance work that keeps the file honest over time. If the file starts to feel like a sitemap clone, trim it. The goal is to guide, not to impress. If you later introduce `llms-full.txt`, treat it as a separate surface with a separate maintenance cost. Start with the small index first, because the short file is the one that stays honest. The best test is whether a person unfamiliar with the site could use the file to find the most useful page in one hop. If not, the list is still too broad. A file that stays useful usually names the same few pages for the same reason every time: the site’s purpose, the most useful hub, and the page a new reader should open next. That consistency matters more than clever wording because the assistant reading the file needs a stable map, not a creative brief. If you are unsure whether a link belongs, ask whether it would still deserve a place if the site had to be explained in one minute. If the answer is yes, keep it. If the answer is only that the page exists, drop it. ## What crawler docs actually say OpenAI and Perplexity both publish crawler docs. Google publishes robots and AI guidance. The message across all of them is consistent: public pages need to be easy to fetch, easy to parse, and hard to misunderstand. `llms.txt` is one small way to help, but it only works if the pages behind it are already solid. ## FAQ ### Is llms.txt required? No. It is optional. ### Does Google use llms.txt for ranking? No. Google says it does not affect Search visibility. ### Should I add llms-full.txt too? Only if you have a reason. Start with the smaller index first. ## Sources - [The /llms.txt file](https://llmstxt.org/) - [Latest Google Search Documentation Updates](https://developers.google.com/search/updates) - [Overview of OpenAI Crawlers](https://developers.openai.com/api/docs/bots) - [Perplexity Crawlers](https://docs.perplexity.ai/docs/resources/perplexity-crawlers) - [How Google Interprets the robots.txt Specification](https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt) - [Strand CMS on GitHub](https://github.com/BowTiedSwan/strand) ## FAQ **What is llms.txt?** It is a proposed `/llms.txt` file that gives LLMs a small, readable index for a website at inference time. **Does llms.txt help Google rankings?** No. Google says it does not affect Search visibility. **Should I also keep robots.txt updated?** Yes. robots.txt still controls crawler access, so both files matter if you want bots to reach the right pages. ## Sources - [The /llms.txt file](https://llmstxt.org/) — llms-txt - [Latest Google Search Documentation Updates](https://developers.google.com/search/updates) — Google - [Overview of OpenAI Crawlers](https://developers.openai.com/api/docs/bots) — OpenAI - [Perplexity Crawlers](https://docs.perplexity.ai/docs/resources/perplexity-crawlers) — Perplexity - [How Google Interprets the robots.txt Specification](https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt) — Google - [Strand CMS on GitHub](https://github.com/BowTiedSwan/strand) — BowTiedSwan