When AI builds the interface, what does your website become?

Before AI can present your information, it has to retrieve it

First, the mechanics, because they explain everything that follows. A generated interface sits at the end of a retrieval process: before an assistant can show your product in a comparison, it has to find your page, fetch it, and pull out the parts it can use.

The details vary by product, but several things generally have to happen:

1. Discovery: a system identifies a relevant source, through search, links, an index, or a supplied URL.
2. Retrieval: it accesses information from a live page or an existing index.
3. Extraction: content is parsed, selected, converted, or filtered into material the model can use.
4. Composition: the model uses that material, alongside other context and sources, to construct the answer and its interface.

These are different jobs, sometimes performed by different systems. OpenAI, for example, distinguishes its search crawler, OAI-SearchBot, from ChatGPT-User, which visits pages for certain user-initiated actions. GPTBot serves a separate training purpose. (OpenAI’s crawler documentation)

Extraction also varies. Anthropic’s API web-fetch tool supports filtering retrieved material before it enters the model’s context. A page being fetched therefore does not mean every part of it reaches the model. (Anthropic’s web-fetch documentation)

This matters when your product appears in a generated comparison. A qualification missing from the retrieved material may disappear from the comparison too. The system might recover it elsewhere, but your carefully designed page does not guarantee that it will.

The quality of the experience depends partly on what survives that journey.

What we found when we looked at the source

So what does an assistant actually receive when it fetches a typical company page?

On October 20, 2026, we fetched several Genymotion pages using the ChatGPT-User user agent, without executing JavaScript. We compared the HTML source size with the body text extractable from it.

These are source-size measurements, rather than token counts or compressed network-transfer sizes. The pricing Q&A also contains structured data that is excluded from the body-text column.

The main homepage contains about 1.8% body text by this measure. That does not mean the remaining bytes are useless: markup, scripts, and styles serve the browser experience. Nor does it mean an extractor loses 98% of the information.

It does show how much machinery surrounds the information.

The AI homepage provides a similar order of magnitude of text in roughly one-sixteenth of the HTML source size. The pricing Q&A makes a narrower answer available as a small, self-contained document.

Another client’s site illustrated a more fundamental problem. Measured the same day, its initial HTML (5.7 KB) contained metadata and an empty application root, with no body text. The content appeared only after JavaScript ran.

Whether that content is accessible then depends on the retrieval system. Rendering capabilities vary, so “AI crawlers never run JavaScript” is too broad a rule. Our own logs show the range: over five weeks, ClaudeBot, PerplexityBot and Bingbot ran the JavaScript on client pages, while we saw no sign of OpenAI’s crawlers doing so. The practical question is whether your important information is available through the retrieval paths your audience’s assistants actually use.

Providing it directly in the server response removes one dependency.

Agents ask different questions of your website

Second question: what do assistants come looking for? The content they retrieve tells us what these systems need.

In a 21-day study of the Genymotion AI site, ChatGPT-User and Claude-User made 1,517 content fetches. The top 50 URLs, about 6% of the content corpus, received 78% of those fetches.

Pricing, system requirements, compatibility, and product comparisons were among the prominent subjects. (Rozz’s analysis of content requests)

Those are useful ingredients for a buying decision. They are also the ingredients a generated interface needs to create a plan comparison, compatibility matrix, or feature checklist.

This suggests a different way to organize information.

A marketing website might distribute an answer across a product page, pricing page, documentation section, and FAQ. A useful source for an assistant can bring the relevant facts together: which product, which price, which requirements, which exceptions.

For example, a price becomes more useful when it travels with its billing period, usage limits, and applicable product. A compatibility statement needs the version and environment it refers to. A sentence extracted from its original page should still make sense.

Information density matters. So does preserving the context that makes a fact accurate.

An AI site is an editorial task as well as a technical one

This is why we think an AI site deserves to be treated as a distinct publishing format.

