Why Does AI Search Quote One Paragraph and Ignore the Rest of Your Page?

Why does AI search quote one paragraph and ignore the rest of your page?

Because retrieval systems work on passages, not pages. A page is the unit you publish and the unit that gets indexed, but the unit that gets matched against a question is smaller. So the answer engine finds the one section of your page that addresses the question and treats the rest as context it did not need.

This surprises people who spent a long time on a comprehensive guide and then watched an AI answer lift one paragraph from the middle of it. It feels like the work was wasted. It usually was not. The page earned its place in the index and the passage earned the citation, and those are two different competitions.

The mistake I see people make next is the expensive one. They conclude that they should chop everything into tiny fragments so every piece is retrievable. Google has published direct guidance against exactly that, which I will get to, and the guidance is correct.

What is actually happening between your page and the answer?

Two layers. First a retrieval layer finds candidate material, then a generation layer writes an answer using it. Google describes the technique as retrieval-augmented generation, also known as grounding, and says it relies on Google's core Search ranking systems to retrieve relevant, up to date web pages from the Search index.

Google's own documentation is unusually plain about the relationship between the two. It says the generative AI features on Google Search are rooted in its core Search ranking and quality systems, and that the best practices for SEO continue to be relevant for that reason. In other words, the retrieval layer is not a new search engine sitting beside the old one.

Google also describes a second mechanism called query fan-out, which it defines as a set of concurrent related queries generated by the model to fetch additional relevant results. The example in its documentation is a user asking how to fix a lawn full of weeds, with fan-out queries like best herbicides for lawns and how to prevent weeds in lawn. Your page can be pulled in by a question the user never typed.

What does the retrieval step do to your text?

In the general architecture, it splits documents into chunks and matches those chunks against the query. Anthropic's engineering write-up on contextual retrieval describes the standard approach plainly: break the corpus into smaller chunks of text, usually no more than a few hundred tokens, convert them into vector embeddings, and store them for semantic similarity search.

That write-up also names the failure mode that matters most for writers. Anthropic says traditional RAG solutions remove context when encoding information, which often results in the system failing to retrieve the relevant information. A chunk that made perfect sense inside your article can become ambiguous once it is standing alone in a vector database.

Anthropic's proposed fix, contextual retrieval, combines contextual embeddings with contextual BM25, a lexical matching function that catches exact strings an embedding might miss. Anthropic reports the method can reduce failed retrievals by 49 percent, and by 67 percent when combined with reranking. Those numbers describe a technique for building retrieval systems, not a public statement about how any consumer answer engine picks its citations, and it is worth keeping that distinction.

Does that mean you should chunk your content into small pieces?

No, and Google says so directly. Its optimization guide states there is no requirement to break your content into tiny pieces for AI to better understand it, that Google systems are able to understand the nuance of multiple topics on a page and show the relevant piece to users, and that there is no ideal page length.

I find this the single most useful sentence in the whole document, because it kills an entire genre of advice. The correct response to passage level retrieval is not smaller pages. It is self contained sections inside normal pages. Those are different things, and only one of them wrecks the reading experience for humans.

Google's framing in the same guide is that you should make pages for your audience, not just for generative AI search, and that sometimes shorter or longer pages work well depending on your subject. So write the guide. Just make sure each section of the guide stands up if someone reads only that section, because someone will.

What makes a passage retrievable on its own?

Three things. It names its subject rather than relying on a pronoun pointing back two paragraphs. It answers the question in its first sentence instead of building to it. And it carries any qualifier the claim needs inside the same passage, because the caveat you put in the introduction will not travel with it.

The pronoun problem is the one writers underestimate. A section that opens with this approach works best when or it depends on your plan size is meaningless in isolation. Replacing those openings with the actual noun costs nothing and makes the passage independent, which is the whole game.

The qualifier problem is more serious because it has consequences. If your article says a technique works, and the sentence explaining that it only works on sites under a certain size sits three sections away, a retrieval system can surface the unqualified claim. You will then get quoted saying something you did not quite mean. I wrote about a related version of this problem in how AI answer engines handle conflicting information.

Why do some pages get read but never cited?

Usually because the page restates what everything else already says. Google's guidance is specific here: it contrasts commodity content based on common knowledge with non commodity content that provides expert or experienced takes going beyond the ordinary, and says creating content people find unique and useful will likely influence visibility more than any other suggestion in its guide.

Think about it from the generation layer's position. It has retrieved eight passages that all say roughly the same thing. It only needs to cite something to support the claim, and it will tend toward sources that add something the others did not. If your paragraph is the eighth identical explanation of what a sitemap is, there is no reason to pick yours.

Google also makes eligibility explicit, which people forget. It says a page must be indexed and eligible to be shown in Google Search with a snippet, and that a site must be included in Search generative AI features in Search Console, to be eligible for display. Worth checking before you blame your writing.

Does structured data or an llms.txt file help here?

Not for Google, according to Google. Its guide says structured data is not required for generative AI search and there is no special schema markup you need to add, while still recommending it for rich results. On llms.txt it is blunter: it says you do not need such files to appear in Google Search generative capabilities, and that Google Search ignores them.

I still deploy schema on client sites, and I am comfortable saying why. It helps with rich results, it makes entity relationships explicit for systems that are not Google, and it forces a useful discipline about what a page actually is. But I do not tell clients it will get them cited in AI Overviews, because the people who run that system say it will not.

Google adds a note on llms.txt worth quoting for balance: it says it is completely fine to maintain those files for other services or systems that use them, and that doing so will neither harm nor help visibility in Google Search. That is a reasonable position and it matches how I treat the file.

How much of this transfers to the other answer engines?

The architecture transfers. The specifics are mostly unpublished. Every major system retrieves before it generates, so passage level independence helps everywhere. What no vendor publishes in detail is how its live product selects which retrieved passage becomes a visible citation, and anyone claiming otherwise is guessing.

So I optimise for the part that is knowable. Self contained sections, claims that carry their own qualifiers, a clear subject named in every heading, and content that says something the other eight results do not. That set is defensible no matter which engine is reading, because it follows from how retrieval works rather than from any one company's ranking behaviour.

It also happens to be good writing advice, which is the tell that it is probably right. When the optimisation and the craft point the same direction, you are not chasing a hack. I unpacked the citation side of this in how Claude web search treats page citations.

How do you test whether your page is being read in passages?

Use the report Google built for it. Google says you can measure how your content performs in generative AI features on Search and Discover using the Generative AI performance report in Search Console, so start there rather than with a third party estimate of your AI visibility.

Then run the manual test, which is cruder and more informative. Take each H2 on your page, ask that question to an answer engine, and look at what gets quoted. If your section is retrieved but the quoted line is not the one you would have chosen, your opening sentence is not doing its job. If nothing of yours appears, ask whether that section says anything the top sources do not.

Fix one section at a time and re-test. The change that moves the needle most often is rewriting the first sentence after a heading to answer the heading directly, which I covered in writing answer blocks that get cited.

What should you do next?

Open your best performing article and read only the section headings and the first sentence under each one. If that alone does not make sense as a set of answers, you have found your work, and it is editing work rather than a restructure.

Then resist the urge to split the page. Google has told us plainly that tiny pieces are not required and that there is no ideal length, so the version of this that costs you readers is not the version that wins citations. If you want a second opinion on whether your pages are structured for passage retrieval without being shredded, reach out and send me a URL.