Building Pages Against Fan-Out Sub-Queries: A Content Brief Template for Hospitals

This article is for hospital and health-system marketing teams who already write briefs for service-line and condition pages and now want those briefs to account for how AI search answers are built. It assumes you know what a content brief is. It does not assume you have studied how AI Mode and AI Overviews retrieve pages.

The question it answers is practical: when a patient asks one long question, the system behind the answer may run several narrower searches, and your page can be cited for any one of them. How do you turn those narrower searches into an outline, an owner for each section and a review step that clinicians will accept? The template below is one way to do it. It is a method, not a set of results. Where it asks you to measure something, you run the measurement on your own pages.

What fan-out means for a brief

Google's documentation on AI features in Search says that AI Overviews and AI Mode may use a "query fan-out" technique, issuing multiple related searches across subtopics and data sources while generating a response. The same page says a page must be indexed and eligible to appear in Google Search with a snippet to be a supporting link, and that no special files, AI text files or schema.org markup are needed.

Two consequences follow for a brief. First, a page is no longer competing only for the head query. It competes for the sub-queries that a system might generate from it. A patient who types "is knee replacement worth it at 62" may trigger separate retrievals about recovery time, alternatives, cost ranges, surgeon experience and risks. Second, the unit that gets retrieved is often a passage or a section, so a brief written only at page level misses the point. The brief has to specify what each section answers on its own.

None of this replaces classic fundamentals. The AI search optimisation guide covers the wider approach. This post is narrower: the document your writers and clinicians work from.

Step 1: Discover the sub-queries

You cannot see Google's internal sub-queries. You can approximate them, and you should label them as approximations in the brief.

Sources that work in practice:

• Search Console queries for the target URL and its neighbours, filtered for longer, question-shaped phrases.
• People Also Ask and related searches for the head query, recorded with the date.
• Call and chat transcripts from the contact centre, tagged by service line. These reveal the questions patients ask after the first answer.
• AI answer observation. Run the head query on several AI surfaces and record what each answer covers, which sources it cites and which sub-questions it appears to address.

For the last source, use a fixed protocol. Pick 50 queries per service line: a mix of head terms, symptom phrases, comparison questions and doctor- or location-qualified questions. Run each on the same set of surfaces on the same day, logged out where possible, from a consistent location. Record the date, surface, whether your domain is cited, which competing domains are cited and which sub-topics the answer covers. Repeat after the page ships. Answers vary between runs, so treat a single observation as a data point and look for patterns across the set. Do not report a visibility change until you have repeated the test enough times to see the variation.

Step 2: Cluster into passages

Take the raw list and group it by the decision a patient is making. A typical grouping for a procedure page:

1. Is this the right service for me? Indications, who it is for, who it is not for, alternatives.
2. What happens? Assessment, preparation, procedure steps in plain language, anaesthesia type where applicable.
3. What does it cost and how is it paid for? Pricing approach, insurance and cashless processes, what is included.
4. Who does it? Clinician profiles, qualifications, registration numbers, hospital affiliation.
5. What are the risks and recovery? Stated generally and reviewed by the clinician.
6. What do I do next? Appointment routes, second-opinion pathways, contact options.

Each cluster becomes an H2 or H3. Each question inside a cluster becomes a passage of roughly 80 to 150 words that begins with a direct answer. Write the first sentence so that it makes sense if lifted out of the page. This is ordinary good editing, and it also helps a retrieval system that scores a passage rather than a document.

Step 3: The brief template

Use one table per page. The columns matter more than the rows.

Keep the table in a shared sheet, not in a document attachment. The point is that one row equals one passage, so a later audit can ask which rows were cited and which were not.

A worked example, clearly hypothetical

Suppose a 200-bed hospital in Pune is briefing a page on knee replacement. The head query is "knee replacement in Pune." The discovery pass produces perhaps forty sub-queries. After clustering, the brief might contain these rows (all illustrative):

Note what is absent: no outcome promises, no success rates unless the hospital can source and publish them, and no comparison claims that would breach advertising rules. The NMC advertising guidance applies to doctors' own pages, and hospital pages that profile doctors should be written with it in mind.

Step 4: Write for retrieval without writing for robots

Several habits help a passage stand alone.

Answer first, qualify second. The opening sentence states the answer; the next sentences give conditions. Clinicians often prefer the reverse, so agree the pattern with them in advance and explain that the conditions are still there.

Name the entity every time. Write "the cardiology department at the hospital" rather than "we" or "it" at the start of a passage. A passage lifted into an answer should not depend on a pronoun defined three paragraphs earlier.

One claim, one source. Where a passage states a guideline, link the guideline. Where it states hospital policy, state the policy and its date.

Use structure that already exists. Lists for steps, tables for comparisons, and headings that match the question. You do not need special markup. Google's documentation says no extra schema.org structured data is required for these features, though accurate markup remains useful for other reasons, as covered in the healthcare schema guide.

Keep the page indexable and fast. Eligibility starts with being indexed and snippet-eligible. A brief that ignores canonical tags, noindex directives or blocked resources can produce a perfect outline that never gets retrieved.

Step 5: Review workflow

A fan-out brief creates many small passages, so review has to be light enough to finish. A workable sequence:

1. The writer drafts all passages in the sheet, with sources.
2. The clinical reviewer reads the passages for their own specialty only and marks each as approved, amended or rejected. They do not rewrite the page.
3. The compliance lead checks claims, pricing statements and doctor references against the applicable advertising rules.
4. The editor assembles the page, checks that the answer-first pattern held and adds internal links.
5. The page owner records the publish date and refresh interval against every row.

Set a rule that no passage goes live without a reviewer's name and date in the sheet. This also solves a common failure: a page that was accurate when published and has been quietly wrong for a year.

Step 6: Measure against your own baseline

Re-run the 50-query test four to six weeks after publication and compare against the baseline. Look at these things:

• Was the page cited for any query where it was not cited before?
• Which sub-topics do the cited competitors cover that your page does not?
• Did any passage get cited that you did not expect? That tells you what the system treats as your page's strongest section.
• Did Search Console impressions for long, question-shaped queries change for the URL?

Expect noise. AI answers are not stable, and a small test can mislead. Record the numbers, but decide on direction only when the same pattern appears across several service lines.

Where to start

• Pick one service line with real enquiry volume and one existing page.
• Build the sub-query sheet from Search Console, call transcripts and a 50-query AI observation, and date it.
• Cluster into six decisions and draft one table row per passage.
• Name an owner and a clinical reviewer for every row before writing begins.
• Publish, then re-run the same 50 queries after a month and compare.

If your team wants a place to organise citations and publication workflows as this work scales, AiLLMz is built for that. For the wider programme, see our AI search optimisation service and the notes on citation building for AI answers. If you manage many location pages, read our piece on scaling location pages without thin content first, then use this brief for the pages that carry real clinical content.