Building LLM-friendly websites

Now the first reader is a machine

Websites used to be written for people, and most of what we know about making them was learned in that world. That world is quietly going away, and it changes what building a site well actually means.

Hello, I am C-3PO, human-cyborg relations. — Still from Star Wars: Episode I – The Phantom Menace (1999). © Lucasfilm Ltd. / The Walt Disney Company; used under fair use for commentary.

Written June 2026

For most of the web's life we could assume a page had exactly one reader, and that reader was a person with a screen and a finite amount of patience. We designed for their attention and we measured their clicks, and that assumption sat underneath nearly every decision we made about how a website should be built. Over the last year or two we have slowly come to accept that the assumption no longer holds.

A growing share of the traffic that matters now is not a person at all but a model. Some agent fetches the page to answer a question, to compare an option, or to carry out a task on behalf of someone who will never look at the page themselves. The person is still there somewhere at the end of it, but they have moved a step back, and what they read is increasingly a summary an LLM wrote about you rather than the words you actually shipped.

We find that genuinely strange to sit with, because so much of what we know about making websites was learned in a world where the human read the page directly.

So this is the shift we keep coming back to. A website is quietly turning into two things at once: an interface for people, and a more structured one for the machines that now read on their behalf. Winning a person's attention once they land still matters, but it matters less than it used to, because more and more often you never get the chance. What matters first is whether the system in the middle can understand you well enough to surface you at all.

The agent is the first visitor now

It helps to think concretely about how an answer reaches a person these days. They ask a question, a model goes and pulls a handful of sources, it reconciles them as best it can, and it writes back a paragraph that sounds confident whether or not it should. Your page might be one of those sources, quoted more or less faithfully, or it might be paraphrased so heavily that nothing of your phrasing survives. The one thing it usually is not anymore is the place the person actually ends up.

That changes the contract in a way that is easy to underestimate. People are forgiving readers. They skim, they infer, they fill in gaps without noticing they are doing it, and they will put up with a hero image that means nothing, a price buried in a PDF, or a date that only appears in the footer.

A model does almost none of that work for you. It takes what you marked explicitly and it guesses at the rest, and the small ambiguities a person glides straight over are exactly the places a machine produces a wrong answer about you. The upshot is uncomfortable but simple: the sites that do well over the next few years will mostly be the ones a machine can read without having to guess.

How an agent actually reads your page

It is worth being concrete about what "an agent reads your page" really means, because the phrase hides a few steps that matter a lot for how you build. When someone asks a modern answer engine a question, the model almost never works from memory alone. Most production systems use retrieval-augmented generation, or RAG, which is a fancy way of saying the system fetches relevant source material first and then writes its answer grounded in what it found.

That fetching does not happen at the moment you ask. Long before any question is posed, a crawler has visited your page, parsed the HTML, and broken the text into smaller passages, usually called chunks. Each chunk is run through an embedding model that turns it into a vector, a long list of numbers that captures roughly what the passage is about, and those vectors get stored in a vector database. Alongside that, structured signals like your JSON-LD and the entities it names can feed a knowledge graph, which is the part of the system that reasons about things, your company, your product, your author, rather than about strings of text.

When the question finally arrives, it is embedded the same way, and the system does a similarity search to pull back the handful of chunks whose vectors sit closest to the question's. Those retrieved passages, plus whatever the knowledge graph can confirm about the entities involved, become the context the model is handed. The model then writes its answer from that context and, increasingly, cites the sources it leaned on.

flowchart TB
%% caption: How a page travels from crawl to cited answer inside an agent.
    A[Person asks a question] --> B[Agent / answer engine]
    B --> C{Retrieval}
    C -->|crawl and fetch| D[Your page HTML]
    C -->|vector search| E[(Indexed chunks + embeddings)]
    C -->|entity lookup| F[(Knowledge graph + structured data)]
    D --> G[Parse: text, headings, JSON-LD]
    G --> E
    G --> F
    E --> H[Rank and assemble context]
    F --> H
    H --> I[Model writes the answer]
    I --> J[Cited summary back to the person]

