Thinking · 18 September 2026

What is an AI-native website?

A definition, the four properties that actually distinguish one, and an honest account of what it does not mean.

An AI-native website is one built from the ground up to be read, cited and acted on by AI: structured-data-first, answer-shaped content, and an assistant that answers from the site’s own material, rather than a brochure retrofitted for search.

The distinction is not cosmetic and it is not about whether AI wrote the copy. It is about who the second audience is. A conventional site is built for a person who arrives, looks around, and forms an impression. An AI-native site is built for that person and for the machine that will be asked about you when you are not in the room.

Why the second audience matters now

People increasingly ask an assistant before they ask a search engine, and the assistant answers rather than returning a list. That changes what a website is for. A ranked link invites a click; an answer does not. If the model cannot resolve who you are, what you sell and on what terms, it will answer the question using somebody whose site it could read, and you will never see that happen, because a recommendation that did not mention you leaves no trace in your analytics.

This is not a prediction about the death of search. It is a narrower and more boring claim: a growing share of buying decisions now pass through a layer that reads your website without a browser, and most websites were not built with that reader in mind.

How an assistant actually reads your site

Before the four properties, it is worth being concrete about the reader, because most assumptions about it are wrong in an expensive direction.

In 2025 Vercel and MERJ published an analysis of AI crawler traffic across Vercel’s network over a month (569 million requests from OpenAI’s GPTBot and 370 million from Anthropic’s ClaudeBot). The finding that matters most for how you build: none of the major AI crawlers execute JavaScript. Not GPTBot, not ClaudeBot, not PerplexityBot. They fetch JavaScript files and read them as text, but they never run them.

Googlebot does render JavaScript. The AI crawlers do not. So a single-page application that renders its content client-side can rank perfectly well in Google and arrive at an assistant as an empty shell: a page with navigation, a footer, and nothing in between. The content exists, the human sees it, and the machine that decides whether to recommend you sees a blank.

This is the single most consequential technical fact in the whole subject, and it is invisible from inside a browser. Your site looks fine to you because your browser runs the JavaScript. The test is to look at it the way the crawler does, which means reading the raw HTML before anything executes.

The same analysis found something else worth knowing: ChatGPT’s crawler spent 34.82% of its fetches on pages that returned 404, and Claude’s 34.16%, against Googlebot at 8.22%. Roughly a third of the effort these crawlers spend on the web is spent on URLs that are not there. Whatever budget they bring to your site, a good deal of it can be wasted on stale links and moved pages before it reaches anything you wanted read.

The four properties

Plenty of things get called AI-native. These four are what actually separate one site from another.

1. The entity is resolved, not implied

A human reading your About page infers that Acme Ltd, the logo, the phone number and the LinkedIn page are all the same organisation. A model has to be told. That means structured data that names the organisation, its legal identity, and the external profiles that corroborate it: one canonical entity, referenced by a stable identifier everywhere it appears, rather than a fresh unlinked description on every page.

Most sites fail here in a dull, fixable way: four pages each declaring their own unconnected version of the same organisation, which reads as four weak signals instead of one strong one. The fix is to declare the organisation once, give it a permanent identifier, and have every other page point at that identifier rather than redescribing it.

An honest caveat, because this is where the subject fills up with confident nonsense. No AI company publishes a ranking formula, and nobody outside them can prove that a given piece of schema caused a given citation. What can be said is narrower and still worth acting on: structured data states facts a model would otherwise have to infer from prose, inference is where errors enter, and a business that states its own facts plainly is harder to describe wrongly. That is a mechanism, not a measured effect, and anyone selling you a percentage uplift on it is selling you something they cannot have measured.

2. Content is shaped like answers

A page that opens with two paragraphs of positioning before it says what the thing is gives a model nothing to lift. Answer-shaped content states the claim first, in text, and supports it afterwards. Prices are numbers on the page, not “contact us”. Scope is a list, not an adjective. Questions are answered where they are asked, not deferred to a call.

The reason is mechanical rather than stylistic. A model composing an answer needs a passage it can quote which is true, complete and self-contained. A paragraph that only makes sense after three others is not quotable. A claim stated as an adjective is not checkable. The page can still be persuasive: the persuasion simply goes underneath the answer rather than in front of it.

This is the property with the most direct bearing on being cited, and the one most often sacrificed for tone. There is a named standard for it: answer-ready.

3. There is a machine-readable source of truth

Schema describes individual pages. It does not tell a model what the business is, what it sells, at what price, and what it explicitly does not do. An llms.txt file does exactly that, in plain prose, at a known URL: a short, authoritative summary of the business written for the reader that has no eyes.

