Google AI Mode Is Now the Default: What Query Fan-Out Means for How You Structure Pages

Google AI Mode became the global default at Google I/O on 19 May 2026, running on Gemini 3.5 Flash and serving a billion monthly users. The mechanic that changes how you build pages is query fan-out: AI Mode takes one question, silently splits it into many related sub-queries, retrieves results for each one, and synthesizes an answer from across all of them. That means your page no longer competes for a single keyword. It competes to be the best retrieved source for a fan of adjacent questions, and the pages that win are the ones structured so each section is a clean, self-contained answer to one of those sub-questions.

I have built fan-out retrieval pipelines for client RAG systems, so I want to explain what is actually happening under the hood and then give you a concrete restructuring playbook.

What is query fan-out in Google AI Mode?

Query fan-out is the technique where AI Mode decomposes a single user query into multiple parallel sub-queries, retrieves documents for each sub-query, then reasons over the merged result set to produce one answer. It is the same pattern teams like mine have used in production RAG for a while, now running at Google scale.

Here is the shift in plain terms. Old search took your query, matched it to documents, and ranked ten blue links. AI Mode takes your query, asks itself "what does this person really need to know to get a complete answer," generates a set of sub-questions, and runs retrieval for each one independently. A query like "is AI Mode bad for publisher traffic" might fan out into:

• how does AI Mode select sources


• does AI Mode cite the pages it uses


• how has organic click-through changed since AI Mode launched


• what page structures get surfaced in AI Mode answers

How is fan-out retrieval different from classic ranking?

Classic ranking scores whole pages against one query. Fan-out scores passages against many sub-queries, so a single page can be retrieved several times for several different reasons, or not at all if its sections blur together.

The practical consequence is that relevance is now measured per passage, not per document. In the RAG pipelines I build, the retriever chunks a document, embeds each chunk, and matches chunks to sub-queries. A 2,000 word page that rambles across one giant flowing argument produces messy chunks where no single chunk cleanly answers any one sub-question. A page broken into tight, labelled sections produces clean chunks, each of which can be a top match for its own sub-query.

The reward-for-breadth row is the one founders miss. Under classic SEO, stuffing a page with adjacent topics diluted your keyword and hurt you. Under fan-out, covering the adjacent questions well is exactly how you get surfaced more often, as long as each adjacent answer lives in its own clean section.

How do I structure a page to win fan-out retrieval?

Write each section as a self-contained answer to one specific sub-question, lead the section with the answer in one or two sentences, and make sure the page collectively covers the cluster of adjacent questions a reader would naturally ask next. That is the whole game.

Here is the playbook I use when I restructure a client's content for AI Mode.

1. Map the fan-out before you write. Take your target query and brainstorm the sub-questions a model would generate from it. You can do this manually or just ask a model to "decompose this query into the sub-questions needed to answer it completely." Those sub-questions become your H2s.

2. Make every section answer-first and self-contained. Open each H2 with a direct, quotable answer that makes sense even if it is the only thing retrieved. A chunk gets pulled out of context, so it cannot rely on the paragraph three sections up. I write the first sentence of every section assuming it might be the only sentence the model reads.

3. Cover entities explicitly. Fan-out retrieval leans heavily on entity matching. If your topic involves specific products, versions, people, or concepts, name them clearly instead of using vague pronouns. "Gemini 3.5 Flash" beats "the new model" every time a sub-query is about that entity.

4. Use real structure, not visual structure. Headings must be actual H2 and H3 tags, lists must be real list markup, tables must be real tables. The chunker reads the DOM, not how it looks.

A clean section template looks like this:

## Does AI Mode cite the sources it retrieves?

Yes. AI Mode shows a small set of cited links alongside its
synthesized answer, and those citations map to the passages its
fan-out retrieval actually used.

[2-4 sentences of specific detail, self-contained, naming the
real entities involved so an isolated chunk still makes sense.]

If you want the retrieval to actually see this, the HTML behind it has to be clean too:

