---
title: "SEO and Retrieval-Augmented Generation (RAG)"
description: "How Retrieval-Augmented Generation determines which web content AI search engines cite, and how to structure content for retrieval."
tldr: "RAG (Retrieval-Augmented Generation), which Google calls grounding, is how AI search fetches web content at query time; Google says its version retrieves pages through its core ranking systems and shows the relevant piece of a page. Content written in self-contained sections, with direct answers and clear entity references, is easier to retrieve: a 2025 benchmark found embedding models lose 15.6% of retrieval performance when the answer sits late in a passage, and Anthropic's RAG guidance shows chunks that lose their context fail retrieval. Google says its own systems need no chunking from publishers."
publishDate: 2026-05-08
updatedDate: 2026-09-28
author: "Liam Hayward"
---
Retrieval-augmented generation (RAG) is the step in which an AI search system looks up current web pages while answering a question and builds its answer from passages in them. For SEO, it is why each section of a page needs to make sense on its own: Google says its AI features retrieve pages through its core ranking systems and can "understand the nuance of multiple topics on a page and show the relevant piece to users",[^2] so the part of a page that gets used is often a passage, not the whole page.

## What is RAG?

Retrieval-Augmented Generation (RAG) is the process by which AI search engines fetch current web content and use it to generate answers. Google defines it in the same terms, as a technique also known as grounding that relies on its core Search ranking systems to retrieve relevant, up-to-date pages from its index.[^2] Rather than relying solely on knowledge baked into the model during training, the system retrieves passages from indexed pages at query time and grounds its response in those passages. The pages it cites are the source of the retrieved content. For complex queries, Microsoft describes the process on the Bing index as iterative: the system may "refine retrieval based on intermediate results, combine evidence from multiple sources", and register conflicts between sources rather than silently picking one.[^1]

[How AI search works](/ai-search/how-ai-search-works/) covers the full mechanism, including the distinction between training and retrieval, and how crawlability feeds into citation potential. Protocols like NLWeb can expose a site's schema.org structured data as queryable endpoints, making that content more accessible to RAG-based retrieval systems.

## How retrieval systems split pages into passages

Typical RAG pipelines do not retrieve whole documents: they break content into "smaller chunks of text, usually no more than a few hundred tokens", embed them, and retrieve the chunks that best match the query.[^4] That chunking happens on the system's side. Google goes further than saying publishers need not do it: its AI optimisation guide files "chunking" among the things you can ignore for Google Search, stating there is "no requirement to break your content into tiny pieces for AI to better understand it" because its systems can understand several topics on one page and surface the relevant part. There is no ideal page length either.[^2] What publishers control is not chunk size but how the content is structured before it is chunked.

Content structured around one idea per section, with a direct opening sentence and self-contained meaning, aligns with how retrieval systems split and evaluate text, and the failure mode is documented from the engineering side. Anthropic's account of RAG says chunked documents "often destroy context": a chunk reading "the company's revenue grew by 3% over the previous quarter" does not say which company or which quarter, "making it difficult to retrieve the right information or use the information effectively". Its fix, prepending context to each chunk before embedding, cut top-20 retrieval failures by 35%, and by 49% combined with keyword matching.[^4] That is a measurement of general RAG pipelines, not of any search product, and the publisher-side reading is the same either way: a section that carries its own context is easier to match to a query than one that leans on the paragraphs around it.

This matters because a single page can contribute multiple retrievable passages. A well-structured article can be cited across several different queries if each section addresses a distinct question. A poorly structured article of the same length may produce passages that are partial and misleading when extracted from their context.

## How do you write for passage-level retrieval?

Each section of content should be able to answer a specific question on its own. Practically, this means:

- **Start each section with the direct answer.** The opening sentence of an H2 section should address the question posed by the heading, with supporting detail after it. Retrieval models carry a documented position bias, over-weighting the start of a passage and overlooking relevant information further down it: benchmarking across the retrieval pipeline found that the embedding models doing the initial passage matching lost an average of 15.6% of retrieval performance when the relevant information sat later in the passage.[^3] Keyword matching and the rerankers that score a shortlist afterwards were largely unaffected, so the effect bites hardest at the stage deciding which passages are considered at all.
- **Use question-shaped headings where the section answers one.** "What is X?" matches the wording someone types more closely than "Understanding X" does. No published study measures the size of that difference, so treat it as reasoning about how retrieval matches text rather than a measured gain, and do not force a heading into a question the section does not answer.
- **Avoid references to previous sections.** Phrases like "as noted above" or "building on the previous point" make a passage depend on its surrounding context. Write each section as if the reader arrived there directly.
- **Keep one idea per H2.** A section covering two distinct ideas is harder to use for a reader who lands on it, and whichever part a system extracts loses the context the other part supplied, the failure Anthropic's chunk example shows. Split them into separate headings.

