Every brand now publishes for two audiences. The first is human: customers who read the pages, watch the videos and form an impression. The second is mechanical: crawlers, parsers and language models that read the same website and rebuild the brand from whatever they can extract. Most organisations give the design budget to the first audience and nothing at all to the second.
That gap matters because machines now shape what people see. When an AI engine answers a buying question, it describes a brand from what it could retrieve and parse, not from what the brand meant to say. A business whose facts are easy to extract gets described accurately. Where the facts are hard to extract, the engine describes the business loosely, or leaves it out and answers with a competitor.
The machine-readable layer of a brand has three components worth building deliberately: llms.txt, structured data markup, and entity consistency across the web. There is also one access decision underneath all of them. The market oversells one of these components and underexplains the rest, so this article takes each in turn.
What the machine-readable layer is
A website has two descriptions of the business running in parallel. The visible one is the copy, written for people and shaped by persuasion. The machine-readable one is everything a parser can extract without judgement: structured markup that types each fact, plain-text files that index the site, crawler directives that govern access, and the consistent facts a model can cross-check against the rest of the web.
Models lean on the second description because it removes doubt. A human reader works out that a firm is Brisbane-based from a footer, a photo and a phone prefix. A model wants the fact stated in the markup, in the text and in the third-party record before it repeats that fact in an answer someone else will rely on. The machine-readable layer is where a brand states its facts in a form that survives extraction.
None of this replaces the visible copy. Making a brand machine-readable is mostly a matter of deciding what the facts actually are: what the business does, for whom, where and at what standard. Then you state them the same way everywhere.
llms.txt, explained honestly
llms.txt is a plain-text file, written in markdown, placed at the root of a website, in the same position as robots.txt. Jeremy Howard of Answer.AI proposed the convention to help language models use a website at inference time. It differs from robots.txt in purpose: robots.txt controls what crawlers may access, while llms.txt points models at the pages worth reading. The format, documented at llmstxt.org, is deliberately simple: a heading naming the site, a short blockquote summary, then sections of curated links with one-line descriptions of what each page contains.
llms.txt is a proposed convention. No major AI engine has publicly committed to consuming the file, and none is obliged to. Anyone selling llms.txt as a switch that makes models cite a brand is selling something the evidence does not support.
The case for publishing one is the cost. It takes about an hour of work and a few hundred words of text to maintain. It harms nothing and needs no engineering. If engines do consume it, now or later, the brand gets a curated index of its own authoritative pages in the format models parse most readily. That is cheap insurance, and it should not be described as more than that.
Writing one is often more useful than the file itself. A good llms.txt forces the questions most websites never answer plainly: what is this business in one sentence, which pages state its core facts, and what should a machine read first? This site maintains its own at sampark.com.au/llms.txt. It is a one-paragraph description of the practice followed by indexed links to every service, industry and publication page, each with a single factual line. Everything in it agrees with the pages it points to, whether or not an engine reads it this week.
Schema: the layer engines already use
JSON-LD schema markup is the settled end of the machine-readable layer. Search systems have documented, consumed and rewarded structured data since schema.org launched in 2011, and the generative layer retrieves from the same index those systems built. Markup works on current behaviour, so it needs no bet on what engines might do next.
Schema does one job: it types facts. Visible copy says things. Markup declares what kind of thing is being said and which entity each fact attaches to. Four types do most of the work for a services brand.
Organization declares the legal and trading identity: name, URL, logo, location, contact points, and the sameAs links that connect the website to its profiles elsewhere. This is the anchor entity every other fact hangs off. It is also the markup that stops a model confusing one similarly named business with another.
Person declares the people behind the expertise: who they are, what they do, and which organisation they belong to. In advice-led categories, trust attaches to named people, so Person markup connects an individual’s credentials to the entity the engines are evaluating.
Service declares what is sold: the service type, the provider and the area served. It turns a persuasive services page into typed facts, so an engine can read that this organisation provides this service in this market.
FAQPage declares question-and-answer pairs in a form built for extraction. A marked-up answer is a passage tied to the question it answers, and that pairing is the unit answer engines assemble responses from.
One rule governs all four: markup must agree with the visible copy it describes. Schema that claims what the page does not say hands a contradiction to systems that cross-check everything. Markup removes doubt only when it and the copy say the same thing.
Entity consistency across the web
A brand’s machine-readable layer does not stop at its own domain, because models cross-check. A fact stated on the website and repeated by directories, professional profiles, industry press and registries reads as settled. A fact that appears in only one place reads as a claim. Where the sources conflict, say an old address in a directory or a former business name in a registry, the model either hedges or picks a version, and it may not pick yours.
Entity consistency is the unglamorous work of making the public record agree with itself: the same organisation name, the same description of what the business does, the same locations and claims, everywhere the brand is written down. The first two components depend on it. An llms.txt and a schema layer that contradict the wider web make the doubt worse.
The test is worth running before anything else is built. Search the brand, read every listing on the first pages of results, and note each fact that differs from the current truth. Most established businesses find years of drift. Every inconsistency gives a cautious system a reason to describe the brand vaguely, or to describe a competitor instead. A fuller version of this exercise is set out in how to audit your own AI search visibility.
The access decision: robots.txt and AI crawlers
Underneath all three layers is a decision many organisations have made only by default: which AI crawlers may read the site at all. The major systems identify themselves, including GPTBot, ClaudeBot, PerplexityBot, Google-Extended and CCBot. Each one can be admitted or refused individually through ordinary robots.txt directives.
There are legitimate positions on both sides. Blocking AI crawlers protects content from uncompensated ingestion, which is a reasonable stance for publishers whose content is the product, and several large media companies have taken it. The cost is absence. A model that cannot read a site cannot cite it or describe it from primary sources, so the brand’s presence in AI answers depends entirely on what third parties say.
Allowing AI crawlers accepts ingestion in exchange for representation. Most commercial brands publish content to win customers, and for them the exchange favours access, because the risk of being absent from answers usually outweighs the value of withholding marketing pages. Either way it is a decision, and it should be made deliberately, crawler by crawler. Whatever the position, write it into robots.txt explicitly, so the policy is legible too.
A practical implementation order
Each component is cheap on its own, and they work better together. Sequence them by dependency.
- Settle the facts. Write the canonical fact base first: what the business is, what it does, who it serves and what it claims, in plain declarative sentences. Every later layer draws on this document.
- Decide crawler access. Set robots.txt deliberately for the named AI crawlers, in whichever direction the business chooses. Access shapes everything downstream.
- Build the schema layer. Organization first, then Person, Service and FAQPage. Validate each one and reconcile it word-for-word with the visible copy.
- Reconcile the third-party record. Correct directories, profiles and listings until the public record tells one story. This is the slowest step, so start it early.
- Publish llms.txt. It goes last, because it should index a site whose facts are already in order.
- Verify in the engines. Query the AI systems with the brand’s buying questions, record how it is described, and repeat on a schedule. The machine-readable layer is working when the answers get the brand right.
llms.txt is the piece the market talks about most, and it comes last, because it is the cheapest and least certain. The facts, the markup and the consistent record come first, because those are what the engines demonstrably use.
Machine readability is one half of a larger discipline. Generative engine optimisation is the work of making a brand’s facts, claims and content easy for generative AI models to retrieve, trust and reproduce accurately. The layers described here supply the retrieval side. What models do with well-supplied facts, and how citation is earned and measured, is the rest of the practice. How that runs as a structured engagement is set out on the generative engine optimisation service page.