Why Query Fan-Out Is More Than Just Keyword Variations

Somebody sends me a fan-out report most weeks now. It usually runs to twenty or thirty rows, it looks thorough, and it is nearly always a list of the same search written twenty different ways.

The honest summary of how our thinking changed is one sentence. AI search often breaks one question into several smaller searches. We used to audit those as keyword variations. Now we audit whether each smaller search adds a genuinely different piece of information.

That sounds like a small distinction. It changes almost everything downstream: what you build, where you build it, and whether you should build anything at all.

What query fan-out actually means

Query fan-out is a retrieval technique that splits one question into several smaller searches and runs them at once. Google’s help documentation puts it plainly: AI Mode divides your question into subtopics, searches each one simultaneously across multiple data sources, then brings the results back together into a single response. Google used the same term when it announced AI Mode in March 2025, describing it as issuing multiple related searches concurrently across subtopics.

Take a question a buyer might actually ask:

What is the best CRM for plumbers?

Before a system can answer that properly, it needs several things it does not have yet:

• which products exist in that category
• what they cost
• whether they handle job scheduling
• whether they connect to the accounting software the business already runs
• what current users say about them
• whether they suit a two-van operation or a fifty-van one

So instead of treating the original prompt as one search, treat it as a question that splits into several smaller research tasks. That is fan-out. If you want the full mechanism, including what each platform documents and what has to be inferred, we keep it on our reference page for how AI search works.

The version that makes it obvious

The clearest explanation of fan-out I have seen from Google was not about text at all. In March 2026, Dounia Berrada, a Search Senior Engineering Director, explained how AI handles visual searches using an outfit photo. Rather than treating the picture as one object, AI Mode identifies the hat, the shoes and the jacket and investigates each separately before assembling an answer. She described it as running roughly a dozen searches in the time a single search would take.

Once you picture it that way, the text version stops being abstract. One broad question, several smaller investigations, one assembled answer.

The problem with the old way of analysing it

The old approach produced volume, not coverage. Run “best CRM for plumbers” through a typical fan-out generator and you get something like this:

• best CRM for plumbers
• plumber CRM
• plumbing CRM software
• CRM for plumbing companies
• best software CRM for plumbers

Five rows. One information need. Every one of those searches would return more or less the same page, because they are the same question with the words moved around.

Dan Petrovic at Dejan named this failure mode neatly in Fanout V2: From Paraphrastic Collapse to Complementary Set, published on 16 September 2026. His illustration is camping gear: a naive fan-out for “camping gear for beginners” produces five near-identical rewordings, and the retrieval collapses back onto the same handful of items. A useful fan-out would branch by category instead, so one sub-query goes to shelter, another to tools, another to footwear.

Our interest in that is narrower and more practical. We are not building the retriever. We are auditing coverage for a client who wants to know where to spend. So the question we care about is: how do we tell whether a fan-out branch actually adds new evidence, rather than adding another line to a spreadsheet?

The important point, and the one that should change how you read any fan-out report: more queries does not mean better coverage.

What happened when we measured 197 real fan-out queries

Fan-out strings carry almost no measurable search volume. Search Scope tested that on 12 September 2026 rather than assuming it, harvesting verbatim fan-out sub-queries from a ChatGPT mention index across eleven calls through DataForSEO’s AI Optimization API. Not reconstructed guesses at what a model might search, the actual strings recorded against the prompts.

Then we took 197 of those verbatim strings and submitted them to an AI search volume endpoint to see what demand they carried.

Three returned a non-zero figure. The highest was 2.

The obvious objection is that we were reading the wrong market, so we tested that too. We re-ran the batch at the United States locale with ordinary control keywords in the same request. The controls returned real volume in both locales. The long fan-out strings returned zero in both. The zeros are a property of the query form, not the market.

That result is worth sitting with, because it settles an argument. Fan-out strings are machine-built retrieval queries. They are not phrases people type. You cannot audit them with a keyword tool, you cannot prioritise them by volume, and a fan-out map is not a demand forecast. It is a map of retrieval behaviour, which is a different and more useful thing once you stop expecting it to be the first one.

Two caveats we state every time we use this data. That mention index is United States and English only, so there is no Australian fan-out corpus to buy; local relevance in our harvests comes from prompts that name Australian places, never from a location parameter. And the harvest reflects one platform on one day. We treat it as observed evidence of retrieval behaviour, not as a stable universal.

