Query Fan-Out for 'Knee Replacement Cost in Pune': Decomposing the Hidden Sub-Queries

This post is for orthopaedic surgeons, joint-replacement programme heads and the marketing teams who support them. It takes one query, "knee replacement cost in Pune", and shows how an AI search system is likely to break it into smaller questions, then maps each of those questions to something specific on your page. It assumes you already have a treatment page and want to know why it is or is not being used in AI answers.

The reason to do this is that a cost query is not a single question. A patient typing it is really asking several things at once: what will the total be, what changes it, what insurance covers, how long they will stay and what happens afterwards. A page that only lists a price range answers one of those. A system that builds a composite answer will look for other pages to cover the rest.

We use the idea of query fan-out because Google describes it for its own products. We also need to be careful about what is and is not known. Google does not show the sub-queries it issues for any given search. What follows is a method for inferring them, testing the inference and acting on what you find. It is not a report of results.

What query fan-out is, and what Google says about it

Google's own description of AI Mode says it uses a "query fan-out" technique, issuing multiple related searches concurrently across subtopics and multiple data sources, then combining the results into one response. Its documentation on AI features says AI Overviews and AI Mode may use the same approach, which lets the system surface a wider set of supporting links than a single classic search would.

The same documentation sets the entry requirement. A page must be indexed and eligible to be shown with a snippet. It states that there are no additional requirements or special optimisations, and no extra markup or machine-readable files are needed. This matters for how you read the rest of this post. We are not describing a hack. We are describing a way of making sure that, for each sub-question, there is a clearly written, indexable answer on your site, so that the retrieval step has something good to pick.

Step 1: Decompose the query by hand

Start with the head query: "knee replacement cost in Pune". Write down every question a reasonable patient or family member would need answered before they feel the number is trustworthy. Use real sources: call transcripts, appointment-desk logs, the questions patients ask at the first consultation. For this query the sub-queries usually fall into six groups.

1. Total cost and package scope. What does a package include, and what does it exclude? Is the figure per knee or for both?
2. Implant type. Which implants are used, what is the cost difference, and is a price ceiling applicable?
3. Hospital tier and room category. How do a general ward, twin sharing and a private room change the bill?
4. Surgeon and technique. Does the approach (conventional, computer-assisted or robotic) change the cost?
5. Insurance and payment. Does cashless approval apply, what do policies usually cover, and what are the out-of-pocket items?
6. Recovery and follow-up. How long is the stay, what does physiotherapy cost, and what follow-up visits are needed?

Group 2 includes a regulatory element. In India, the National Pharmaceutical Pricing Authority has set ceiling prices for knee implants since 2017, and has extended them since; a Medical Dialogues report covers the extension to September 2025. We could not confirm the position after that date, so any page that mentions it should link to the current NPPA notification and be checked by the hospital's finance and clinical teams before publication.

Step 2: Map each sub-query to a page element

The aim is for each sub-query to have a short, labelled, self-contained answer on the page. Self-contained matters because retrieval systems pick passages, and a passage that depends on three paragraphs of context to make sense is harder to quote accurately.

Notice what is absent: a promise about outcomes, a guaranteed price or a named competitor. Clinical statements need the surgeon's review. Pricing statements need finance sign-off and a "last reviewed" date. The cost of a surgery depends on the assessment, so write ranges as indicative, never as quotes.

Step 3: Test it with 30 queries

The test below is a method. It is how you find out whether your page set is being used. Run it before you edit anything and again afterwards.

Build the query set. Take the head query and write 30 variants: 10 head and short-tail ("knee replacement cost Pune", "TKR price Pune"), 10 with a modifier (insurance, robotic, both knees, senior citizen, cashless) and 10 as natural-language questions ("how much does a knee replacement cost in a good hospital in Pune with insurance?"). Include Hinglish and Marathi-influenced phrasing if your patients use it.

