What Is RAG? Retrieval-Augmented Generation Explained for SEO Professionals

Retrieval-augmented generation, usually shortened to RAG, is one of the most useful ideas to understand if you work in SEO today, and one of the most misunderstood. It describes how many AI answer systems find relevant text first and only then write an answer from it. That sequence explains why clear, self-contained passages matter. It does not, on its own, tell us how Google ranks pages.

This guide explains RAG in plain language for SEO professionals, walks through its components, shows a small demo you can run on your own computer with free tools, and is careful about the line between general AI engineering and documented search-engine behaviour. That line matters because the topic attracts a lot of confident claims that no one can verify.

Key takeaways

• RAG means a system retrieves relevant documents or passages and gives them to a language model to ground its answer, instead of relying only on what the model memorised during training.
• It has two main stages: retrieval (find the right material) and generation (write the answer from it). Quality depends heavily on the first stage.
• For content owners, the practical implication is that sections should be clear, specific and understandable without the rest of the page.
• RAG is a general AI design pattern. Experiments with it do not prove how Google or any other specific engine ranks or selects pages.
• You can build a tiny RAG pipeline locally in under an hour using free, open-source tools. It teaches more than reading about it.

How to read the evidence in this guide

We label claims as official documentation, established technical concept, practitioner convention or hypothesis. RAG itself is an established technical concept with a published research origin. Claims about how any particular search engine uses it are only as strong as that engine’s own documentation.

What Is Retrieval-Augmented Generation (RAG)?

Retrieval-augmented generation is a technique in which a system first retrieves relevant information from an external source and then supplies it to a large language model so the answer is grounded in that information. The term was introduced in a 2020 research paper by Lewis and colleagues, “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”. (Established concept.)

A useful comparison is an open-book exam. A model without retrieval answers from memory, which can be out of date or wrong. A model with retrieval is allowed to look things up first, then answer. The open-book version is not automatically correct, but it has something concrete to base the answer on and, in many designs, something to cite.

Who should care

SEO professionals who want to understand why AI answers cite some pages and not others, content teams deciding how to structure articles, and consultants being asked by clients “how do we show up in AI answers?”. If you are asked that question, RAG is the right mental model for how many (not all) AI answer tools work.

RAG is not the same as SEO, and not the same as training

• Training teaches a model patterns from large datasets, once, before release. RAG supplies fresh material at the moment of the question.
• RAG is an engineering architecture. SEO is the practice of making your pages findable and useful in search. They overlap when a search product uses retrieval to build answers.
• Query fan-out decides what to search for. RAG describes what happens with the results. Our guide to query fan-out covers the first part.

How RAG Works

A typical RAG system has an indexing phase that happens in advance and a query phase that happens each time someone asks a question.

Indexing phase (done in advance)

1. Collect documents. Web pages, PDFs, help articles, internal wikis.
2. Split into chunks. Long documents are cut into passages, often a few hundred words each, sometimes following headings. How you cut matters, because a chunk is the unit that gets retrieved.
3. Convert chunks into embeddings. An embedding model turns each chunk into a list of numbers (a vector) that captures meaning, so similar passages end up close together. See our guide to embeddings and vectors.
4. Store them. Vectors and the original text are kept in an index or a vector database.

Query phase (every question)

1. Embed the question. The question is converted into a vector the same way.
2. Retrieve. The system finds the chunks whose vectors are closest to the question vector, and sometimes combines this with keyword matching.
3. Rerank (optional). A second model re-orders the top results by how well they actually answer the question.
4. Assemble the prompt. The best chunks plus the question are placed in the model’s context window, with an instruction to answer using only that material.
5. Generate. The model writes an answer, and many products attach links or citations to the chunks used.

Component	Job	Why it matters to content owners
Chunking	Cuts documents into retrievable units	Sections that depend on surrounding text may lose their meaning
Embeddings	Represents meaning as numbers	Clear, specific wording produces cleaner matches than vague wording
Retriever	Finds candidate passages	If your answer is not retrieved, it cannot be used
Reranker	Orders candidates by relevance	Direct, well-evidenced answers tend to be easier to judge as relevant
Generator	Writes the answer	It can only reliably repeat what it was given
Citation layer	Links claims to sources	Visible attribution is a product decision, not guaranteed