Length within a section is secondary to structure. A concise section that leads with its main point is more retrievable than a longer one that buries it.

## Entity clarity and structured data

Content that names its entities unambiguously, people, organisations, products, concepts and locations, is easier to retrieve accurately, and Anthropic's chunk example above is exactly this failure: a passage that says "the company" instead of naming it cannot be matched to a question about that company.[^4]

Use a brand or product's full, established name on first mention rather than a pronoun or shorthand. Identify people by name and, where relevant, their role or affiliation. When a topic could be confused with another (the word "Apple" as a company versus a fruit, for example), include a disambiguating phrase.

Structured data via Schema.org markup labels the entities on a page explicitly, and its documented reach is narrower than that sounds. Microsoft says structured content, with schema-marked pages as its example, helps its AI answers interpret and summarise a page;[^5] Google says structured data is not required for its generative AI features and that there is no special markup to add.[^2] An `Organization` or `Person` block on an author section makes attribution machine-readable for whichever system does read it. None of it guarantees citation, and the prose should carry the same names and attribution, because the prose is what every system reads.

## RAG optimisation and traditional on-page SEO

The content practices that support RAG retrieval are largely the same as those that support traditional search quality. Direct writing, clear headings, factual accuracy, and credible authorship are not new requirements.

The difference is emphasis. Traditional on-page SEO treats the page as the unit: title tag, meta description, keyword distribution, internal linking structure. RAG optimisation treats the section as the unit. A page can rank well in traditional search while containing passages that are poorly structured for retrieval.

There is no separate technical playbook for RAG. For Google the link is documented: its AI features retrieve through its core Search ranking systems,[^2] so the pages that earn traditional rankings are the pool its AI answers draw from. The measurement differs: citation rate rather than click-through rate.

## Frequently asked questions

### Is RAG the same as GEO?

No. RAG is the technical architecture AI systems use to retrieve and ground their answers. Generative Engine Optimisation (GEO) is the content practice of making pages more likely to be retrieved and cited by those systems. RAG describes how AI search works; GEO describes what publishers do in response to it.

### Do I need schema markup to appear in AI answers?

No, but it reduces ambiguity. Google says so directly: structured data is not required for generative AI search, and there is no special schema.org markup to add, though it remains worth using for rich results.[^2] Pages without structured data can and do appear in AI-generated answers. The one operator that says schema helps at all is Microsoft, whose statement is that structured content, schema-marked pages included, helps its AI answers interpret and summarise a page.[^5]

### How does this differ from optimising for featured snippets?

The techniques overlap significantly. Featured snippet optimisation also emphasises passage-level clarity and direct opening sentences. The difference is that featured snippets are drawn from top-ranked results, whereas AI retrieval can surface passages from pages at lower rank positions if the passage relevance is strong. Writing for retrievability is a broader target than writing for position zero.

[^1]: [Evolving role of the index: From ranking pages to supporting answers — Bing](https://blogs.bing.com/search/May-2026/Evolving-role-of-the-index-From-ranking-pages-to-supporting-answers)
[^2]: [Optimizing your website for generative AI features on Google Search — Google Search Central](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide)
[^3]: [An Empirical Study of Position Bias in Modern Information Retrieval — Zeng et al., arXiv 2505.13950 (EMNLP 2025 Findings)](https://arxiv.org/abs/2505.13950). Beijing University of Posts and Telecommunications with the NovaSearch team; two constructed benchmarks, not a live engine; the 15.6% average drop covers dense embedding and ColBERT-style late-interaction models.
[^4]: [Introducing Contextual Retrieval — Anthropic](https://www.anthropic.com/news/contextual-retrieval). Engineering guidance for building RAG systems on Anthropic's models, September 2024; it describes general RAG pipelines, not any search product.
[^5]: [How AI Search Is Changing the Way Conversions are Measured — Bing Webmaster Blog](https://blogs.bing.com/webmaster/November-2025/How-AI-Search-Is-Changing%E2%80%AFthe%E2%80%AFWay%E2%80%AFConversions%E2%80%AFare-Measured), Fabrice Canel and Krishna Madhavan, 20 November 2025: "Structured content, like schema-marked product pages, FAQs, and comparison tables, helps AI systems interpret and summarize your content more effectively."