# What is already built in, while others are still debating > Measured, not claimed: how rarely machine-readable findability is actually delivered — and why retrofitted solutions age while built-in ones do not. There is a kind of conversation I have been having for eighteen months, and it always runs the same way. Someone asks whether they now have to “do something for AI as well”. Then comes a list of acronyms, then an assessment of which of them is a fad, and at the end a sentence like: “We'll watch it for now.” I understand that. Watching is the sensible response to hype. Only the question is now being asked wrongly. The question is not **whether** something has to be done. The question is **where the knowledge of it sits**. Because the knowledge has long been public: how a machine reads a website, how it separates facts from running text, which files it fetches first — that is in documentation, studies and blog posts, including ours. What is missing is not knowledge. What is missing is the build. And that is a difference you can measure. That is what this piece is about. ## What I am not explaining again here. So the text does not say the same thing a third time, four pointers up front: - What GEO, AEO and LLMO mean, and whether you really need five new acronyms, is in [GEO, AEO, LLMO](https://btlabs.dev/en/posts/geo-aeo-llmo-do-you-need-five-acronyms). It is not repeated here. - How to **measure** AI visibility, when position one on Google no longer guarantees anything, is in [What you measure when position one is worth nothing](https://btlabs.dev/en/posts/what-you-measure-when-position-one-is-worth-nothing). - What the technical architecture of a machine-readable website looks like is in [From SEO to GEO](https://btlabs.dev/en/posts/from-seo-to-geo-architecture). - And that a business can rank first on Google and still be absent from an AI answer is the problem set out in [First on Google, invisible in ChatGPT](https://btlabs.dev/en/posts/first-on-google-invisible-in-chatgpt). This piece is an attempt at an answer to that. Not what one ought to know — but how much of it is actually being delivered today, and what that says about the gap between talking and building. ## The measurement I am relying on. Since mid-2026 we have been measuring monthly how widespread the building blocks of machine-readable findability really are. Not by survey, but by request: a fixed panel of domains is examined, always the same sample, always the same checks, and the results are published. As of September 2026, panel 853 domains. Three figures from it matter here: - **86.2%** of domains serve a robots.txt. That is the classic, established since the nineties — the file that tells search engines what they may look at. - **13.5%** serve an llms.txt. That is the young file that tells a language model, in short form, what this domain is about and which pages are the important ones. - **0.0%** serve a machine-readable catalogue of what the business offers and what an agent can do with it. That last figure is not a rounding down. It is the observation that something widely written about barely exists in practice. And one more value tells the same story from another side: **16** domains in the panel serve **not a single one** of the blocks we check. No declaration, no summary, no catalogue, nothing. Not because bad work was done there — but because it was nobody's job. ⚠ Every figure carries a date and is collected afresh each month. They describe what is being delivered **today** and predict nothing about what will be normal in a year. ## Why the gap between knowing and building is so wide. The obvious explanation would be ignorance. I think that is wrong. The people who build websites read the same articles I do. The real cause is more mundane, and I see it in every second project: **these things are nobody's remit.** A website is created as design plus copy plus engineering, with a delivery date. What comes after arrives as an additional job — and an additional job needs an occasion, a budget and somebody to commission it. For “a file that explains to language models what this place is about”, that occasion rarely arises. There is a second, more uncomfortable pattern. These blocks are not hard to build, but they are hard to **keep current**. A hand-written summary of your own website is correct on the day it is published and wrong six months later. A fact markup written once into a page template stays put when the facts change. I have seen sites that serve 2023 opening hours in machine-readable form while the visible text has the right ones. To a person the site is fine. To a machine it is false — and the machine believes the marked-up value. **Retrofitted machine readability ages.** That is the core of the problem, and it is why commissioning it once helps little. ## What “built in” actually means. The alternative is unspectacular: these outputs are not maintained, they are **generated** — from the same data the visible page comes from. If the foundation holds what the business is called, what it does, where it does it, when it can be reached and what the services are, then the following arise from it without further work: - the **fact markup** in every page, the part search engines read; - a **machine-readable summary** of the business in the form of facts; - a **summary of the website** for language models, with the pages that actually matter; - a **catalogue** of what is on offer; - the **full-text output** of the content in a form a machine can cleanly split; - and the **declaration** of who may use what, and what expressly not. Altogether that is 34 output routes a domain can provide for machines — and in the panel they almost never appear together. The practical difference shows up not on setup day, but the first time something changes. A business changes its opening hours. In one world it changes them in the text, and everything machine-readable stays as it was until somebody remembers. In the other it changes them once, and every output changes with it — because they were never copies, but views of the same source. That is not a product feature to marvel at. It is only the difference between something that has to be maintained and something that is correct. ## Three objections that come up in every second conversation. I take them seriously, because they are fair — and because the answers show what this is really about. **“Our customers don't ask an AI, they phone.”** Often true, and for some trades it will stay true for a long time. But the question is not whether your customer asks an AI; it is whether anyone on the way to you does: the son searching on behalf of his parents. The assistant collecting three quotes. The search engine itself, which now puts an answer in front of the results list. The phone call at the end proves nothing about how the decision before it was made. **“It's all still immature anyway.”** Also right. The formats are changing, and some of them will be called something else in two years. But that is an argument **for** building it in and against handwork: what is generated from one source can be switched to a new format without touching content. What was written by hand has to be rewritten by hand. Retrofitting manually today buys tomorrow's conversion cost along with it. **“If it mattered that much, everyone would be doing it.”** That is the objection I have the clearest answer to, and it is above: they are not. Of 853 measured domains, 13.5% serve a summary for language models, 0.0% a machine-readable catalogue, and 16 domains serve none of it. Whether that becomes an advantage is not decided by how widespread it is — but “everyone does it” is, in any case, not available as an argument. ## What the difference costs in practice. A worked example, deliberately without invented statistics — anyone can redo it for their own business. A trades business changes perhaps a dozen things a year that matter to the outside world: opening hours over the holidays, a new service, a colleague with a new responsibility, a phone number, a second location, the winter emergency service. In the retrofitted world, several places hang off each of those changes: the visible page, the fact markup, the summary for language models, the trade directory, the map profile. Five places, twelve changes — that is sixty small acts a year, none of which anyone notices as long as they are skipped. Which is exactly why they get skipped. And every skipped one leaves behind a statement that contradicts. In the built-in world it is twelve. Not because anyone is more disciplined, but because the other forty-eight do not exist. The damage from those forty-eight is not spectacular — nothing collapses. It is the customer standing at a locked door at the wrong hour. The enquiry for a service that no longer exists. The recommendation that goes to the business in the next village, because its details were less ambiguous. Small things nobody traces back to a cause. ## Why I think this is the actual positioning. It took me a long time to put this point cleanly, and I am putting it this plainly for the first time: the competitive advantage is not in knowing about AI visibility. That knowledge is freely available, and anyone selling it is selling something you can read up on. The advantage is that **having it costs nothing**. Not in money, but in attention: nobody has to think of it. Nobody has to update a file. Nobody has to know what an llms.txt is in order to serve one. It is also why I no longer have the “do we need this yet?” debate. It assumes the decision costs effort. If the build sits in the foundation, the decision costs nothing — it was already made when the foundation was chosen. Why the term “web agency” has become too narrow for this kind of work I described in [Why “web agency” is too narrow](https://btlabs.dev/en/posts/why-web-agency-is-too-narrow). ## What I am expressly not claiming. I have made a habit of writing this section, because it keeps me honest: - **I am not claiming these files improve rankings.** There is no solid evidence for that, and anyone promising some is inventing it. What they do is raise the chance that a machine finds the right details instead of forming its own. - **I am not claiming that low adoption proves value.** Being rare does not make something valuable. It only makes it a difference — and whether that difference pays is decided not by adoption, but by use in the systems that give answers. - **I am not claiming we invented this.** The formats are open, the standards public, anyone can serve them. Our contribution is that with us they arise by themselves and stay current. - **And I am not claiming it is sufficient.** A machine-readable business without substance is a well-signposted empty shop. ## What would tell me I am wrong. Three things would change my mind. **First**, if the adoption figures jumped without anything changing in usage. If in a year half the panel serves these files because a large website builder switches them on by default, then it was never a difference, only a default. We have already seen one case like that and marked it as such in our analyses — a figure that comes from a platform default says nothing about intent. **Second**, if the systems that give answers demonstrably ignored these details and fell back on running text alone. Then the whole chain would be effort without effect. **Third**, if maintained handwork turned out to stay more accurate over years than generated output. That would contradict everything I have seen in twenty years, but it would be an argument. Until then this holds for me: the measurement says almost nobody delivers what almost everybody talks about. That is not a sales argument, it is an observation — and it is the most honest reason I have for the way we build. ## What you can check yourself, in ten minutes. No tools, no consultant, on your own domain: 1. **Open your-domain.tld/robots.txt.** Does anything come back? Does it say anything about AI systems, or only about search engines? 2. **Open your-domain.tld/llms.txt.** If you get an error page, you are in the majority. 3. **Look at the fact markup of an inner page** — in the source, or with one of the search providers' free testing tools. Do the opening hours there match the ones in the visible text? That is the check that fails most often. 4. **And the decisive question:** if a detail changes tomorrow, how many places do you have to touch? If the answer is more than one, one of them will eventually go stale. Not perhaps — certainly. ## To close. I did not write this to say we do it better. I wrote it because the debate is being held in the wrong place. Whether AI visibility becomes important is no longer an interesting question — the answer is in every usage report. The interesting question is whether what is known about it ends up, inside your own business, somewhere it takes effect, and whether it will still be right there in two years. Everything else is watching. And you can watch just as well while it is already built in. ## Sources and date. All adoption figures come from our own monthly measurement, as of September 2026, panel 853 domains; method and raw data are published with each edition. The values change monthly; this article shows the current state automatically. --- Source: https://btlabs.dev/en/posts/what-is-already-built-in Last-Modified: 2026-09-18T07:00:01.835Z Languages: [de](https://btlabs.dev/llms/de/posts/was-heute-schon-eingebaut-ist) · [it](https://btlabs.dev/llms/it/posts/cio-che-e-gia-integrato) See also: [llms.txt](https://btlabs.dev/llms.txt) · [ai.txt (Policy)](https://btlabs.dev/ai.txt) · [identity.json](https://btlabs.dev/identity.json)