Before AI can decide what to cite, it first has to understand what your words mean.
You (ideally) write your homepage for a person to read. Nowadays, the first reader is a machine - 57% of global web traffic is a bot, and only 43% are human. This could mean the first visitor to your website is an AI system that's deciding what to cite, summarize, or use when answering a question or describing your company. What you need to understand to know how to use this in your favor is how exactly the LLMs get these answers, since they don't read your page the same way a human does.
Human vs. machine page reading
A person reading a homepage does it the way they read anything: left to right, one sentence after another, filling gaps in their knowledge with context from everything they already know. A homepage phrase like “built for teams that move fast” means something to a human because humans bring their own experience to whatever they are ready. They've met teams like this, and they know what “fast” implies in context.
A language model (LLM), the kind of AI behind tools like ChatGPT or Claude, doesn't read that way. Before it can do anything with a page (answer a question about it, decide whether it's relevant to a search, or summarize it), the text first gets broken apart and turned into a different kind of thing entirely, a process for 'reading' and understanding text done by a machine, where it gets its context, not from life experience like a human, but from the rest of the web or the rest of the site. It works more off comparison, not for comprehension the way a person does it. It doesn't process words out of order, but instead it uses sequence differently from human understanding.
We'll walk you through what that transformation involves: how a page gets split into pieces, how those pieces become something a machine can compare, and what happens once a model turns that into an answer (FIG. 1).
Words become 'chunks'
A model can't take in an entire page at once and treat it as a single unit. So before anything else happens, a page gets cut into smaller pieces, usually a few hundred characters each. This process is called chunking, and it's what makes it possible to compare or retrieve one section of a page separately from the rest.
The split tries to use the existing structure. It breaks on a heading, a paragraph, or a sentence, gets each piece close to that target size without going over, and copies a little text along the way until each part of the page is broken up. From this point on, the model works on the pieces, or chunks, not the page (FIG. 2).
In chunking, the LLM looks solely at the separated piece. They are not great (yet) at looking even at the other sections of the page to determine exactly what the chunk is about. So, you need to make sure that your 'chunks' have meaning on their own, and that you don't leave a lot to nuance or context that a human may already possess when they look at your site.
The example above uses a fictional company we built specifically for this article, called Verdrax. We invented our own company so the model couldn't use anything it might already know about a real brand and impact our study.
We used a 'chunker' for this article to demonstrate what commonly occurs when a chunker is used inside Claude, ChatGPT or any other commercial AI product. We can't use the real ones because they are not public. However, the gist of what they do is standard, and that is what we replicated here.
Meaning becomes vectors
Once a chunk is determined, it is converted into a string list of numbers meant to capture what the chunk is about. That conversion is called an embedding, typically hundreds of numbers per chunk, computed here using OpenAI's embedding model. The individual values are not important, it matters how they are used. Two chunks that mean similar things end up with numbers that are mathematically close together, and two chunks about different things end up far apart.
The diagram above (FIG. 3) uses three real chunks from the same homepage split apart in the last section. The “What We Do” chunk and “The Problem” chunk scored 0.79 out of a possible 1.0 for closeness. Both talk about vendor documentation and onboarding friction, so that tracks. The “Deployment & Security” chunk, about hosting and certifications, scored only 0.58 against “What We Do”: related enough to still come up as connected, but noticeably farther.
One thing we should be upfront about: real embeddings have far more dimensions than a flat picture like this can show, so this is a simplified “closer or farther” illustration, not a literal map of where these chunks actually sit. No matter what, comparing meaning, once everything is embedded, comes down to measuring distance between lists of numbers, not reading anything.
Retrieval is not the same as understanding
Retrieval is LLM language for 'finding a page,' and it's a different step from understanding what's on it. A search query gets converted into the same kind of number-list as any other chunk, and a system compares it against every page's numbers to see which ones are closest. That's what “relevant” means here: mathematically close, not necessarily correct. This is cosine similarity.
Getting your page or website to a point where it is getting shown and cited is a matter of making sure you have the closest answers to the queries. So, more specific content, more clear language, all of these are better and will help the LLM understand what you are about enough to actually surface you as an answer.
The model builds an answer
Once an LLM has done its work to retrieve content, it then formulates an answer. This is different than the traditional search we have used for the last 20 years. Instead of giving the user a path to do more research (10 blue links in Google), it seeks to answer the query fully. This project was set to measure if the model answers correctly with what it is given, or if it invents an answer if the information was not there.
For this part, we didn't chunk or retrieve anything. We tested it with Claude directly, handing over one full page at a time (the whole page at once, no retrieval ambiguity) and asking ten real questions about the company plus one question with no true answer anywhere in any version, built specifically to see what happens when the model has nothing to work with. The clear version's page names NetSuite, SAP Ariba, and Coupa directly in its integrations section, and questions about those got answered correctly every time. Handed the trap question, on a page where no price is ever stated, Claude answered: “The text does not state a dollar price for the Starter plan… No monthly dollar figures are given.”
Across every version, every question, and every time we asked, Claude never invented a specific detail in place of a missing one. The two versions that stated their facts directly each answered 95% or more of the ten questions correctly (FIG. 4). The version that left everything vague answered about a third. In this case, the model didn't misread anything. There just wasn't much stated to extract.
The failure mode here is a vague page giving the model very little to say.
The failure mode here is a vague page giving the model very little to say.
What this changes
All in all, here's what happens with your homepage and an answer an LLM gives about it: the page gets split into pieces (chunks), each piece becomes a list of numbers representing what it means, a question gets compared against those numbers to find what's relevant (cosine similarity), and then, using only what was found, the model formulates an answer.
This makes your homepage's real job a little different from the one it was probably written for. You need to make sure every important fact can stand on its own, pulled out of context with nothing around it to prop it up. The practical implication is this: whatever fact isn't stated plainly somewhere on the page (a specific integration, a specific price, a specific industry) probably won't make it into an answer. And it's not because the model misunderstands your content, it's because without the clear language, there's nothing there to find, retrieve, or generate from.
The two versions that performed well in our test didn't have much in common stylistically. One was repetitive and keyword-heavy. The other was clean and direct. But they shared the one thing the vague version didn't: both stated the same key facts clearly, by name. We can point to this conclusion with confidence. Whether polished writing helps or hurts on top of that is still an open question, this test wasn't built to isolate it, but clear, named facts were crucial in each version that worked.
Go through your own homepage section by section and check whether each important fact is named, not implied or saved for a sales call. Be as clear as you can. You can also run a version of this test yourself: paste your homepage into an AI system, ask it the questions a real buyer would ask, and see which ones it can't answer. That gap is what we looked at in our study.
A machine doesn't read your homepage like a human does. It takes it apart, measures it, and tries to answer questions using the pieces from that process. Whatever message you are trying to get across to the LLM about your company has to be there, plainly stated, in the segments we refer to as chunks.