How long is a typical conversational search query?

Typed Google queries average roughly 3-4 words. Queries put to ChatGPT Search and Perplexity routinely run 15-30 words and often contain a constraint clause and a stated context, which is why they almost never match an exact-match keyword target.

What is query fan-out and why does it matter?

Fan-out is the decomposition step where an answer engine rewrites one conversational prompt into several narrower retrieval queries before searching. Your page is matched against those rewritten sub-queries, not against the user's original sentence, so you optimize for the decomposition rather than the prompt.

Should I still do keyword research for conversational search?

Yes, but at the level of constraints rather than phrases. Mine Search Console for the modifiers that recur across long queries — budget, location, team size, comparison-against — and build sections that resolve each constraint explicitly.

Why does my page rank on Google but never get cited by Perplexity?

Ranking proves you match a keyword. Citation requires that a specific passage answers a decomposed sub-query in a self-contained way. Pages that are structurally one long argument rank fine and cite badly because no single chunk stands alone.

Do follow-up questions in a chat session affect which pages get retrieved?

They do. Follow-ups carry the prior turn's context into the new retrieval, narrowing it — a second turn asking 'what about for a two-person team' fetches passages about small-team constraints specifically. Content that anticipates the second and third turn gets retrieved twice.

Conversational Query Structures for ChatGPT & Perplexity | MarketLens

Somebody typing into Google writes three words. Somebody typing into ChatGPT writes a paragraph. That gap is the whole discipline of conversational query optimization, and most content strategies have not adjusted for it.

The instinct is to chase longer keywords — target the long tail, add more question-shaped H2s. That is half right and it misses the mechanism. Answer engines do not retrieve against the user’s sentence. They decompose it first, into several narrower queries, and retrieve against those. Your content is being matched to a query the user never typed.

This piece covers what that decomposition looks like, how to find the sub-queries that matter for your pages, and how to structure sections so they get retrieved by more than one of them.

The shape of a conversational query

The queries worth designing for all share one feature: a constraint clause. A budget, a team size, an existing tool, a level of expertise — “best X for a small team”, “how do I X without Y”, “what should I use instead of Z”, “is it worth X if I already have Y”. Plain “what is X” is a solved commodity that every category leader already owns. Being the page that resolves “…for a two-person team already on Shopify” is where retrieval share is still available, and the rest of this piece is about how to build for that.

What actually happens between the prompt and the retrieval

The naive model of AI search is: user asks, engine searches the sentence, engine summarizes results. That is not what happens.

The real sequence, roughly consistent across ChatGPT Search, Perplexity and Google’s AI Overviews:

User prompt (24 words)
      │
      ▼
[ Intent parse ]  ──► extracts: task, constraints, entities, expertise level
      │
      ▼
[ Query fan-out ] ──► rewrites into 3-6 narrow retrieval queries
      │                 q1: "static site generator small team"
      │                 q2: "Hugo vs Astro build speed"
      │                 q3: "static site generator no javascript required"
      ▼
[ Parallel retrieval ] ──► each sub-query hits the index independently
      │
      ▼
[ Passage assembly ] ──► top chunks from each sub-query pooled
      │
      ▼
[ Synthesis + citation ] ──► answer written, sources attached per claim

Two consequences fall out of this diagram, and they are the whole strategy.

First: you compete per sub-query, not per prompt. A page that comprehensively answers the full prompt but has no passage that cleanly answers q3 loses q3 to a thinner competitor who happens to have a section headed “Do you need JavaScript?”. Coverage beats depth at the retrieval stage.

Second: citations are attached per claim, not per answer. You can be one of six sources and get cited on the one sentence that matters, or be the best overall source and get cited on nothing because your passages were paraphrases of what three other sources also said. This is the same dynamic that decides which handful of sources ChatGPT Search attaches to an answer.

Finding the sub-queries your pages should own

You cannot see the fan-out directly. You can reconstruct it well enough with three inputs.

Search Console long-tail residue. Filter your queries report to those containing 6+ words. These are the typed queries closest in shape to spoken and chatted ones. Sort by impressions with low CTR — those are queries where you are retrieved but not chosen, which usually means you match topically but do not resolve the constraint.

Prompt the engines directly. Ask ChatGPT Search a realistic 25-word prompt in your category and read which sources it cites and for which claims. Then ask the obvious follow-up. The second turn is where narrow retrieval happens, and it exposes exactly which sub-queries the engine considers distinct.

Autocomplete constraint mining. Google’s suggestion API returns constraint completions if you seed it with a preposition. Query "project management tool for " rather than "project management tool" and you get the segment axis: for freelancers, for construction, for remote teams. Each of those is a fan-out target.

