Query Fan-Out: Turning One Pillar Into the Distinct Spoke Questions AI Actually Answers

You have a big topic and a blank calendar. Somewhere between the two, you are supposed to turn that topic into fifteen articles that do not repeat each other. This guide gives you the method: query fan-out content planning, where you take one pillar and decompose it into the specific sub-questions an answer engine would need covered, so every spoke earns its slot. It is for marketing leads who plan the queue and then have to defend it. By the end you will have a ranked, de-duplicated pillar to spoke questions map you can hand to a writer.

What query fan-out means for planning

Google describes query fan-out as a set of concurrent, related queries a model generates to request more information and fetch additional relevant results. AI Overviews and AI Mode may issue related searches across subtopics and data sources before they write an answer.

You do not need the retrieval mechanics to use this. Translate it into one planning question instead, and you have the whole basis of query fan-out content planning:

What distinct questions would a buyer need answered before the broad question feels complete?

That is the whole idea. Google's own illustration is a lawn full of weeds. The broad question pulls in narrower ones about the best herbicides, removing weeds without chemicals, and preventing weeds from coming back. Three different answers. Three different pages, potentially.

One caution before you start, because it saves you from writing a promise you cannot keep. Fan-out is probabilistic and engine-specific. No engine publishes the exact sub-queries it generates, and the same prompt can expand differently tomorrow. So the output of this method is not a leaked list of hidden queries. It is a defensible question set that reflects real user needs and the plausible subtopics AI search would cover on the way to an answer. That is a lower claim, and a much more useful one.

Five words you will use constantly, so let's fix them now:

• Pillar: the broad subject or buyer problem.
• Spoke question: one narrower question with its own distinct answer.
• Keyword variant: different wording for substantially the same need. One record, not one page each.
• Subtopic: a subject area. It only becomes a spoke once you write it as a question.
• Intent: what the reader is trying to do. Learn, compare, choose, troubleshoot, implement, calculate, or validate.

Step 1. Write your pillar as one buyer problem

Start by rewriting your topic as a question that names an audience, a situation, and an outcome.

The template that works: "How can [audience] achieve [outcome] when [constraint]?"

So instead of "AI search visibility," you write: "How can a marketing lead turn AI-search visibility gaps into a content plan?" Feel the difference? The second one tells you which questions belong and which do not. The first one tells you nothing.

Then record six things about that pillar:

1. The audience or persona.
2. The funnel stage.
3. The desired outcome.
4. The product or category context.
5. The constraints that change your advice: budget, team size, platform, industry, timeframe.
6. The decision the reader eventually has to make.

Done when: your pillar has one primary job and one clear audience, and you can say out loud what a complete answer has to help the reader understand or decide.

Where people go wrong: starting with a head term. "AI search." "Content clusters." "Topic authority." Those are labels, not problems. A label is too broad to sort questions against, so every candidate looks like it belongs. Rewrite the term as a buyer problem before you go any further.

Not sure your pillar is narrow enough? Try to name the decision at the end of it. If you cannot, it is still a label.

Step 2. Collect the real question wording

Here is the good news: you do not have to invent the questions. People are already asking them. Your job in this step is collection, not judgment. Resist the urge to cluster anything yet.

Pull from several evidence classes, so your set is not shaped by one tool's vocabulary:

1. First-party search demand. Search Console shows which queries already bring people to your site, with clicks and impressions. Export the query rows for the relevant pages, country, device, date range, and search type. The default Performance view covers the past three months, and you can change it.
2. Search-interest discovery. Google Trends gives you a largely unfiltered, anonymized sample of actual search requests. Work the Related topics and Related queries cards, and check the "Top" view for the terms with the greatest interest in your selected context.
3. Customer language. Sales calls, support tickets, customer interviews, community threads, chat transcripts, your own site search. Take the verbatim wording. Label the source and the date.
4. Existing AI-answer evidence. Whatever prompts your team already runs in ChatGPT, Perplexity, Gemini, or Google AI Mode. Save the answer, whether your brand was named, whether a page of yours was cited, which competitors showed up, and the date. Every answer is a snapshot, not a constant.
5. Bing AI Performance. Where you have it, the grounding queries, topics, intents, cited pages, and Citation Share show how your content gets used in Microsoft Copilot and partner experiences.
6. Your site and your competitors' sites. Inventory what already answers part of this subject, and note the competitor pages covering a question you have nothing for.

For every raw item, keep the original wording and add fields for source, audience, stage, intent, constraint, date, and how strong the evidence is.

Done when: you have a source-labeled bank of question-shaped inputs. Every item traces back to a customer, a search, an AI answer, your site, or a competitor, or it is honestly labeled as an editorial hypothesis.

