One search now fires eight to twelve searches

When someone searches now, the system does not run their query. It runs a cluster of related queries it generates from theirs, retrieves passages for each, then writes one answer grounded in what came back. Google names this in its own documentation as concurrent, related queries. The industry calls it query fan-out.

That single mechanism explains most of what looks broken in your reporting. It is why a page ranking third for your main term gets skipped. It is why a page that does not rank in the top 100 gets cited. You are no longer competing for one string. You are competing across eight to twelve of them, and you never see the list.

How it works, concretely

Someone types a commercial question about, say, replacing a commercial roof. The system does not just search that phrase. It generates sub-queries around it: typical cost per square metre, how long the work takes, what happens to tenants during works, warranty periods, whether the existing structure needs assessment, common failure points in the old system, who is licensed to do it.

It retrieves passages against each of those. Then it assembles.

Your page might be excellent on the head term and silent on six of the eight sub-questions. A supplier's technical note, a forum thread and a rival's project write-up answer them instead. Those three get cited. You do not, despite ranking above all of them.

The unit that wins is a passage that answers one sub-question cleanly. Not a page that wins a keyword.

Why this breaks conventional keyword strategy

Traditional keyword work groups terms by search volume and intent, picks a primary term per page, and optimises the page around it. That model assumes one query maps to one ranked list.

Under fan-out, volume on the head term tells you how often the cluster gets triggered. It tells you nothing about which sub-questions decide the answer. And sub-questions frequently have almost no standalone search volume, because nobody types them. They exist only inside the machine.

So the keyword tool cannot show them to you. This is the part that catches out sophisticated teams: your research process is structurally blind to the thing that now decides citation.

How to see the fan-out anyway

You cannot read the system's internal query list, so you approximate it. Three methods, in order of effort.

Ask the answer engines to show their work. Run your commercial question in AI Mode, ChatGPT search and Perplexity. Look at what each cites. The cited sources reveal the sub-questions being answered, because each source was retrieved to satisfy one. Do this for 30 core questions and the pattern becomes obvious fast.

Interview your sales team. They already know the fan-out. Ask them to list every question a buyer asks between first contact and signature, in the order they get asked. That list is usually closer to the real cluster than anything a keyword tool produces, because both are modelling the same human.

Read your own support tickets and call transcripts. Same principle, more volume, less recall bias.

Then build the matrix. Rows are your 20 to 40 commercial topics. Columns are the sub-questions. Each cell is either we answer this directly somewhere on our site, or blank. The blanks are where citations go to other people.

Structure follows from that

Once you have the matrix, you face a real trade-off, and it is worth naming honestly because both options are defensible.

One deep page covering the whole cluster. Strong for authority, links and rank on the head term. Retrieval works fine on it as long as each sub-question is answered in a self-contained passage with a clear heading. The risk is burying answers inside a 4,000-word page where the relevant paragraph depends on context above it.

Separate pages per sub-question. Cleaner retrieval, easier to make each answer standalone, but you fragment link equity and create thin pages if the sub-question does not have enough substance behind it.

The rule that has held up: keep it one page when the sub-questions are steps in a single decision, split it when a sub-question is a decision of its own with its own buyer.

What matters more than the split is how the passage reads. Write sections that survive being lifted out. State the answer first, then the qualification, then the detail. If a paragraph only makes sense after the three above it, retrieval will not use it.

Google explicitly says you do not need to chop content into tiny fragments. Self-contained is not the same as small.

What this changes in reporting

Stop reporting position for the head term as the primary measure of a topic. Report coverage instead.

For each topic: how many sub-questions in the cluster do we answer, how many are we cited for across the main answer engines, and who holds the ones we do not. That is a number that moves when the work is right, and it maps to something a marketing director can act on.

Also track it per engine, because they fan out differently and cite different sources. One blended AI visibility score averages systems that disagree with each other.

The limitation worth stating

You cannot verify fan-out directly. Everything above is inference from cited sources, and the cluster changes as models change. Anyone selling you a tool that claims to output the exact sub-queries is modelling, not reading.

That is fine. The strategic conclusion does not depend on precision. Whether the system generates eight sub-queries or fourteen, the work is the same: know every question your buyer asks, answer each one directly, and write so a paragraph can stand alone.

The head term was never the customer. It was a label we put on them.