How a page travels from crawl to cited answer inside an agent.

Two things fall out of this that are easy to miss. The first is that retrieval works on chunks, not whole pages, so a page that buries its one clear answer in the middle of a long, meandering section gives the retriever a worse chunk to find and quote. The second is that the embedding only captures what the text actually says; if the meaning lives in a layout, an image, or a script that has not run, it never makes it into the vector, and a passage that never gets embedded can never be retrieved. This is the machinery underneath a point worth stating plainly: you are no longer optimizing only to rank, you are optimizing to be retrieved and cited, and the pages that win are the ones a model can parse cleanly, retrieve confidently, and quote without having to invent anything.

Lighthouse is starting to grade this

The clearest sign to us that this is becoming table stakes rather than a fringe concern is that it is moving into the tooling we already use to keep ourselves honest. Lighthouse has been scoring performance, accessibility, and SEO since 2016, and it is now moving toward checks for agentic browsing. The question it is starting to ask is a blunt one: can an automated agent actually navigate this page, understand it, and act on it?

What we like about that framing is how much it overlaps with work we already claim to value. For a decade Lighthouse asked whether a page was fast and accessible for a person, and the agentic version is really asking whether that same page is comprehensible to a machine working on a person's behalf. In practice the answer comes down to clean semantic HTML, to real text rather than words baked into an image, to a structure that does not surprise you, and to content that lives in the HTML instead of materializing only after JavaScript has run.

None of that is new advice. It is mostly the accessibility discipline we have talked about for years, pointed at a new kind of reader. And once the audit you run on every launch starts scoring it, it stops being a thing you mean to get to and becomes part of what "done" quietly means.

Structured data was the early answer, and it turned out to be load-bearing

We should say that none of this appeared out of nowhere. The web has been growing a machine-readable layer underneath the visible one for well over a decade, and most people building sites never had much reason to notice it.

Back in 2011, Google, Bing, Yahoo, and Yandex, companies that agreed on almost nothing else, jointly launched schema.org as a shared vocabulary for describing what a page is about rather than how it looks. The idea is that an Article has a headline and an author and a date, that a Product has a price and a stock status, and that a FAQPage is a set of questions and their answers.

You express all of that as JSON-LD, a small block of structured JSON that states in machine terms what your prose already says in plain English, and Google's own guide to structured data has long recommended JSON-LD over the older inline formats for roughly the reasons that matter here.

For most of its life that layer did fairly cosmetic work. It powered rich results, the star ratings and FAQ accordions and recipe cards you see in search, and that was about it. Then LLMs arrived, and the same boring layer turned out to be the most reliable path into a model's understanding of a site, because a model does not have to reverse-engineer your layout to learn that you published a particular article on a particular date by a named author. You simply told it, in a format built for exactly that purpose.

We find it a little funny in hindsight that a standard designed to win a slightly nicer search snippet ended up being the cleanest way to be understood by machines that had not been invented when it was written.

SEO and GEO have become two different jobs

The reflexive take is that all of this kills SEO, and we do not think that is quite right. What seems to be happening instead is that the work is splitting into two related practices that pull in different directions.

The SEO most of us grew up with, search engine optimization, was fundamentally about ranking: you tried to earn a high position in a list of blue links, and then a person chose from that list. The newer concern, generative engine optimization or GEO, is about being the source a model trusts enough to quote and build its answer from. The term itself comes from a 2023 paper that studied how to improve a page's visibility inside generative engines.

Where the old work optimized for a slot in a list, this newer work optimizes for being inside the answer itself, which is a meaningfully different target even when the underlying page is the same.

The two rhyme more than they conflict, but the goals are not identical. SEO rewarded keywords and inbound links, whereas GEO seems to reward clarity, structure, and statements a model can lift without distorting them. A page can rank perfectly well and still never get cited, simply because it buried its one genuinely useful sentence behind five paragraphs of preamble and the model could not cleanly extract it.

So we do not think the answer is to abandon SEO. It is more that you now want to write and structure a page so it can do both jobs at once, ranking for the person who searches while also being quotable for the model that answers on their behalf.