Pro tip: do not tidy up awkward phrasing yet. "Is this worth it for a small team?" is not a clean keyword, and that is exactly why it is valuable. It carries an audience and a decision that the polished version hides.

Two caveats worth knowing now, so you read the data correctly later. Search Console stores top data rows rather than every row, and it filters some queries for privacy. A missing query row does not mean nobody asked. And Trends is directional, not a demand census. Autocomplete is the same: a language discovery signal, never proof of volume or importance.

Step 3. Expand across the question dimensions

Now you go looking for what your bank is missing. Most advice to break topic into subtopics stops right here, at "brainstorm some angles." A fixed matrix does better, because it shows you the holes you would never have thought to check.

Run your pillar through each dimension and ask what a reader would want:

For the AI-visibility pillar, that produces candidates like "What is AI-search visibility?", "Why does a page rank in search but never appear in AI answers?", "How should a small content team approach this?", "How does citation tracking differ from rank tracking?", and "Once I find a gap, do I refresh an existing page or write a new one?"

Fourteen dimensions does not mean fourteen spokes, and it is not a race to break topic into subtopics until the grid is full. Generate a candidate only when the combination is a real user need. An empty cell is information too: it usually means that dimension does not matter for this pillar.

Keep your buyer-stage labels consistent while you do it. Awareness questions define the problem. Consideration questions compare methods or tools. Decision questions test fit, implementation, proof, and constraints.

Done when: your candidate bank covers the dimensions that matter for this audience and this buying journey, and every candidate is written as a question or an explicit job to be done.

Where people go wrong: treating every modifier as a new topic. "AI visibility for SaaS," "AI visibility for B2B SaaS," and "AI visibility for software companies" are probably one need. They only split if the audience, the evidence, or your recommendation genuinely changes. Modifiers are how thin content gets made, one adjective at a time.

Step 4. Normalize the wording before you judge overlap

You cannot compare questions that are wearing different costumes. So give every candidate one canonical form, and keep the original phrasings as aliases underneath it.

Normalize these:

• Singular and plural.
• Punctuation, capitalization, and stop words.
• Abbreviations and their long forms.
• Brand, product, location, audience, and timeframe, moved into fields instead of the question text.
• Verbs like "track," "measure," and "monitor," but only when the requested action really is the same.
• Question shape, so "AI citation tracking" becomes "How do I track AI citations?" without changing what is being asked.

Do not normalize away the words that change the answer. "For agencies." "For ecommerce." "Without paid tools." "Versus." "Best." "How much." "Why." "After publishing." Those are not noise. They are the whole reason a separate page might exist.

A canonical record that holds up in review looks like this:

• Canonical question
• Original variants
• Primary intent
• Audience
• Buyer stage
• Required answer type
• Key constraint
• Evidence sources
• Existing URL, if any
• Competitor URL, if relevant
• Recommended content target
• Overlap decision and rationale
• Priority
• Owner and review date

That is more admin than a spreadsheet of keywords. It is also the difference between a backlog you can defend and a backlog you argue about every quarter.

Done when: every raw item maps to one canonical question, or it is rejected with a reason attached.

Common mistake: leaning on semantic similarity to do this for you. Two questions can share almost every word and still need two different pages. Two questions that share almost no words can need the same one. Vocabulary is a hint. Answer requirements are the fact.

Step 5. Merge or split with the same-answer test

This is the step that decides whether your cluster is sharp or bloated. It is also the step everyone rushes.

Here is the whole test, and it takes about four minutes per pair.

1. Write the one-sentence answer to each candidate.
2. Put the two answers side by side.
3. If the answer, the evidence, the audience, and the recommended action are all the same, merge them.
4. If only the wording differs, keep one canonical question and list the rest as aliases.
5. If the answer changes, split them.
6. Check your live site. If two existing pages chase the same intent and both underperform, look at consolidating or sharpening the difference.
7. Write down why you decided what you decided, so the next editor does not reopen the debate in six months.

Merge when they seek the same underlying answer, serve the same audience and stage, need the same evidence and examples, lead to the same action, and one page could answer both without burying either.

Split when any one of these is true: the reader's job changes (definition versus implementation), the answer format changes (comparison versus tutorial versus diagnosis), the audience or constraint changes your recommendation, the buyer stage changes the depth, the evidence source changes (a product spec versus an independent benchmark), one asks "why" while another asks "how" or "which" or "how much" and the answers will not sit together, or the page would have to make two competing calls to action.

SERP overlap is a useful supporting check. Semantic clustering groups terms by how similar the language is; SERP clustering groups them when engines rank many of the same URLs for both. Overlap tells you whether the wider ecosystem treats two queries as one page opportunity. It lags on new topics, it moves by location and date, and it does not replace your judgment.