Here is the pattern I use to pull that programmatically:

import requests, itertools

BASE = "https://suggestqueries.google.com/complete/search"
SEEDS = ["static site generator for ", "static site generator without ",
         "static site generator vs "]

def suggest(q):
    r = requests.get(BASE, params={"client": "firefox", "q": q}, timeout=10)
    return r.json()[1]

rows = list(itertools.chain.from_iterable(suggest(s) for s in SEEDS))
for phrase in sorted(set(rows)):
    print(phrase)

Three seed prepositions — for, without, vs — map the constraint space of almost any commercial topic in about thirty seconds. Those completions become your H3 list.

Structuring a section so it survives decomposition

A sub-query retrieves a passage, typically 200-400 tokens of contiguous text. The unit of optimization is therefore the section, not the page.

A retrievable section has four properties:

It opens with the answer. First sentence states the conclusion; the reasoning follows. Retrieval scoring weights early tokens, and a section that spends 80 words building to a point will be scored on the build-up.

It names its own entities. No “it”, “this approach”, “the above”. A passage extracted from the middle of your page has no antecedent for a pronoun. Write “Hugo’s build step” where you would naturally write “it”.

It restates the constraint in the heading. ### Is Hugo a good fit for a two-person marketing team? matches a fan-out sub-query far more directly than ### Team size considerations. Headings are weighted heavily in chunk embeddings because they are often prepended to the chunk text.

It is 120-250 words. Shorter and it lacks the signal to score well; longer and the chunker splits it, halving your answer.

Anticipating turn two and turn three

Single-turn optimization is table stakes. The differentiator is multi-turn, because conversational sessions rarely stop at one question and each follow-up runs a fresh retrieval carrying the prior context.

The predictable turn sequence in commercial categories:

Turn	User intent	What the engine retrieves
1	Orientation — “what are my options for X”	Overview and category-definition passages
2	Constraint application — “which for a team my size”	Segment-specific passages, comparison tables
3	Objection — “but doesn’t X have problem Y”	Limitation, failure-mode, and caveat passages
4	Execution — “how do I actually set that up”	Step-by-step and code passages

Most content covers turns one and four and skips two and three entirely. Turn three is the most valuable and the most neglected: a page that honestly documents where its recommendation fails is the only page in the retrieval pool that can answer an objection query. Being the cited source on “doesn’t Hugo struggle with X” is worth more than being one of ten sources on “what is Hugo”.

Practically: every recommendation section should be followed by a short, honestly-titled limitation section. ### When Hugo is the wrong choice will get retrieved by objection queries from every engine, and it costs 150 words.

Why conversational traffic converts differently

Volume is the wrong metric here. Conversational queries carry the constraint the user actually has, which means someone arriving from an AI citation has already had their situation matched against your content by the model. The qualification happened upstream, before the click — so judge this traffic on what it does after it lands, not on how much of it there is.

That changes the economics of long-tail work. A section targeting a constraint that generates forty visits a month is not a rounding error if those forty visitors pre-qualified themselves through a three-turn conversation. It also fits a wider pattern in how people use search results: Pew’s behavioural study of real search sessions is a useful corrective to treating raw click counts as the measure of a page’s worth.

The audit questions that matter

Run these against any page you want cited:

Pick your page’s core topic. Write five realistic 25-word prompts a user would type. Decompose each into three sub-queries.
For each sub-query, does a single contiguous passage on your page answer it without needing the surrounding page? If not, that is a gap.
Does any heading on the page contain a constraint word (for, without, instead of, when not to)? If zero, you are optimized for turn one only.
Open a chunk of your page at random from the middle. Does it contain unresolved pronouns or “as mentioned above”? Each one is a decapitated reference.
Is there a limitation section? If not, you cannot win turn three.

Most pages fail three of five. Fixing them is additive editing — you are adding constraint-titled H3s and de-pronouning existing prose, not rewriting.

Next step

Take your single highest-intent page and add two sections this week: one titled with a real constraint your buyers have (for teams under 10, if you're already on WordPress) and one honest limitation section. Then ask ChatGPT Search and Perplexity a matching conversational prompt in a fresh session and see whether you appear.

If you are doing this for a local or service business, pair it with the foundational GEO checklist for local businesses — constraint-titled sections work best on top of a site that is crawlable and correctly described in the first place.

A MarketLens Premium audit maps this across the whole site — pulling the long-tail residue from Search Console, reconstructing the fan-out per page cluster, and returning the specific H3 sections missing from each. Either way, the fastest thing you can do today is write the limitation section nobody else will.

Conversational Query Structures for ChatGPT & Perplexity