Removing scripts and styles can make a page lighter. It does not resolve ambiguous product names, missing limitations, scattered answers, or outdated claims.

At Rozz, we create AI sites alongside companies’ existing websites, on their own domains. The aim is to organize their information for retrieval and extraction: clear topics, self-contained answers, explicit comparisons, and links to supporting material.

A well-structured conventional website can already do much of this. The reason to create a dedicated AI site is to make those requirements an explicit publishing responsibility, with a format that can evolve around what agents actually request.

The human website continues to serve people arriving directly. Its visual storytelling, navigation, and pacing still have a purpose.

The AI site serves another route to those people: through a system assembling an answer on their behalf.

That is where this becomes larger than optimizing for a citation. The source material may help determine how a business is described, which limitations appear, and whether its product fits the user’s situation.

The files are useful only if systems use them

Third: what about the special AI files everyone recommends? Publishing an AI-oriented format does not guarantee that anyone uses it.

We publish llms.txt files and JSON feeds, and we measured their use. In a 90-day dataset of 461,328 logged requests across our production AI sites, those files together accounted for just under 1% of requests. HTML pages accounted for 55.2%, and sitemaps for 20.4%. (Rozz’s discovery-file study)

Request volume is not a measure of influence. A file fetched once could still be useful, and these observations concern our sites rather than the whole web.

But the findings challenge the idea that adding a special file is enough. The ordinary pages remain central to what systems retrieve.

Our immediate priority is therefore content that works through existing mechanisms: accessible HTML, clear links, useful sitemaps, and information organized so it can be extracted without losing its meaning.

We also need to be precise about what our observations establish. Requests show that systems retrieve the material. They do not, by themselves, establish how much it improves an answer or influences a purchase.

The website’s most important version may change

Today, a website combines information with a particular presentation of that information.

Generated interfaces make it possible to separate those jobs. A company publishes the source material; an assistant combines it with other sources and presents it according to the user’s needs.

As those experiences improve, I expect more people to encounter businesses this way. They will still use the web’s information, while spending less of the journey inside each company’s chosen layout.

In that environment, the AI site could become the most consequential version of a company’s web presence: the version that supplies the facts behind an experience generated elsewhere.

That is where we see things going at Rozz.

It gives website owners something concrete to work on now. Inspect what a fetcher receives. Identify the questions that matter to prospective customers. Publish complete answers with their qualifications intact. Keep them current, and measure what systems actually retrieve.

The interface may be generated in the moment. The information behind it needs preparation.

How does a brand survive inside a generated experience?

Fourth, and still open: what do AI sites need beyond facts? That’s a question for brands and the agencies that shape them.

If an assistant chooses the layout and interaction, how does a company’s identity travel with its information?

A brand has a voice, a visual identity, values, and a feeling it wants an experience to create. Some of those attributes also help people choose: a preference for simplicity, a service philosophy, or a commitment supported by evidence.

One starting point could be a dedicated file among an AI site’s discovery files, something like an AGENTS.md for brand guidance. Related experiments already exist, including design guidance for website-building agents. The next question is how that guidance could reach independent systems presenting a business to potential customers.

Our own discovery-file findings provide a useful constraint: publishing guidance is only the beginning. Systems must discover it, interpret it, and decide how to use it.

Could this become a new kind of CSS for the AI-mediated web, carrying both visual identity and what a brand stands for? How should it interact with the user’s preferences, or with other brands appearing in the same answer?

Those are questions we want to explore with web agencies. Making information accessible to AI is the immediate job. Helping brands express themselves inside generated experiences may be the next.

Sources

• OpenAI, Intelligent UI announcement
• Google Research, Generative UI
• OpenAI, Overview of OpenAI crawlers
• Anthropic, Web fetch tool
• Luke Wroblewski, Design systems for AI agents
• Rozz Insights #14, What AI bots read, what they ignore
• Rozz Insights #15, Who actually reads your llms.txt?