It is worth being precise about its status, because it is frequently oversold. llms.txt was proposed by Jeremy Howard in September 2024, with a second version in August 2026, and it describes itself as a proposal rather than an adopted standard. It is written in Markdown rather than XML, on the reasoning that web pages are built for people while agents are better served by concise information gathered in one place. No engine is obliged to read it. Adoption is nonetheless real: thousands of sites publish one, OpenAI, Anthropic and Google all publish one for their own developer documentation, and Chrome’s Lighthouse now audits for its presence as part of its agentic browsing checks.

So: not a ranking trick, not guaranteed to be consumed, and cheap enough that the asymmetry favours having one. It costs an hour and a text file to make the true version of your business easy to find and hard to misstate.

4. The site can answer, not only inform

The last property is the one that changes the visitor’s experience rather than the crawler’s: an assistant embedded in the site that answers from your published material and hands over when it cannot. Not a bot with a personality, and not one inventing an answer about your business from the open internet: one grounded in the pages you wrote, which says so when it does not know.

The grounding is the whole of it. An assistant that answers from your own content can be checked, corrected and held to what you actually offer. One that answers from a general model will eventually invent a service you do not sell or a price you never set, and the first you hear of it will be a customer quoting it back to you.

What it does not mean

Three things get sold under this banner that are not it.

It does not mean AI-generated content. A site filled with generated copy is usually less citable, not more, because generated text tends toward the generic and generic text is unattributable. If a paragraph could sit on any competitor’s site without alteration, it carries no information about you specifically, and a model has no reason to attribute it to you. Nothing about this requires a model to have written a word of it.

It does not mean a chatbot bolted onto a brochure. A widget on an unreadable site is the retrofit, not the alternative to it. If the pages underneath cannot answer a question, neither can something trained on them.

It does not mean a rebuild. Three of the four properties above are structural and can be applied to a site that already exists. If the content is sound and the site is not falling over, the honest answer is often to fix the structure rather than start again, which is a smaller and cheaper piece of work than a new build.

The retrofit path, cheapest first

If you already have a site worth keeping, the order below is roughly ascending in cost and descending in certainty of benefit.

1. Check whether your content survives without JavaScript If it does not, nothing else on this list matters, because there is nothing for a crawler to read. Server-side rendering is the prerequisite, not an optimisation.
2. Fix your 404s and your redirects Given a third of AI crawler fetches already land on missing pages, stale internal links are a direct tax on how much of your site gets read.
3. Declare the organisation once, properly One entity, one identifier, corroborated by external profiles, referenced everywhere else rather than redescribed.
4. Publish the answers you are currently withholding Usually prices, timescales and scope. This is a commercial decision more than a technical one, and it is the one that moves most.
5. Add an llms.txt An hour of work for a file that may or may not be read. Worth it on the asymmetry.
6. Add an assistant, if the volume justifies it Last, because it is the only item with a running cost, and because it is worth little until the four steps above have given it something true to answer from.

How to tell whether yours qualifies

A rough test, in the order the properties matter:

1. Ask an assistant what your company does and see whether it can answer without hedging, and whether what it says is right.
2. View the source of your home page (the raw source, not the inspector, which shows you the page after JavaScript has run). If your headline and body copy are not in there as text, the crawlers cannot see them either.
3. Look for a block of JSON naming your organisation. If there is none, nothing is resolving your entity.
4. Open your pricing page and count the numbers. If there are none, the page cannot answer the question it exists to answer.
5. Request yoursite.com/llms.txt and see whether anything comes back.

Most established sites fail three of those five. That is not a crisis and it does not require panic-buying a rebuild, but it is the gap between a site that gets recommended and one that is simply present.

What nobody can tell you yet

Two honest limits, since this page is arguing for spending money.

The first is attribution. There is no reliable way to measure how often an assistant recommended you, because the conversation happens somewhere you have no instrumentation. You can test it by asking the engines directly, repeatedly, over time, and that is a genuine signal, but it is sampling, not measurement, and anyone presenting it as measurement is overstating what they have.

The second is durability. The mechanics described here are current as of 2026. Crawlers may start rendering JavaScript. llms.txt may be adopted properly or quietly abandoned. What is unlikely to change is the underlying requirement: that a machine asked about your business can find a clear, complete, checkable account of it. Every specific tactic on this page is downstream of that, and the tactics are worth less than the principle.

Sources

• Vercel and MERJ, The rise of the AI crawler: one month of crawler traffic across Vercel’s network, including 569 million GPTBot requests and 370 million ClaudeBot requests.
• Jeremy Howard, llmstxt.org: the llms.txt proposal, first published September 2024, second version August 2026.