A growing share of the people evaluating your company never load your homepage. They ask an assistant, read a summary, and form a view before a human ever visits the site. That summary is assembled from whatever a machine could find, parse and trust about you.
We rebuilt 7unit.tech for that reader. Not by adding an AI page or a chatbot, but by making the site structurally legible: unambiguous about who we are, cheap to retrieve, and backed by evidence a machine can check.
Three findings from that work were not what we expected. Two of them changed how we now approach every client site.
Finding one: we cut the AI index in half and it got better
The current convention for making a site agent friendly is a file at /llms.txt. It sits at the root, describes the organisation in plain Markdown, and links to the detail.
Our first version was thorough. It ran to roughly 6.8 KB, with a paragraph of context under every capability, every market, every case study. It read well. It was also wrong.
An index is not a document. Every sentence we wrote into llms.txt was a sentence already living on a linked page, which meant we had created a second copy of our positioning that would drift away from the first the moment either changed. Worse, we had made the cheapest, most frequently retrieved file on the site into one of the most expensive to read.
We cut it to 3.4 KB. What came out: descriptions that were already available one hop away. What stayed: the discriminating facts, meaning capability names, the markets we work in, and evidence metadata such as industry, country and year.
The rule we now apply: llms.txt exists to identify, qualify and route. It should tell a machine who you are, whether you are relevant to the question being asked, and exactly where to go for detail. Nothing else belongs in it. Length is not authority.
Finding two: the cookie banner was our worst performing element
This one had nothing to do with AI, and it is the reason we now measure before we redesign.
Our mobile Largest Contentful Paint was sitting between 4.0 and 4.2 seconds. The obvious suspect was the hero animation. Everyone assumed it. We were a week away from redesigning the top of the site.
Measurement said otherwise. The hero was already present in the server rendered HTML and painted early. The problem was the cookie consent paragraph. It was physically larger than the H1, and it only appeared after React hydration, so it arrived late and took over as the final LCP candidate. The page was not slow to paint. It was slow to finish deciding what the largest painted thing was.
We changed the architecture so consent visibility is determined before first paint, while keeping the normal React provider as the authority for storing and applying consent. Mobile LCP moved to between 2.1 and 2.3 seconds, with performance scores around 96 to 97 in the measured runs.
There is a subtlety worth naming, because it is where this fix usually goes wrong. Once a consent banner is visible before hydration, its buttons are visible too, and for a short window they do nothing. A user clicks Accept, sees no response, and clicks again. We handled it with a small pre-hydration bridge that captures intent only, and hands that intent to the real consent provider once React is ready.
The bootstrap layer must never become a second consent authority. It should not construct the final consent record, enable analytics, enable advertising, or duplicate provider logic. Privacy sensitive state fails closed, always. Getting a performance score up is not worth a consent bug.
The broader lesson: measure the actual LCP candidate and its timing before you change visible page design. The obvious suspect is often innocent, and in our case redesigning the hero would have cost weeks and fixed nothing.
Finding three: the ceiling is evidence, not markup
You can do every technical thing correctly and still be useless to a machine, because the hard question is never "what does this company claim". It is "what supports the claim".
Most B2B sites fail here in the same way. They list capabilities. Fintech. AI. Healthcare. Enterprise integration. Then they stop. A capability list is an assertion, and an assertion is the one thing a careful reader, human or machine, discounts.
So we built retrieval trails instead. Each capability points to a piece of evidence, and each piece of evidence carries the metadata that lets a machine confirm relevance: what it was, which industry, which country, which year, and a link to the detail.
Fintech engineering leads to a lending platform in Italy in 2026. UAE and WhatsApp leads to a specific CRM build. Compliance leads to the compliance work we have actually shipped. If a capability had no evidence behind it, we had two honest options: link to the proof, or remove the claim. We removed several.
That was the uncomfortable part of the project, and the most useful. Optimising a site for machine readers is mostly an exercise in deleting things you cannot support.
What we would do first
If you are starting this work, resist the temptation to begin with the novel parts. The layers that matter most are the boring ones, and no amount of work on llms.txt compensates for a broken one.
In order:
- Get the fundamentals right. Correct canonicals, a sitemap with no 404s, an intentional
robots.txt, semantic and server readable HTML. - Define the organisation once, in JSON-LD, with stable identifiers, and reference that single definition everywhere rather than embedding slightly different versions of yourself across pages.
- Publish a concise
/llms.txtthat identifies, qualifies and routes. - Add clean Markdown alternatives for your high value pages, generated from the same content source as the HTML, not maintained by hand alongside it.
- Link every capability to evidence, or delete the capability.
Then run the test that tells you whether any of it worked. Give an agent only your /llms.txt as its starting context and ask it who you are, what you do, where you operate, what evidence supports your capabilities, and which resources it should retrieve to verify those claims. Let it fetch the linked resources. Then ask the specific questions a buyer would ask.
Wherever the agent hedges, invents or asks for clarification, you have found the exact gap in your content. That is the whole loop. Fix it, republish, ask again.
The principle underneath all of it
Do not optimise a website to tell AI engines that your company is important. Optimise it so agents can determine precisely who you are, retrieve the right information cheaply, and find evidence for what you claim.
The pleasant side effect is that a site built this way is also clearer to the human buyer who eventually does load your homepage. That overlap is the reason this work is worth doing even if answer engines never send you a single visitor.
We have written the full method up as a free technical guideline. It covers the discovery stack, llms.txt structure, Markdown alternatives, the JSON-LD entity graph, canonicalisation, routing hygiene, the rendering traps described above, and a validation checklist you can run against any site, including one you did not build.
AI Discovery and AEO Implementation Guideline
If you would rather have it run against your own site, or want a second opinion on an audit you have already done, write to dipin.krishnan@7unit.tech.