What Google Says About RAG

Google’s official guide to generative AI features states that these features rely on RAG, which it also calls grounding: its core ranking systems retrieve relevant, up-to-date pages from the Search index, and its systems then review the specific information on those pages to generate a response that links to supporting pages. It describes query fan-out as the way related queries are generated to fetch more results. (Optimizing your website for generative AI features on Google Search.) (Official documentation.)

What Google does not publish is the internal detail: how pages are split into passages, which models embed them, how candidates are reranked or exactly what is selected. The RAG model in this article is therefore a sound way to reason about the process, but a statement such as a specific chunk length for Google would need a source, and we have none.

Google also says there is no requirement to break content into tiny pieces for AI, and no ideal page length. Our advice on clear, self-contained sections is about helping readers and other retrieval systems, not about meeting a Google rule.

A Real-World Example

This example is illustrative. We have constructed it to show the mechanism. It is not data from a client or from any search engine.

Imagine a help centre with this section on one page:

It depends on the plan. See below.

A user asks, “How long does onboarding take?” The retriever splits the page into chunks. The chunk above contains no mention of onboarding, time or the product, because the answer relied on a heading and a table elsewhere on the page. Its embedding is close to nothing in particular, so it is unlikely to be retrieved.

Now compare a rewritten version:

Onboarding usually takes two to three weeks for the Standard plan and four to six weeks for the Enterprise plan, depending on how many data sources need to be connected.

This chunk names the topic, gives a specific answer, and states the condition. It can stand alone, so it is far more likely to be matched to the question and useful when retrieved. The figures in this example are invented to illustrate the structure; in your content they must be real and verifiable.

The lesson is not “write for robots”. It is that clear, self-contained, specific passages help every reader and every retrieval system, whichever way chunks are cut.

Implementation Steps: Build a Tiny RAG Demo

The goal is learning, not production. You will embed a few passages, retrieve the best matches for a question and assemble the prompt a model would receive. You do not need an API key or a paid service.

1. Prepare a local environment. Install Python 3.9 or later. Create a virtual environment so you do not affect other projects.
2. Install the library. pip install sentence-transformers numpy. The first run downloads a small open-source embedding model, so you need an internet connection once. Check the library’s current documentation for version and licence details.
3. Create a small corpus. Copy six to ten sections from one of your own pages into a Python list. Include both well-written and vague sections so you can compare.
4. Run the script below.
5. Read the results critically. Which chunks were retrieved? Which obvious chunk was missed, and why?
6. Rewrite the weakest chunk so it can stand alone, then run the script again.

from sentence_transformers import SentenceTransformer
import numpy as np

chunks = [
    "It depends on the plan. See below.",
    "Onboarding usually takes two to three weeks on the Standard plan.",
    "Our support team is available Monday to Friday.",
]
question = "How long does onboarding take?"

model = SentenceTransformer("all-MiniLM-L6-v2")
chunk_vecs = model.encode(chunks, normalize_embeddings=True)
q_vec = model.encode([question], normalize_embeddings=True)[0]

scores = chunk_vecs @ q_vec          # cosine similarity (vectors are normalised)
top = np.argsort(-scores)[:2]

for i in top:
    print(round(float(scores[i]), 3), chunks[i])

context = "n".join(chunks[i] for i in top)
prompt = f"Answer using only this context:n{context}nnQuestion: {question}"
print(prompt)

The last lines show the grounded prompt a language model would receive. You can paste it into an AI assistant to see the generation step, or stop there. The similarity scores are only meaningful relative to each other within your test, so do not treat them as universal quality scores.

Free Tools

Tool	Use	Limits and checks
Python and a virtual environment	Run the demo locally	Needs basic command-line comfort
sentence-transformers and numpy (open source)	Embeddings and similarity	Downloads a model on first run; dependencies, licences and hardware vary
Google Sheets	Record test questions and results	Manual
Google Search Console	Real queries your pages already earn, to build realistic test questions	Not every query is shown
An AI assistant such as Claude	Run the generation step on your assembled prompt	Free usage limits apply. A chat interface is not an API, and API use can cost money.

Limitations