Run each query on the surfaces that matter. Google with AI Overviews, Google AI Mode, and one or two chat assistants. Use a clean browser profile and a Pune location, and note the date, because answers change.

Log the results. For each query and surface, record: whether an AI answer appeared, which sources were cited, whether your domain appeared, which sub-topics the answer covered, and which of those sub-topics your page also covers. A simple sheet with one row per query-surface pair is enough.

Read the sub-topics as inferred fan-out. If answers consistently open with price drivers, then insurance, then recovery, that is a good indication of the sub-queries being resolved. You cannot observe them directly, so treat the pattern as a hypothesis and look for it across many queries rather than one.

Score coverage. For each of your sub-queries, mark "answered clearly", "mentioned" or "absent" on your page. A gap that also appears among the cited competitors is the first thing to fix. Keep the AI-answer sheet separate from your ranking data; the two measure different things.

If you want to run this at scale without a spreadsheet, AiLLMz can track the same queries across AI surfaces on a schedule.

Step 4: Write for retrieval without writing for robots

A few rules make the cost page easier for any system, and for a human reader, to use.

One question per heading. "What is included in a knee replacement package?" is a better heading than "Package details". It states the sub-query directly.

Answer first, then qualify. Put the plain answer in the first sentence under the heading and the exceptions after it. For cost, that might be: "The cost depends mainly on the implant, room category and length of stay. Ranges below are indicative and are confirmed after assessment."

Keep numbers in tables with labels. A table row reading "Twin-sharing room, per night" is easier to quote correctly than a number in the middle of a paragraph. Add the date the figures were last reviewed.

Split what should be split. A page that tries to cover knee replacement, hip replacement and spine surgery in one place will blur the passages. Keep a single procedure per page and link to its siblings, as we describe in our guide to hospital service-line pages.

Use structured data only for what it fits. Medical procedure and FAQ markup can describe the page accurately, but Google's documentation is explicit that no special markup is needed for AI features. See the notes on schema markup for sensible use.

Step 5: Fill the gaps that other sources cannot

Your hospital has facts that aggregators do not: the actual inclusions of its package, the real room categories, the insurance desk process, the physiotherapy protocol. These are the passages that make a cost page worth citing. Aggregators tend to be generic.

Equally, there are things you must not say. Do not promise a price. Do not promise a recovery date. Do not use a patient story as proof of outcome without consent and clinical sign-off, and do not use the National Medical Commission's advertising restrictions as an afterthought; the NMC compliance handbook covers what a doctor's or hospital's content can and cannot claim in India.

Where a gap needs a third party, such as an insurer's list or a regulator's notice, link to the primary source instead of repeating it from memory. Primary links also help a reader check the facts.

Step 6: Re-test and interpret carefully

After the page is updated and re-crawled, rerun the same 30 queries on the same surfaces under the same conditions. Compare coverage and citations. Then be sceptical of what you see.

AI answers vary run to run, so a single appearance is weak evidence and a single absence is weak evidence too. Look at the share of queries where your domain is cited across the set, and at which sub-topics your page now supplies. Also watch Search Console: Google says AI feature traffic is included in the overall Web numbers, so there is no separate line to read. Pair the AI test with enquiry data from the call centre and forms, to see whether cost-intent enquiries are better informed on arrival.

A checklist for the cost page

• Each of the six sub-query groups has a labelled section.
• Inclusions and exclusions are listed, not implied.
• Price ranges are labelled indicative, dated and approved by finance.
• Implant categories are explained in plain language and reviewed by the surgeon.
• The implant price-ceiling sentence links to the current NPPA notice.
• Insurance and cashless steps are described, with the desk contact.
• Recovery information is framed as general and subject to clinical assessment.
• Surgeon profiles are linked and consistent with the page.
• The 30-query test is saved with date, surface and location.

For help structuring this across a joint-replacement programme, see our AI search optimisation service and the AI search guide.