Query fan-out is the technique of breaking one question into several related searches, running them, and building the answer from what comes back. Google documents that both AI Overviews and AI Mode may use it, describing it as issuing multiple related searches across subtopics and data sources to develop a response. The practical consequence for a site is that the unit being retrieved is no longer “the page that answers the question someone typed.” It is any passage that answers one of the sub-questions the system generated on the way, and several of those can come from different pages on your site, or from none of them.
This post covers what Google and OpenAI document about the technique, what remains undocumented, and three things it changes about how pages should be scoped: cover the sub-questions explicitly, give each one a home, and link those homes together. It sits under Citability and entity signals: a GEO guide.
What is query fan-out?
Query fan-out is a retrieval step in which a system rewrites a single user question into multiple narrower queries, searches for each, and combines the results. The term is Google’s. Its Search Central page on AI features says both AI Overviews and AI Mode “may use a ‘query fan-out’ technique,” and that while a response is being generated, the systems identify more supporting web pages, which lets Google display “a wider and more diverse set of helpful links” than a classic search would.
Google’s announcement of AI Mode at I/O in May 2025, written by Elizabeth Reid, put it more concretely: “Under the hood, AI Mode uses our query fan-out technique, breaking down your question into subtopics,” and running many queries at once. The same post describes Deep Search as using “the same query fan-out technique but taken to the next level,” able to “issue hundreds of searches.”
Is it only Google?
No, though Google is the vendor that names it. OpenAI’s help article on ChatGPT search describes the same shape without the label: ChatGPT search “typically rewrites your query into one or more targeted queries” sent to search providers, and after reviewing the first results “may send additional, more specific queries.” OpenAI’s example takes a question about drugs that target a particular receptor, searches a general phrasing first, then follows up with a query naming a specific compound it found in the first results.
So two documented patterns exist: parallel fan-out, where sub-questions are generated up front, and sequential follow-up, where later queries depend on what earlier ones returned. Both mean one user question produces several retrieval opportunities.
What isn’t documented?
Most of the mechanics. Neither vendor publishes how many sub-queries a typical question produces, how they are chosen, how results are weighted against one another, or how many pages from one domain can contribute to one answer. Third-party analyses offer estimates; none of those numbers come from the vendors, and this post doesn’t repeat them.
That matters for how far the implications below can be pushed. They follow from the documented fact that one question becomes several searches. They are not tuned to any number nobody has published.
What does fan-out change for a page?
It changes which question a page has to answer. Before fan-out, the useful model was: a person types a question, a results page lists documents, the person picks one. With fan-out, the question that reaches your page is often one the system wrote, and it is usually narrower than what the user typed.
Take an illustrative example on the fictional Acme Robotics site. A user asks: “Which robot arm should a small machine shop buy for loading a CNC mill?” A system decomposing that question might reasonably search for:
| Plausible sub-question (illustrative) | Acme page that could answer it |
|---|---|
| What payload does a CNC machine-tending arm need? | Buyer’s guide, “Choosing a payload” section |
| Which arms are certified for collaborative operation? | ARM-X9 product page, safety section |
| How much does a small cobot cost? | Pricing page |
| How long does it take to install a machine-tending cell? | Integration guide |
| Can a cobot be programmed without a robotics engineer? | Software overview |
The sub-questions are invented for this example. The point is structural: the user asked one thing, and five separate pages each had a chance to supply one piece. A site whose buyer’s guide tries to answer all five in one long, undifferentiated page has one chance at best; a site that answers each one clearly, in a section or page whose heading names it, has five.
How do you cover the sub-questions?
Write them down first. For each head question that matters to the business, list the sub-questions a careful expert would need to answer it. Good sources for that list, none of which need a terminal:
- Search Console queries. In the Performance report, filter queries to those containing “how,” “what,” “which,” “can,” or “does,” and group them by the page that earns impressions.
- Support tickets and sales calls. The questions that come up before a purchase are the sub-questions of “should we buy this.”
- Your own comparison and buyer’s guides. Their section headings are often a sub-question list already, written as labels.
Then map each sub-question to the passage on your site that answers it, in a spreadsheet with three columns: sub-question, URL plus heading, and whether the first sentence under that heading answers it. Rows with no URL are coverage gaps. Rows where the first sentence doesn’t answer the heading are extraction gaps, and The 40–60 word answer block covers how to close them.
Should each sub-question get its own page?
Each sub-question should get its own clearly headed, self-contained section, and its own page when it is substantial enough to stand alone. The test is whether the answer survives being read on its own. A passage retrieved for “how much does a small cobot cost” will be read without the paragraphs around it, so it has to name the product, state the price or range, and say what is included. Chunking: why passages have to stand alone covers what makes a section survive that.
The opposite failure is worth more attention than it gets: two pages answering the same sub-question differently. If the buyer’s guide says installation takes “a few days” and the integration guide says “two weeks,” fan-out can retrieve both, and the answer will either pick one or hedge between them. One sub-question, one canonical answer, with other pages linking to it rather than restating it with different numbers.
Why do internal links matter more under fan-out?
Because the pages that answer sub-questions have to be found in the first place. Google’s AI features page lists “making your content easily findable through internal links on your website” among the practices it says still apply. Under fan-out, a narrow page answering one sub-question is exactly the kind of page that ends up orphaned: it gets few external links and no navigation slot.
Three habits help:
- Link from the head-question page to every sub-question page, with anchor text that states the sub-question, not “learn more.”
- Link sideways between sub-question pages where a reader would naturally go next, such as payload to safety to pricing.
- Use question-shaped headings on the target sections so the anchor text and the heading agree. Question headings vs. keyword headings covers the trade-offs.
None of this is new advice. Fan-out raises its value, because a sub-question page with no internal links pointing to it is unlikely to be the one retrieved for that sub-question.
How do you check coverage across a site?
Without a terminal, use a crawler’s custom extraction to list every H2 and H3 on the site: //h2 and //h3, exported with the URL. Paste your sub-question list into a second sheet. For each sub-question, a formula such as =COUNTIF(Headings!B:B, "*payload*") counts headings that mention its key term; zero means no section names it, and more than one means check for conflicting answers. Your crawler’s inlinks count, in the same export, flags sub-question pages with few internal links.
From a terminal, the headings for a list of URLs:
while read -r url; do
curl -s "$url" | grep -oE '<h[23][^>]*>[^<]+' | sed "s|^|$url\t|"
done < urls.txt > headings.tsvGEOBee does not model fan-out, and no crawler can, since the sub-queries are generated inside the assistant. What it measures is whether each page is readable once retrieved: the answer block, question-style headings, extractability, and AI crawler access, scored per URL and listed in the three lenses. Its site-wide findings include orphan pages, which is the internal-linking failure above. Whether a page wins a given sub-query is not something a crawl can see, which is also why What prompt tracking can and can’t tell you is worth reading before trying to measure it from the outside. AI Overviews eligibility: every technical requirement covers the baseline every one of those pages has to clear first.
To find the sub-question pages that are orphaned or missing an answer block, download GEOBee and crawl your site during the 7-day trial.