• A toy system is not a search engine. Your demo uses one small model and a handful of passages. Production systems use different models, far larger indexes, reranking and signals you cannot see.
• Results do not transfer to Google rankings. A passage that retrieves well in your demo is not proven to rank or be cited anywhere.
• Chunking differs by system. Some split by headings, some by length, some by meaning. You cannot assume yours matches theirs.
• Retrieval can still fail. Even good passages may not be retrieved if the question is phrased unusually or the system favours other sources.
• RAG reduces, but does not remove, wrong answers. A model can misread or over-generalise retrieved text.
• Do not rewrite everything for machines. Over-fragmenting a page into disconnected snippets can make it worse for readers. Keep the narrative; make each section clear.

A Measurable Experiment

Hypothesis (unverified): Rewriting vague sections into self-contained passages will increase how often those passages appear in the top three results of a local retrieval test.

1. Choose 10 sections from your own content that you suspect are vague or dependent on context.
2. Write 20 test questions a real reader might ask, using Search Console queries and customer questions. Record which section should answer each one.
3. Baseline run. Using the script, record for each question whether the correct section appears in the top three. Calculate the hit rate.
4. Intervention. Rewrite the 10 sections so each names its topic, gives a specific answer and states conditions. Do not add new topics.
5. Second run with the same questions and the same model. Calculate the new hit rate.
6. Optional control. Leave five comparable sections unchanged and check they stay stable.

Metrics: top-three hit rate before and after; average rank of the correct section. Guardrails: read the rewritten page for flow, and check that engagement does not drop after you publish the changes. Confounders and limits: twenty questions is a small sample, the model is not the one any search engine uses, and you may unconsciously write the rewrite to suit your test questions. Treat the result as a lesson in passage clarity, not as proof of ranking or citation effects.

Chunking Strategies Compared

How a document is cut into chunks has a large effect on what gets retrieved. There is no single correct method, and we do not know which any particular search product uses. Understanding the common approaches helps you reason about how your own content might be handled.

Strategy	How it works	Strength	Weakness
Fixed-size	Splits text every set number of words or tokens, often with overlap	Simple and predictable	Can cut through the middle of an explanation or table
Heading-based	Splits at headings so each section is a chunk	Follows the author’s structure	Sections that are too long or too short perform badly
Sentence-window	Retrieves single sentences but supplies neighbouring sentences as context	Precise matching	More complex to build
Semantic	Splits where the meaning shifts, using embeddings	Keeps related ideas together	Needs a model and tuning

The takeaway for content owners is robustness. If your section works whether it is cut at a heading, by length or by meaning, it will survive more systems. That means each section should state its subject, answer its question and contain the conditions that make the answer true.

A Checklist: Is This Section Retrieval-Ready?

1. Does the heading describe the content accurately? Headings are often used as context for the passage beneath them.
2. Does the first sentence answer the question the heading asks?
3. Does the section name its subject instead of relying on “it”, “this” or “the above”?
4. Are numbers, conditions and exceptions stated in the section itself rather than in a distant table or footnote?
5. Is it a sensible length? Long enough to be useful, short enough to stay on one topic. There is no verified ideal word count, so judge by whether it answers one question completely.
6. Are claims attributed or evidenced so a reader, or a system, can tell what they rest on?
7. Would it still make sense if someone saw only this section?

What RAG Means for Different Content Types

• Tutorials and how-to guides: keep each step self-contained and state prerequisites at the start of the relevant step, not only at the top of the page.
• Comparison and pricing pages: tables are useful to people but can be chunked badly. Add a sentence or two that states the main conclusion in plain text near the table.
• Definitions and glossary pages: a one or two sentence definition at the top is easy to retrieve and easy to read. Follow it with detail.
• Case studies: state the client context, action and result in the same section, with figures that are real and sourced.
• FAQs: each question and answer pair is naturally chunk-shaped. Make answers complete rather than saying “see above”.

Common Mistakes

• Writing for chunks at the expense of readers. A page of disconnected soundbites is poor reading. Keep a narrative thread.
• Assuming the demo proves something about Google. It shows how a simple retrieval pipeline behaves.
• Hiding key facts in images. Text in an image may not be extracted or embedded. Put the important facts in text.
• Stuffing in keywords to match queries. Retrieval rewards clarity and specificity, not repetition.
• Treating citations as guaranteed. Whether an answer shows a source is a product decision.