It also explains a wider problem with AI visibility reporting. The gap between the query a tool tracks and the query that actually sourced the answer is the main reason AI visibility tools are less accurate than they look.

The shift: from query variations to information needs

We now start the audit with a different question. Not “what else could this be called”, but:

What different pieces of information would an AI system need in order to answer the original question well?

For the plumbing CRM example, that gives something like:

• Which tools exist in this category?
• Which ones are affordable for a small operator?
• Which handle job scheduling and dispatch?
• Which integrate with Xero or MYOB?
• Which are well reviewed by people who actually use them?
• Which suit small teams rather than enterprise fleets?
• How do the two or three main options compare directly?

That is a far more useful map, and not because the wording is more varied. It is more useful because each branch answers a different part of the question. Take any one away and the final answer gets worse. That is the test.

A branch earns its place when removing it would leave a hole in the answer. A branch that can be removed without anyone noticing was never a branch.

Why this matters for AI SEO

Different information needs are usually satisfied by different types of source, and that is where this stops being theory. If every branch leads to the same kind of content, you probably need one strong page. If the branches need genuinely different evidence, the system will go looking in genuinely different places, and only some of those places are your website.

Nine classes is not a magic number. It is roughly where a normal consumer or B2B decision lands before the branches start repeating themselves, and it is a useful checklist: if your map has fourteen rows and they all sit in two of these classes, you have a wording exercise, not a coverage map.

Which changes the question the whole engagement is built around.

The job stops being “how do we rank one page for this prompt”. It becomes: where does the system need to look to build this answer, and where can our brand credibly appear in that process?

That is a more honest framing of what AI SEO work is, and it is the reason a lot of it happens off your own domain. It is the same logic behind entity SEO: your brand is something that needs independent corroboration, not a site that needs more pages.

The same classes, three different markets

The classes hold across verticals. What changes is which branch is hardest to win and who currently owns it. Three examples from markets we work in.

Childcare, a local family decision

The pattern in this market is that the emotional branches, safety and educational fit, are the ones parents actually decide on, and they are the branches providers cover worst. Availability is already owned by Starting Blocks and the commercial directories, so competing there is expensive and mostly pointless. The winnable ground is the branch nobody has documented.

Commercial solar, a high-consideration trade purchase

Plumbing CRM, a B2B software decision

Same root query as earlier in this article, mapped to classes:

Read across the three and the useful thing is not the queries. It is that in every market, one or two classes are already owned by an institution you will never outrank, one or two are owned by nobody, and the second group is where the work belongs.

How we audit fan-out at Search Scope

The audit runs in five steps, and they are deliberately boring.

1. Start with the main query. Work out the real question behind it. Not the keyword, the decision the person is trying to make.
2. Break it into information needs. List what somebody would genuinely have to know before they could give a good answer. Do this in plain language first, before anything is phrased as a search.
3. Generate fan-out queries for each need. One or more searches per information need. This is the only step where the phrasing matters.
4. Remove duplicates. If two queries would return the same kind of answer, merge them. Ruthlessly. This step usually cuts a thirty-row list in half.
5. Map each branch to the source that should satisfy it. Your site, product documentation, third-party reviews, comparison publishers, forums, research, directories. Name the source type, not just the query.

Step four is where most fan-out reports fall apart, and step five is where the actual strategy appears. The first three steps are the part everyone already does.

Where this sits in the wider programme, and how it connects to measurement, is covered in the AI Entity Authority System.

Before and after: the same root query, two maps

The same root query produces two very different maps depending on which question you asked.

The old approach

Root query: best CRM for plumbers.

• best plumbing CRM
• best CRM for plumbers
• plumbing company CRM
• CRM software plumbers
• top plumbing CRM

Result: five queries.

The new approach

Root query: best CRM for plumbers.

• plumbing CRM pricing
• plumbing CRM with job scheduling
• plumbing CRM Xero integration
• plumbing CRM reviews
• Jobber vs Housecall Pro
• best CRM for small plumbing teams

Result: six queries, and more to the point, six different pieces of evidence.

The first list tells you to write one page and hope. The second tells you that your pricing page has a job, your documentation has a job, your review profile has a job, and at least two of those branches are not on your website at all.

We also check where those queries actually lead

Generating fan-out queries is only half the job, so we test the branches before we trust them. A branch that looks different on paper is not automatically a different retrieval pathway, and the only way to know is to run it.