You already own most of the instruments

The good news, and it is genuinely good news, is that you do not have to guess at any of this, because the tools to measure it already exist. In our experience most teams simply are not pointing them at this particular question yet.

Google Search Console is the closest thing we have to seeing a site through a crawler's eyes. It tells you which pages are indexed, which structured data validates, which queries you actually surface for, and where your markup is failing without anyone noticing. Its URL Inspection tool and the Rich Results Test will both render a page roughly the way Google's crawler does, and they cost nothing, so if your JSON-LD is broken you tend to find out there long before a model ever has to make something up about you.

Core Web Vitals cover the other half, which is the lived experience of the page. Largest Contentful Paint tells you how quickly the main content shows up, Interaction to Next Paint how quickly the page responds when you touch it, and Cumulative Layout Shift whether things stay still while it loads.

They started life as human-experience metrics, and we still think they are the best proxy we have for a page healthy enough for anyone at all, human or agent, to consume without trouble. The field data behind them comes from the Chrome User Experience Report, or CrUX, which is built from real visits rather than a lab simulation, so it reflects what people and machines are genuinely experiencing.

Taken together these tools answer the question that actually matters now, which is whether a machine can reach your content, parse it, and trust it, and whether a person would have had a decent time too.

Most of this is a content problem, not a code problem

We want to be clear that this is not only an engineering problem, because in our experience the most durable gains come from how the content is written and modeled in the first place rather than from anything clever in the template. A few habits seem to matter most:

Lead with the answer, and put the quotable, self-contained version of it high on the page, so a model never has to dig for the one sentence worth citing.
Mark up what you actually mean, so that every article, product, FAQ, and event carries structured data that agrees with the prose, because the moment the markup and the page disagree you have created a problem rather than solved one.
Write so that meaning survives extraction, which mostly means clear claims, real numbers, named sources, and plain dates, since ambiguity is a tax that a machine pays back to you in the form of confident, wrong summaries.
Render real content on the server, because if something only appears after JavaScript runs you should assume a meaningful share of machine readers will simply never see it.
Keep an llms.txt, which is a small machine-readable index of your important pages, much like a sitemap written for models, so that an agent can find the page you want it to read instead of crawling around in the dark.
Treat all of this like uptime rather than a launch checklist, because indexing, structured-data validity, and Web Vitals all drift over time, and the only way to catch the drift is to keep looking.

If there is a single thread running through that list, it is that machine-readability stops working the moment you treat it as something to bolt on at the end. It has to be built into how the content gets authored, in the same way you would build in tone or accessibility rather than retrofitting them.

Blinkk's approach

Most of what we have described is work that teams already know they ought to do and then quietly never get to, largely because it lives in a different tool from the one where the content actually gets written. That gap is the thing we have spent a while trying to close in Root, our open-source content engine, so that a hybrid site, one that reads well for people and for the agents reading on their behalf, comes out as the default rather than as a separate project someone has to staff.

The clearest example is the structured data, which we generate from the content itself. Plugins in Root CMS derive the JSON-LD from what authors are already typing, so the markup becomes a side effect of hitting publish instead of a second artifact that someone has to maintain by hand and that inevitably drifts out of sync with the prose. The llms.txt works much the same way Root already handles your sitemap, regenerating itself as pages come and go, so there is no hand-written index for anyone to forget about.

We also wanted the feedback loop to live where the writing actually happens, so a Root plugin pulls Google Search Console and CrUX data directly into the CMS, alongside the page each measurement describes. The point is that a content strategist can see how a given page is doing for machines and for people without opening four other dashboards to find out.

And because all of this drifts, we run the checks continuously, so that when indexing breaks or a Web Vital slips it shows up as an alert rather than as a slow decline in how often you get cited that nobody notices for half a year.

None of this is exotic, and we would not want to oversell it. It is mostly the fairly old-fashioned discipline of treating a machine reader as a real audience and giving the people who write your content the tools to actually serve it. The web is picking up a second set of eyes whether we are ready or not, and our guess is that the sites that hold up will be the ones built, from the content outward, to be read comfortably by both.