What is llms.txt?

The problem it solves

AI assistants that answer questions about your business have to work from whatever they can parse quickly, and most websites do not make that easy. The facts that actually matter - what you do, who you serve, what makes you different, roughly what things cost - tend to be scattered across a homepage built for humans scanning visually, a services page written for search engines, and a pricing page that assumes context the reader already has. A model trying to summarise your business in a sentence has to reconstruct that picture from fragments, and it often gets it wrong, or leaves you out entirely because the picture never quite resolves. llms.txt solves this by putting the essential facts in one predictable place, in a format built for fast machine reading rather than persuasion. You are effectively pre-writing the summary you want an AI system to work from, instead of leaving that summary to inference across a hundred pages of marketing copy - it gives an assistant a reliable shortcut to the version of the truth you actually control.

What goes in the file

The emerging convention, set out in Jeremy Howard's original proposal, is deliberately plain: an H1 with your business name, a blockquote with a one or two sentence summary, then a handful of Markdown sections that link your key pages with a short description of each - services, pricing, contact, case studies. There is no schema to validate against and no required fields beyond the H1, which is part of the appeal: any business owner can write one in a text editor without special tooling. A fuller companion file, llms-full.txt, can carry expanded detail for systems that fetch more than the summary. Whichever version you publish, treat it as a claim you are making about your business rather than a copy-paste job. An llms.txt that states a price you no longer charge, or a service you no longer offer, is actively worse than not having the file at all, because it hands an AI assistant a confident wrong answer to repeat.

Who reads it today

Honestly: adoption is early, and no AI vendor has published a guarantee that they fetch or weight llms.txt in their answers. OpenAI, Anthropic and Perplexity have not confirmed it as a formal part of how their assistants gather context, and some practitioners in the SEO and AI-visibility community are openly sceptical, arguing that a model capable of reading your full site when it browses does not need a separate summary file at all. The counterargument, and the reason AuditHQ still recommends it, is that the file costs a matter of minutes to create, several AI crawlers do fetch it in practice when they visit a domain, and - separate from whether any individual crawler reads it - the discipline of writing one is valuable in itself. Deciding your canonical one-line description, your priority pages and your non-negotiable facts is an exercise that clarifies your AI visibility even in the scenario where the file goes unread. It is a low-cost bet with asymmetric upside, not a guaranteed win.

How to add one

Create a plain text file named llms.txt, write the Markdown summary described above, and have it served at your domain root - yourdomain.com/llms.txt - sitting alongside robots.txt and sitemap.xml. On most hosting platforms and site builders this is a one-file upload into the public or static directory; if you are on a framework like Next.js or a static site generator, it usually just needs to live in the public folder so it is served unmodified at build time. You can reference it with a short comment in robots.txt if you want to make it easy for automated tools to discover, though this is a courtesy rather than a requirement since the file lives at a predictable, well-known path already. AuditHQ does both on this site: the file is referenced from robots.txt and served live at audithq.com.au/llms.txt, so you can see a real, current example rather than a hypothetical template.

llms.txt is one signal among several

The file works alongside a set of related signals, not instead of them: structured data (schema.org markup that tells search and AI systems what type of entity you are and what properties it has), server-rendered content (so crawlers that do not execute JavaScript can actually read your page), explicit AI-crawler access in robots.txt (so GPTBot, ClaudeBot, PerplexityBot and similar are not accidentally blocked), and consistent entity signals across your Google Business Profile, LinkedIn and directory listings. AuditHQ's AI Visibility suite checks all of these together as part of a single audit, and llms.txt presence and quality is one check among many rather than the headline metric. That is the right way to weight it: a perfect llms.txt sitting on top of a JavaScript-only site that crawlers cannot read will not move the needle, while a well-structured, server-rendered site with consistent entity data will perform reasonably in AI answers even without one. Treat it as a genuinely useful finishing touch, not a shortcut around the underlying work.

Getting the content right, not just the format

The most common mistake businesses make when they finally sit down to write an llms.txt is copying marketing language straight out of their homepage hero section. Phrases written to feel aspirational to a human reader - built for the modern era, trusted by businesses everywhere - are exactly the kind of vague claim an AI summary should avoid, because they give a model nothing concrete to repeat back to a user who asked a specific question. Write it the way you would brief a new employee who has thirty seconds to learn what your business does: plain nouns, real locations, real service names, actual differentiators. If you are a licensed electrician in Geelong who does emergency callouts, say that - not that you deliver electrical solutions with a commitment to excellence. The file rewards specificity in the same way a good meta description or a well-written FAQ answer does, and for the same underlying reason: systems that summarise on your behalf can only be as precise as the source material you hand them.

Frequently asked questions