The mistake that costs the most: "different keyword" is not the same as "different spoke." The only question that matters is whether a reader would expect a materially different answer. Two pages can share a keyword and both deserve to exist. Two pages with no shared words can be the same page twice.

Done when: every surviving spoke has one dominant answer, no survivor is a near-duplicate of another, and a writer can explain why each one is separate without checking the doc. This is the step that turns a keyword list into a real pillar to spoke questions map.

Step 6. Map each spoke to one content target

A surviving question is not automatically an article. Deciding the container now is what stops a good question from becoming the wrong kind of content.

Assign each spoke to exactly one of these:

• A short direct answer or definition section.
• An FAQ entry.
• A section inside a broader guide.
• A focused how-to article.
• A comparison page.
• A use-case page.
• A troubleshooting article.
• A calculator, template, or checklist, if you can genuinely support it.
• A refresh of a page you already have.
• No page yet, when the evidence is thin or the answer belongs somewhere else.

That last option is real. Use it. A candidate parked with a reason is worth more than a thin page published to clear the backlog.

Then, for each spoke, write down the exact question as it will appear near the top of the page or section, the answer promise in one sentence, the proof or first-party experience it needs, the audience and stage, the neighboring questions it should link to, whether it is a refresh or a new target, and the signal you will check later.

This is also where DeepSmith starts doing real work for you, once your editorial framework exists. In AI Visibility, the Prompts area stores the questions you track and reports mention and citation rate per prompt, with the full answer history. Discover Prompts generates a starter set from your stored product, persona, and buyer-stage context. Treat it as an evidence and validation layer sitting under your judgment, not a replacement for it. The method decides which questions are distinct. The platform tells you what happens when they get asked.

Done when: each spoke has one content target, one answer promise, one owner, and one stated relationship to your existing coverage.

Where people go wrong: turning every survivor into a standalone article. Some of your best content cluster spoke ideas are three-paragraph sections or FAQ entries inside a page that already ranks, and they still cover the subtopics AI search pulls into an answer. That is not a demotion. A crisp answer inside a strong page is easier to cite than a thin page nobody links to.

Step 7. Validate, rank, and keep the set alive

Three quick passes before anything reaches the calendar.

Pass A, the human check. Read the questions to a salesperson, a support lead, or an actual customer. Does this sound like something a person would ask? Would the promised answer help? Cut the internal jargon. Cut anything you cannot support.

Pass B, search and coverage. Check your Search Console and Trends evidence, then check your own site. Does a page already answer this? Look at competitor coverage for gaps, but do not assume that because a competitor has forty pages on something, your audience needs forty too. Coverage is a difference, not proof of quality.

Pass C, the AI-answer test. Run a representative prompt in the engines you care about. Record the exact prompt, the date, the platform, the answer, whether you were mentioned, which pages were cited, and which competitors appeared. A spoke passes when the question is useful to a reader and the answer test shows a real information or visibility opportunity. It does not pass just because a model produced a plausible-sounding phrase.

Then rank. Score each survivor 1 to 3 on seven factors: buyer importance, evidence strength, visibility gap, business relevance, distinctness from your existing pages, your ability to answer it genuinely well, and the effort plus freshness burden. Use the score to order the work, not to manufacture false precision. Your best items usually combine a real need, a clear gap, a distinct answer, and credible expertise.

DeepSmith's Content Map helps most at this pass. It crawls your site and your competitors' sites into one shared topic taxonomy, classifies every page by granular topic and funnel stage, and shows coverage gaps, untapped topics, page counts, and funnel distribution, re-checked every 24 hours. That is how you tell a genuine gap from a topic you already cover three times. Opportunity Agents go a step further and return ideas with the specific data point that justifies each one, which is what turns a backlog into something you can defend in a planning meeting.

Then keep the set alive. Re-run the overlap check whenever someone proposes a new page. Review the whole set when your product, positioning, competitors, or customer questions change. Keep a change log of what was added, merged, split, and retired, with the evidence behind each call.

Done when: you have a ranked, de-duplicated backlog with a validation record and a scheduled review date, and you can say what gets published first and why.

What to do next

Take one pillar. Just one. Run it through the seven steps this week and see how many of your content cluster spoke ideas survive the same-answer test. Most teams are surprised by how many merge, and relieved by how much clearer the remaining set is.

Then turn the approved, ranked questions into a production queue and put a review date on it. Buyer language moves. So do your competitors and the answers engines give.

Want to see the evidence layer under your question set? Start a free DeepSmith trial and test your spokes against real AI answers before you write a word.