Chunking Strategies Compared

How a document is cut into chunks has a large effect on what gets retrieved. There is no single correct method, and we do not know which any particular search product uses. Understanding the common approaches helps you reason about how your own content might be handled.

Strategy	How it works	Strength	Weakness
Fixed-size	Splits text every set number of words or tokens, often with overlap	Simple and predictable	Can cut through the middle of an explanation or table
Heading-based	Splits at headings so each section is a chunk	Follows the author’s structure	Sections that are too long or too short perform badly
Sentence-window	Retrieves single sentences but supplies neighbouring sentences as context	Precise matching	More complex to build
Semantic	Splits where the meaning shifts, using embeddings	Keeps related ideas together	Needs a model and tuning

The takeaway for content owners is robustness. If your section works whether it is cut at a heading, by length or by meaning, it will survive more systems. That means each section should state its subject, answer its question and contain the conditions that make the answer true.

A Checklist: Is This Section Retrieval-Ready?

1. Does the heading describe the content accurately? Headings are often used as context for the passage beneath them.
2. Does the first sentence answer the question the heading asks?
3. Does the section name its subject instead of relying on “it”, “this” or “the above”?
4. Are numbers, conditions and exceptions stated in the section itself rather than in a distant table or footnote?
5. Is it a sensible length? Long enough to be useful, short enough to stay on one topic. There is no verified ideal word count, so judge by whether it answers one question completely.
6. Are claims attributed or evidenced so a reader, or a system, can tell what they rest on?
7. Would it still make sense if someone saw only this section?

What RAG Means for Different Content Types

• Tutorials and how-to guides: keep each step self-contained and state prerequisites at the start of the relevant step, not only at the top of the page.
• Comparison and pricing pages: tables are useful to people but can be chunked badly. Add a sentence or two that states the main conclusion in plain text near the table.
• Definitions and glossary pages: a one or two sentence definition at the top is easy to retrieve and easy to read. Follow it with detail.
• Case studies: state the client context, action and result in the same section, with figures that are real and sourced.
• FAQs: each question and answer pair is naturally chunk-shaped. Make answers complete rather than saying “see above”.

Common Mistakes

• Writing for chunks at the expense of readers. A page of disconnected soundbites is poor reading. Keep a narrative thread.
• Assuming the demo proves something about Google. It shows how a simple retrieval pipeline behaves.
• Hiding key facts in images. Text in an image may not be extracted or embedded. Put the important facts in text.
• Stuffing in keywords to match queries. Retrieval rewards clarity and specificity, not repetition.
• Treating citations as guaranteed. Whether an answer shows a source is a product decision.

Frequently Asked Questions

Is RAG what Google uses for AI Overviews?

Google says its generative AI features on Search rely on retrieval-augmented generation (which it also calls grounding) and query fan-out, retrieving pages through its core ranking systems. The detailed architecture is not published, so treat RAG as a good general model and not a full description.

Do I need a vector database to understand RAG?

No. The demo above uses a simple in-memory comparison. Vector databases matter when you have millions of passages and need fast lookup.

Does RAG mean keywords no longer matter?

No. Many systems combine keyword and vector retrieval, and exact terms remain important for names, codes and specific phrases. Our guide to keyword, vector and hybrid search covers the trade-offs.

Can I optimise for RAG?

You can make passages clearer, more specific and easier to extract, which is good practice anyway. You cannot guarantee retrieval or citation. Google states that no special optimisation is required for its AI features.

How does this connect to passage ranking?

Passage ranking is a documented concept about evaluating sections within a page. RAG chunk retrieval is a separate AI pattern with a similar practical lesson. See what passage ranking is.

How do I tell whether my pages are being used by AI tools?

Use a repeatable observation log rather than single checks. We explain the method in how to measure AI search visibility.

Sources and Further Reading

• Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (2020), arXiv:2005.11401
• Google Search Central: AI features and your website
• Sentence Transformers documentation

Related reading

• What is query fan-out?
• Embeddings and vectors explained
• Keyword vs vector vs hybrid search

Next Step

If you want your key pages reviewed for passage clarity and retrieval-readiness, request a free SEO audit. We will flag the sections that rely too heavily on surrounding context.