<article>
  <h2 id="ai-mode-citations">Does AI Mode cite the sources it retrieves?</h2>
  <p>Yes. AI Mode shows a small set of cited links alongside
     its synthesized answer...</p>
</article>

Flat, semantic, one idea per section. That is what chunks well.

Does my JavaScript site even get retrieved?

Only if the answer text is in the HTML the crawler receives, not injected later by client-side JavaScript. This trips up a huge number of React and Next.js builds, and it is the first thing I check before any fan-out tuning.

Fan-out retrieval cannot chunk content it never received. If your section answers are rendered client-side after hydration, many crawlers see an empty shell and your beautifully structured sections are invisible. The fix is server-side rendering or static generation for any page you want surfaced. I dug into exactly why this happens and how to confirm it in why your Next.js SPA is invisible to AI crawlers ↗, and it pairs directly with the structure work here. Get the rendering right first, then the section structure, because perfect structure inside an unrendered page wins nothing.

A quick way to check what the crawler actually gets:

## Compare rendered HTML against the raw response
curl -s https://yoursite.com/your-page | grep -c "<h2"
## If this returns 0 but your page clearly has H2s,
## your headings are being injected by JS. Fix rendering first.

This is also why performance still matters under AI Mode. Slow, heavy pages get crawled less thoroughly, and the move to stricter Core Web Vitals thresholds means a sluggish React page can quietly lose retrieval coverage. I wrote up the current thresholds and concrete React fixes in INP is now an equal ranking signal ↗.

What does a fan-out content plan look like in practice?

A fan-out content plan starts from one core topic, expands it into a tree of sub-questions, and assigns each sub-question its own section, with the highest-intent ones getting their own pages. Think clusters, not isolated articles.

Here is how I lay it out for a client. Suppose the core topic is "AI Mode for SMB websites."

Core: AI Mode for SMB websites
├─ What is AI Mode and how does it pick sources   → section
├─ How fan-out changes my page structure          → section
├─ Does my JS site get retrieved                   → section + link to sibling
├─ How do I measure AI Mode visibility             → section
├─ What content should each service page cover     → dedicated page
└─ How do I structure FAQs for retrieval           → dedicated page

Every node is a sub-query someone will actually ask. Sections handle the close-in questions on one page. Separate pages handle the high-intent questions that deserve depth and their own URL. The cluster links to itself, which both helps users and gives the retriever clear entity relationships to follow.

This is also where structured data earns its keep. FAQ and article schema give the retriever explicit question-answer pairs that line up neatly with generated sub-queries. I do not treat schema as a ranking trick. I treat it as handing the model pre-chunked, pre-labelled answers.

How do I measure if any of this is working?

Stop watching keyword rank alone and start tracking whether your pages appear as cited sources in AI Mode answers for your target sub-questions. The metric moved from position to inclusion.

In practice I track three things for clients:

• Citation presence. Run your target queries and their obvious sub-queries through AI Mode and log whether your domain shows up in the cited sources. Do this on a schedule, since results shift.


• Section-level retrieval. When you do get cited, note which section was pulled. That tells you which of your answer-first blocks are landing and which need tightening.


• Referral quality over volume. AI Mode sends fewer but more qualified clicks, because the user has already read a synthesized answer. I weight conversion rate from AI Mode referrals far more heavily than raw sessions.

If you are staring at a React or Next.js site and are not sure whether it is even being retrieved, let alone structured for fan-out, this is the kind of work I do day to day. My RAG development service ↗ is built on the same retrieval internals AI Mode now runs at scale, so I can audit what the crawler sees and rebuild your pages around the sub-questions that matter. If that is useful, my contact page ↗ is the quickest way to reach me and I read everything that comes in.

The short version: AI Mode rewards pages that read like a well-organized set of answers to a family of related questions. Map the fan-out, give each sub-question its own clean self-contained section, name your entities, make sure the HTML actually renders, and you will get surfaced for far more than the one keyword you used to chase.