So we run each branch and compare the top ten results it returns. If two queries come back with substantially the same URLs, they are not separate branches, whatever the wording suggests, and they get merged. The call we are making is whether the type of source changes, not whether some fixed percentage of URLs differs.

If a branch returns a different shape of source entirely, a forum thread, a set of product docs, a review platform, a comparison publisher, then it is genuinely representing a different pathway and it stays.

We also run the volatile surfaces more than once. Same location, same language, same device, at least 24 hours apart, then label each branch STABLE if it held across passes, VOLATILE if it appeared in one pass out of three, and UNTESTED if it has only ever been seen once. A single pass is not evidence of anything, and an audit built on one pass says so in its first line.

That is the step that turns fan-out analysis from an LLM brainstorming exercise into something you can actually measure and re-check in ninety days.

What we optimise after the audit

The audit produces a work list, not a content calendar. Depending on which branches are weak, it might tell you to:

• improve an existing page
• add a missing section to a page that is nearly there
• build a genuine comparison page
• publish original data, because nobody else has any
• fix or extend your product documentation
• get listed or mentioned on the third-party sources that own a branch
• build visibility in the forums and communities where experience questions get answered
• strengthen reviews and reputation on the platforms that already rank

Here is the part worth emphasising, because the alternative is programmatic spam: not every fan-out query needs its own page.

Google says this directly in its guidance on optimising for generative AI features. It names fan-out queries specifically as an example of the variation-chasing it warns against, notes that doing it to manipulate rankings breaches its scaled content abuse policy, and adds that it does not work anyway, because “a high quantity of pages doesn’t make a website higher quality”. Google also points out that its systems understand synonyms and general meaning, so they can connect a search to content that does not use the same precise words.

We hold ourselves to it. Our rule is one question, one answer, one page that owns it. A new wording gets filed against the question it already answers rather than turned into a page of its own. The September harvest described above is the example: every string in it resolved to a question we had already answered, so it produced no new pages at all. A fan-out map that ends with nothing to build is a valid result, not a wasted one.

Finding six retrieval branches does not mean publishing six near-identical pages. Sometimes the right answer is one new section, better documentation, or a mention on somebody else’s site.

The bigger idea

AI search is not just matching a question to a page. It is increasingly about assembling an answer from several pieces of information, some of which are not yours and never will be.

So a fan-out audit should measure coverage, not query count. And AI SEO should optimise for the places a system may need to retrieve from, not just for the original prompt.

If there is one line to take from this, it is the change in the question we ask ourselves:

We no longer ask how many fan-out queries we can generate. We ask how many different parts of the answer we are actually covering.

For the nerds: the terminology behind this

Everything above is deliberately written in plain language. The same ideas have formal names, and if you want to read further, these are the ones to search for.

Paraphrastic collapse is the failure mode described earlier: a set of sub-queries that look different but collapse onto the same retrieval intent.

Set-level optimisation is the idea that the quality of a fan-out is a property of the whole set, not of each query judged on its own.

Semantic diversity and marginal information gain are the two things we are informally measuring in step four of the audit. How different is this branch from the ones already in the set, and how much does adding it improve the answer?

Complementarity and coverage are the formal terms for what we call “does this branch add a different piece of the answer”.

Those last terms come from retrieval research. A 2026 Google Research paper, Efficient, Property-Aligned Fan-Out Retrieval via RL-Compiled Diffusion, presented at ICML 2026, frames fan-out retrieval as a set-valued problem: the system needs a collection of results that together satisfy higher-order properties such as diversity, coverage, complementarity and coherence, rather than picking the best single result for each query independently.

One caveat we want to be explicit about, because plenty of commentary is not. That paper is Google Research, and its experiments run on a fashion outfit dataset and a music playlist dataset, not on web search. It is not evidence that this architecture is what powers Google AI Mode. What Google has separately confirmed, in its product announcements and its own help documentation, is that AI Mode uses query fan-out.

So we are not claiming to have reverse-engineered anybody’s algorithm. The public product behaviour tells us fan-out is real. The research direction tells us how a serious retrieval team thinks about what makes a fan-out good. Put together, they give us a better way to audit retrieval coverage than counting keyword variations ever did. That is the whole claim.

Want this run on your own category?

If you are sitting on a fan-out report that looks thorough and has not told you anything you can act on, that is usually because it counted queries instead of information needs. We run this audit as part of our AI SEO work, and it tends to produce a shorter list of more useful work than clients expect.

If you want it run on your main commercial question, book a call and we will walk you through the branches before we talk about pages.