Quick answer
Grounding queries are the search strings an AI engine sends to a search index before writing an answer, and they are never identical to what the buyer typed. Google's Gemini API returns them in groundingMetadata.webSearchQueries and OpenAI's Responses API exposes a queries array, so the retrieval layer is observable rather than hypothetical.
Your buyer asks an AI assistant which marketing attribution tool is best for B2B SaaS. You have a page targeting exactly that phrase. You do not get cited.
Here is why. The engine did not search for the sentence your buyer typed. It decomposed that sentence into several narrower searches, ran them against an index, retrieved passages, and assembled an answer from whatever came back. Your page was never evaluated against the buyer's question. It was evaluated against machine-generated queries you have never seen.
Those machine-generated searches are grounding queries, and for most marketing teams they are a complete blind spot. You can see your rankings. You can see your citations, sometimes. The layer in between, where the actual retrieval decision gets made, is treated as a black box.
It is not a black box. Two of the largest AI platforms return their internal search queries as structured data in public APIs, and several consumer assistants render them in the interface while they work. The raw material for an evidence-based map of how AI engines research your category is sitting in API responses that cost cents to generate.
This post covers what grounding queries are, exactly where each engine exposes them, how to pull them, and what to do with the map once you have it. If you have not covered the fundamentals of getting cited at all, start with our answer engine optimization guide first. This is the layer underneath it.
Grounding query, query fan-out, and the prompt are three different things
The industry uses these interchangeably. They are not the same, and the confusion is why most advice in this space stays vague.
The prompt is what the human typed. "Best marketing attribution tool for B2B SaaS." It is a sentence, it was never sent to a search index, and optimizing for it as though it were a keyword is the core mistake.
Query fan-out is the technique. It describes one prompt being decomposed into multiple related searches issued across subtopics. It is a name for the behavior, not for the output.
Grounding queries are the output. They are the literal strings sent to a retrieval system. "Grounding" is not a marketing coinage here; it is the word the platforms themselves use in their API surface, because the purpose of the retrieval step is to ground the generated answer in retrievable, citable source material rather than model memory.
The practical distinction: fan-out is the thing you cannot observe directly on a consumer product, and grounding queries are the thing you often can. That is the entire opportunity.
Google documents the multi-query behavior plainly in its Grounding with Google Search documentation, in the section explaining how billing works. Because Google charges per search query the model generates, it has to state precisely what counts as one. Its own worked example takes the prompt "Tell me about the life of Albert Einstein." and shows it generating three separate searches covering his early life and education, the theory of relativity, and his later life in the US.
One sentence in. Three searches out. None of them the sentence.
Where each engine exposes its grounding queries
Observability varies enormously by platform, and it is worth being precise about which surface gives you what.
| Platform | Grounding queries observable? | Where |
|---|---|---|
| Gemini API | Yes, as structured data | groundingMetadata.webSearchQueries on each candidate |
| OpenAI Responses API | Yes, as structured data | queries array on the web_search_call action |
| Claude | Yes, in the interface | Search strings render as the assistant runs them |
| Perplexity | Yes, in the interface | Sub-queries display during the research step |
| ChatGPT (consumer) | Partially | Search activity is summarized in the reasoning trace |
| Google AI Overviews / AI Mode | No | No publisher-facing surface exposes the sub-queries |
The two API rows are the valuable ones, because they give you machine-readable strings you can log, count, and diff over time. The interface rows are still useful and require zero setup, but they produce manual notes rather than data.
The important caveat, stated up front: the Gemini API is a developer product and AI Mode is a consumer Search product. Google has never documented that they share a query-generation component. Observing Gemini API grounding tells you how a Google model decomposes a question in your category. It is a strong proxy. It is not a mirror of what AI Mode does, and anyone who tells you otherwise is describing undocumented internals of a closed system.
Method 1: Pull grounding queries from the Gemini API
This is the highest-fidelity signal available, and it is cheap.
When you call a Gemini model with the Google Search tool enabled, the response includes a groundingMetadata object on each candidate. Per the Gemini API reference, it is output-only and populated on generateContent calls. It carries seven fields, and three of them matter for this work:
webSearchQueriesis an array of strings: the actual searches the model ran. This is the fan-out, rendered as data.groundingChunksis the list of retrieved sources. In the Gemini API each web chunk carries exactly two properties,uriandtitle. (Adomainfield exists on Vertex AI's schema but not on the Gemini API's, which trips people up.)groundingSupportsis the join table between them. Each entry maps asegmentof the generated answer to thegroundingChunkIndicesthat supported it, withconfidenceScoresattached.
That third field is the one most people miss, and it is the most interesting. groundingSupports does not just tell you which sources were used. It tells you which sentence of the answer came from which source. That is a passage-level retrieval map of your category, generated on demand.
One implementation detail worth knowing before you write parsing code: the startIndex and endIndex on a segment are measured in bytes, not characters. If your category involves non-ASCII content, naive string slicing will silently produce wrong offsets.
A minimal call looks like this:
from google import genai
from google.genai import types
client = genai.Client(api_key=YOUR_KEY)
resp = client.models.generate_content(
model="gemini-2.5-flash",
contents="Best marketing attribution tool for B2B SaaS",
config=types.GenerateContentConfig(
tools=[types.Tool(google_search=types.GoogleSearch())]
),
)
meta = resp.candidates[0].grounding_metadata
# The searches the model actually ran
for q in meta.web_search_queries:
print(q)
# Which source backed which sentence
for s in meta.grounding_supports:
cited = [meta.grounding_chunks[i].web.uri for i in s.grounding_chunk_indices]
print(s.segment.text, "->", cited)
Run that across fifteen or twenty seed prompts covering one buying decision and you have a real dataset: every search the model ran, every source it retrieved, and the sentence-to-source mapping for each.
Two notes on scope. The GoogleSearch tool config in the Gemini API surface accepts searchTypes and timeRangeFilter; domain exclusion is documented on the Google Cloud grounding page rather than in the API discovery document, so check which surface you are actually calling. And if you display Google's grounded results in a product, the grounding documentation sets out display requirements for Search Suggestions, including that any non-Google results you show alongside must be clearly separated so users are not misled about their origin.
Method 2: Harvest sub-queries from the assistants you already pay for
No engineering required, works today, produces notes rather than data.
Claude renders its search strings as it runs them. Perplexity displays its sub-queries during the research step. ChatGPT summarizes its search activity in the reasoning trace. In each case you can read the queries off the screen while the assistant works.
OpenAI's API makes the same behavior explicit for anyone who wants it structured. In the published OpenAPI specification, the web search tool call carries an action that can be search, open_page, or find_in_page. On the search action, the singular query field is now marked deprecated: true and sits alongside a plural queries array. That deprecation is the clearest possible evidence that one-query-per-call is the legacy shape and multi-query retrieval is the current one.
Two things follow from that action union that change how you think about content. The engine does not only read result snippets. It opens specific pages (open_page) and runs in-page pattern searches (find_in_page). A page that requires a human to scroll and synthesize is a page that loses at the find_in_page step.
Note that sources and results are not returned by default on the Responses API. You opt in through the include parameter, using web_search_call.action.sources and web_search_call.results. Answer-level citations arrive separately as url_citation annotations carrying the URL, title, and character offsets into the generated text.
For manual harvesting, impose a protocol so two people on your team produce comparable notes: same seed prompts, fresh session each run, three runs per prompt, log every distinct query string with the engine and date. Fan-out is not deterministic. A single run tells you very little.
Build the grounding query map
The deliverable is a spreadsheet. One row per observed grounding query.
| Column | What goes in it |
|---|---|
| Seed prompt | The buyer question you tested |
| Grounding query | The literal string the engine issued |
| Engine | Gemini API, OpenAI, Claude, Perplexity |
| Method | API or interface observation |
| Intent class | Definitional, comparative, pricing, technical, validation |
| Currently cited | Which domain got retrieved for this query |
| Our asset | The page that should answer it, or blank |
| Gap type | 1 to 4, per the next section |
Scope it to one buying decision, not your whole category. Fifteen to twenty seed prompts covering how a buyer actually researches a purchase, from "what is X" through "X vs Y" to "how much does X cost," will generate somewhere between fifty and two hundred distinct grounding queries. That is enough to see the pattern and small enough to finish in an afternoon.
The insight arrives when you sort by intent class. Most teams discover that comparative and pricing sub-queries fire constantly, that they have no asset addressing either, and that a competitor is being retrieved for both.
Four gap types, and which to fix first
Not every gap costs the same or takes the same work.
| Gap type | What it means | Fix | Effort |
|---|---|---|---|
| 1. No asset | Nothing on your site addresses the sub-query | Write it | High |
| 2. Wrong answer | Page exists, does not answer this specific sub-question | Add a section | Low |
| 3. Not retrievable | Answer exists but is buried in narrative prose | Restructure into a self-contained passage | Low |
| 4. Competitor owns it | Another domain is consistently retrieved | Out-specific them | Variable |
Fix type 3 first. It is the cheapest work in the entire discipline, and it is usually the largest bucket. You already have the answer. It is spread across four paragraphs, dependent on context established earlier in the page, and therefore useless to a retrieval system pulling a single passage. Rewriting it as a self-contained chunk that answers the sub-query without needing the rest of the page is an hour of work per instance.
Type 2 is next. Type 1 is real work and should be prioritized by how commercially valuable the sub-query is, not by how many times you observed it. Type 4 is a judgment call, and the honest answer is often to skip it and win five easier queries instead.
What changes in your content plan
Sub-query coverage replaces keyword coverage. One page that cleanly answers eight grounding queries beats eight thin pages each targeting one keyword. This inverts the programmatic-SEO instinct, and it is the single biggest strategic shift.
Every section must stand alone. If a passage only makes sense after reading the two above it, it cannot be retrieved usefully. Write each H2 section so it survives being extracted in isolation.
Vagueness is disqualifying at the retrieval layer. Comparison and pricing sub-queries fire constantly. If your pricing page says "contact us" and your comparison content refuses to name competitors, you have opted out of a large share of the retrieval surface in your own category. That is a positioning decision with a measurable cost, and it should be made deliberately rather than by default.
Retrieval precedes citation. Getting retrieved gets you into the candidate set. Getting cited is what happens next, and the mechanics of that, from schema markup through content formats, are covered in the AEO guide. Retrieval surfaces you; citation quotes you. You need both, in that order.
What this method cannot tell you
The category is in its overclaiming phase. Here is what the honest version of this method does not give you.
The Gemini API is a proxy, not a mirror. It shows you how a Google model decomposes a question. It does not show you AI Mode's internals, and no public documentation establishes that they share a query generator.
There is no volume data. Grounding queries have no search volume, no difficulty score, and no trend line. Nothing publishes that data because these strings are generated per session, not typed by a population of humans. Use the map to prioritize; never use it to forecast.
Fan-out is non-deterministic and personalized. The same prompt produces different queries on different runs. Sample sizes of one are worse than useless because they feel like evidence.
Query counts vary too much to benchmark. You will see numbers quoted for how many sub-queries a typical prompt produces. Treat them all with suspicion unless the methodology names the engine, the tool configuration, and the sample size, because forcing grounding on in an API call produces very different counts than observing a consumer product.
Anyone selling you a dashboard that reports grounding queries with volume estimates attached is selling you a model output, not a measurement.
Key Takeaways
- Grounding queries are the search strings an AI engine sends to a retrieval index. They are generated by the model and are almost never identical to what the buyer typed.
- Google's Gemini API returns them directly in
groundingMetadata.webSearchQueries, and OpenAI's Responses API exposes aqueriesarray. The retrieval layer is observable, not hypothetical. groundingSupportsmaps individual sentences of a generated answer to the specific sources that backed them, giving you a passage-level view of what actually got used.- Build a grounding query map for one buying decision. Sort by intent class and fix retrievability problems before writing new pages.
- The cheapest win is restructuring answers you already have into self-contained passages.
- Never attach volume forecasts to grounding queries. No such data exists.
Frequently Asked Questions
What are grounding queries?
Grounding queries are the search strings an AI system issues to a search index before generating an answer. The model decomposes the user's prompt into narrower searches, retrieves passages from the results, and grounds its response in that retrieved material rather than relying on model memory alone.
How are grounding queries different from keywords?
Keywords are typed by humans and have measurable search volume. Grounding queries are generated by a model at runtime, vary between sessions, and have no volume data at all. You optimize for keywords by matching phrasing; you optimize for grounding queries by covering the sub-questions a model will decompose a topic into.
Is query fan-out the same as grounding queries?
No. Query fan-out is the name of the technique, where one prompt is expanded into multiple concurrent searches. Grounding queries are the resulting strings sent to the index. Fan-out describes the behavior; grounding queries are the observable output of it.
Can I see ChatGPT's grounding queries?
Partially. Consumer ChatGPT summarizes its search activity in the reasoning trace rather than exposing a clean list. Through the OpenAI Responses API you get structured access, where the web search tool call carries a queries array and you can opt into sources and results using the include parameter.
How many grounding queries does one prompt generate?
It varies by engine, question complexity, and configuration, and published figures differ wildly depending on methodology. Google's own documentation example shows a single biographical prompt producing three searches. Measure it for your own category rather than trusting a benchmark.
Do grounding queries have search volume?
No. They are generated per session by a model, not typed by a population of users, so there is nothing to aggregate into a volume figure. Any tool presenting volume estimates for grounding queries is showing you a model's guess.
Grounding query mapping is one piece of a working AI search motion, and it only pays off when the retrieval layer and the citation layer are built together. If you want a read on where your GTM system stands across both, start with our GTM Maturity Assessment.