How AI Search Retrieves, Reranks and Cites Passages

The short answer: AI search does not cite a page as a whole. It cites a passage it retrieved for one of several sub-queries, kept after a second ranking pass, and chose to quote or paraphrase. Most pages that are indexed but rarely cited fail for passage-shaped reasons: the answer is buried mid-paragraph, the passage opens with “it” and means nothing alone, or the page covers one sub-question while the engine asked five. This guide walks the pipeline stage by stage, then gives one audit checklist per stage.

What Is Documented and What Is Inferred

No engine publishes its retrieval or ranking internals, so it pays to separate the few documented facts from inference. The documented parts:

• Google runs query fan-out. Google’s May 2025 I/O post says “AI Mode uses our query fan-out technique, breaking down your question into subtopics” (Google, AI in Search). Search Central’s AI features and your website page says AI Overviews and AI Mode may issue multiple related searches across subtopics and data sources.
• Eligibility is ordinary Search eligibility. The same Google page says a supporting link must be indexed and eligible to be shown in Search with a snippet, and that there are no additional requirements or special optimizations. The usual preview controls (nosnippet, data-nosnippet, max-snippet) limit what can be shown.
• Other engines need their search crawler allowed. OpenAI says sites that opt out of OAI-SearchBot are not shown in ChatGPT search answers (OpenAI crawlers). Perplexity says PerplexityBot is the crawler that surfaces and links sites in its results (Perplexity crawlers).

Everything else here (chunking, reranking, how a passage gets quoted) is general retrieval-augmented generation (RAG) practice plus what you can observe in rendered answers. Treat it as a working model, not engine specifications. Where we name a metric or a score, it is our own heuristic for organizing an audit, not an industry standard.

The Pipeline at a Glance

Stage 1: Chunking and Retrieval

Most RAG systems don’t embed or score a whole page. They split it into passages, index each one, and retrieve the passages closest to the query. A page is a container for many independent retrieval units, and its citation chances are roughly the sum of how good each unit is on its own. A long page can hold a dozen passages of which only two are worth retrieving.

How pages tend to get split

Engines don’t publish their splitting rules, but common chunking approaches use the page’s own structure first and fall back to size limits:

1. Headings. H2 and H3 boundaries are the cleanest split points. A page with one H2 followed by a wall of prose leaves the splitter to guess.
2. Paragraphs. When a section is long, the paragraph break is the next natural boundary.
3. Lists and tables. Long lists may be cut partway, and the second half loses the sentence that introduced it.
4. Sentence boundaries. With no structure to use, a splitter breaks at a sentence near its size limit, wherever that falls.
5. Fixed windows. The crudest method cuts at a set length, sometimes mid-sentence, often with overlap between windows.

You can’t control which method an engine uses, but you can write so every method lands on a sensible boundary: one topic per heading, short paragraphs, and lists introduced by a sentence that says what they list.

What a retrievable passage looks like

• Bounded by a heading. It starts at or just after an H2/H3 and ends before the next one, so the heading and the passage travel together.
• One claim. One main point, one or two sentences of evidence (a named source, a specific figure, a concrete example), and a closing sentence that resolves it. A paragraph that compares three tools, three prices and three use cases at once is three passages pretending to be one.
• Self-anchoring opening. The first sentence names its subject. “Google’s AI Mode splits a question into sub-queries before it searches” works alone; “It also does this for follow-ups” does not. A retrieved passage arrives without the paragraph above it.
• A finished ending. The claim and its evidence sit in the same section. If the proof is in the next section, a retrieved passage carries a claim with no support.
• Sensible size. A few short paragraphs per heading. A single 80-character bullet carries too little context; a screen-long paragraph will be split somewhere you didn’t choose.

The five chunk failures that repeat

• Wall of prose. One long paragraph that a splitter cuts at an arbitrary point. Fix: break it at the topic shift and add an H3.
• Bullet fragments. A dozen short bullets with no context. Fix: group them into a few clusters, each with an introductory sentence.
• Context-stripped openings. Sections that start “Another reason is” or “On top of that”. Fix: restate the subject in the first sentence.
• Mid-thought endings. The claim in one section, the evidence in the next. Fix: keep them together.
• Parallel multi-claim passages. Several comparable claims in one paragraph. Fix: one heading per claim.

None of this is against human readability. Clear headings, self-explaining section openers and one point per section read better for people too. What it works against is the long, flowing magazine cadence many style guides still reward.

Finding which passage was cited

Some citation links carry a text fragment (#:~:text=), which tells the browser to scroll to and highlight a specific span. When a citation includes one, open it with the fragment intact: the highlighted text is the passage the engine pointed to. When it doesn’t, match the claim in the answer back to your page by hand. Either way, log the passage, not just the URL. Text fragments stop matching when the text changes, so an old fragment that no longer highlights anything is itself a sign the passage was edited.

Stage 2: Query Fan-Out

Query fan-out means the engine does not search the typed question once. It writes several related searches, retrieves for each, and composes one answer from the combined results. Optimizing only for the head query leaves the other branches to whoever answers them.

The three branch types

You can’t see the sub-queries, but on commercial questions the parts of an answer usually fall into three kinds of branch:

• Specification branches. A constraint inside the question (“under $100”, “for small business”, “without coding”). These pull from pricing pages, comparison tables and spec sections.
• Use-case branches. The scenario implied by the question (“for Shopify”, “for ads”). These pull from use-case pages, how-to guides and templates.
• Comparison branches. Named alternatives (“A vs B”, “A alternatives”). These pull from comparison and review pages.

“Best AI UGC tool for Shopify under $100” plausibly branches into a price question, a Shopify question and a “best tools” comparison. A site with one page that answers the head query well can still be absent from two of the three.

Inferring your fan-out tree from citations

1. Capture. For each priority question, record the cited URLs, the cited claims and any rationale text, per engine.
2. Cluster. Group the cited claims by what they answer: a constraint, a scenario or a comparison. Each cluster is an inferred branch.
3. Score coverage per branch. Yes (a page whose main intent is that branch), partial (a page that mentions it in passing) or no.
4. Summarize. We use a simple coverage ratio: branches marked yes divided by inferred branches. It is a tracking number for your own trend, not a benchmark.
5. Turn gaps into a backlog. Brief each gap with the actual cited text competitors hold on that branch.

Sibling pages, and when not to make one

The response to a real gap is a focused page whose main intent is that branch, linked to and from the main page. The traps are the opposite of the gap:

• Cannibalization. A “sibling” so close to the main page that both compete for the same sub-query. A new page needs a different intent, not a different headline. Near-duplicate pages split signals and may not be indexed at all, which is why this guide replaced a dozen overlapping articles.
• Chasing every branch. Long-tail variants belong as sections on an existing page. Spreading effort over many thin pages lowers the quality of each.
• A stale map. Answers change as engines and competitors change. Re-check the branches for your priority questions on a regular cadence, not once.
• Uneven freshness. Refreshing the main page while its siblings age leaves stale pages on the branches.

Which branch to fill first

Three questions order the backlog: does the branch carry a prominent part of the answer (it appears early or recurs across engines), does the answer show images for it (a page with good images can be shown there too), and is the current cited source weak (a thin listicle is easier to displace than the category’s reference page)?

Stage 3: Reranking

In most RAG systems, first-stage retrieval is fast and broad: it pulls many candidates by embedding similarity or keyword match. A reranker then reads the query and each candidate together (often a cross-encoder model) and reorders them, and only the top few reach the model that writes the answer. A passage can be retrieved and still never appear. You can’t see the candidate list, so reranking is diagnosed indirectly: you rank in classic results or the passage clearly matches, but a competitor’s passage gets cited instead.

What tends to survive a second look

• Specific claims. A sourced figure, a named standard or a concrete example beats “much faster”. Only use numbers that are true and sourced; a made-up statistic is easy to quote and a liability once quoted.
• Named entities. Name the product, brand or standard in the passage itself instead of relying on “it” or the page title.
• Claim first. Put the answer in the first sentence rather than after a topical warm-up.
• Consistent dates. If the page shows an updated date, it should match dateModified in the structured data, as Google’s byline date guidance asks, and only change when the content changes.

Structured data helps engines understand a page, but Google states that no special markup is needed for AI features, and no engine documents schema as a reranking input. Add the markup that accurately describes the page and don’t expect it to rescue a vague passage.

Reading a decline

When a passage that used to be cited stops appearing, three causes cover most cases, and each needs a different fix:

• It went stale. The facts or dates aged. Fix: update the content and the dates together. Date problems are page-wide, so fix the whole page, not one passage.
• A competitor got sharper. Your passage is current, but another source makes the same point more specifically. Fix: rewrite the opening sentence against the text that now gets cited.
• The engine is confused about who you are. The passage matches, but the engine attributes the topic to another entity. Fix: entity work (consistent names, sameAs links, author pages). See brand entity disambiguation.

Most fixes at this stage are edits to one to three sentences, not page rewrites. Rewriting a whole page risks breaking the passages that were already working.

Stage 4: Synthesis, Quoted or Paraphrased

The synthesis stage is the only one users see. The model writes the answer from the surviving passages, and each source ends up in one of a few observable states: its wording is quoted or closely reproduced next to a link, its idea is paraphrased with a link, or it appears only in a list of sources below or beside the answer. The first two are where attention goes.

What pushes a passage toward being quoted

• Self-containment. The model sees the passage without its neighbors. A claim that depends on the previous paragraph gets paraphrased or dropped.
• Claim-shaped first sentence. A useful template: [entity] [verb] [specific claim] [qualifier]. “OAI-SearchBot must be allowed in robots.txt for a site to appear in ChatGPT search answers” is quotable. “There are some interesting points about crawlers” is not.
• Distinctive, precise phrasing. Generic wording is easy to restate in the model’s own voice. A precisely named concept or a crisp definition is harder to paraphrase without losing something.
• Clear authorship. A named author, publisher and date make a source easier to attribute.

Three synthesis failures and their fixes

• Paraphrased because the opening is a warm-up. The substance is used, the words are not. Fix: rewrite the first sentence into the claim template above.
• Listed only, because it needs context. Showing the passage alone would produce a sentence nobody can parse. Fix: add the subject and the qualifier the surrounding text used to supply.
• Dropped for a more distinctive competitor. Same substance, blander wording, so the engine used the other source. Fix: say it more precisely, with a named concept or a concrete example.

Diagnose before editing. A context problem rewritten as a warm-up problem will still end up in the sources list.

Position matters

Readers scan answers top-down, so a source linked in the first sentence gets more attention than one linked at the end. If you want one number for this, weight each citation by position and by state (quoted above paraphrased above listed). The weights are your choice; keep them fixed so the trend means something.

Stage 5: How Citations Are Displayed

After synthesis, the citation is rendered: a sentence or span is linked or highlighted, and a source card shows the publisher. This is the surface a person decides to click on.

Answer anchor sentences

When an engine links or highlights one sentence from your passage, it helps if the right sentence is the obvious choice. A sentence makes a good anchor when it:

• reads correctly with nothing around it (no “as described above”, “this approach” or dangling pronouns);
• carries the specific claim and the named entity, early in the sentence;
• uses the words of the question early, so the linked text visibly answers it;
• is a normal length, short enough not to be cut off on a phone;
• avoids stacked em-dashes, semicolons and parentheticals that give a highlighter several places to cut.

Anchor losses come in three kinds: the wrong sentence was picked (the lead sentence was framing, so fix the lead), the right sentence was cut off (shorten or simplify it), or a competitor’s sentence is simply the better answer (sharpen yours). Anchors also change without any edit on your side, when engines change models, when the intent behind a query shifts, or when a competitor publishes. So compare several captures over time before reacting to one.

Citation cards

The source card is assembled from page and site signals, and most of them are documented for Google Search:

• Favicon. Google asks for a square icon of at least 8x8px, recommends larger than 48x48px, supports one favicon per hostname, and needs both the icon and the home page crawlable (favicon guidelines). A missing or blurry icon reads as an unknown source.
• Site name. Google picks a site name from the home page and recommends WebSite structured data with name and optional alternateName, using the same name consistently (site names). If the footer, logo text and markup spell the brand three ways, expect a bare domain on the card.
• Title. Google truncates title links as needed, typically to fit the device width, and asks for unique, descriptive titles without boilerplate (title links). Put the distinctive words first, so a cut-off title still says what the page is.
• Date. A visible “Updated” date that matches dateModified. Conflicting dates give an engine reasons to show none, or the wrong one.
• Thumbnail. Engines that show images on cards often use the page’s og:image or a prominent image on the page. Make the og:image a relevant image, not a generic banner.

Cards change without edits too: a redesign changes what is shown, a site name is re-picked, a different page image is used, or another source is ordered above you. Record what the card showed each time so you can tell which happened. Favicon and site name are site-level fixes that improve every card at once, so do them first.

Rationale snippets

Some answers include a short line next to a source saying why it was used, such as “best for sensitive skin” or “the guide explains the calibration step”. These rationale snippets are usually close to text on the cited page, so you can match them to a passage. They show which claim or use case the engine valued, not only that it cited you. When rationale is present, capture it word for word and score it on five questions:

• Use case: does it name a concrete buyer situation?
• Claim: does it carry a specific fact, source or step?
• Visual: does it refer to images?
• Comparison: does it compare to a named competitor?
• Freshness: does it refer to recency?

Three uses repay the effort. The competitor mirror: the rationale on queries where competitors are cited shows which framings the engine treats as good answers in your category. The drift trigger: when the rationale on your cited page moves off your strongest claim, refresh that passage before the citation itself goes. The engine delta: the same query often gets different rationale on different engines, which tells you which format of the same claim each one picks up. Don’t over-read tiny samples. A missing rationale on a cited page is itself a sign the engine found nothing clean to lift.

Running It: One Capture, One Backlog

Every stage above reads from the same observation: a rendered answer for a priority question on a given engine. Capture it once and analyze it five ways instead of building five pipelines.

• One priority question set. The questions that matter commercially, kept stable and revised quarterly, not per audit.
• One capture record per answer: question, engine, date, each cited URL, its position, its state (quoted, paraphrased, listed), the anchor text, the text fragment if any, the card contents and the rationale text, stored verbatim. Third-party AI-visibility trackers can collect much of this; check that they don’t truncate the text.
• One backlog, grouped by page so a writer gets one coherent brief per URL. Each brief contains the failing check, the current passage and the competitor text that is cited instead.
• A cap set by throughput. Only queue what the team can edit well that week; the rest waits.
• A re-check. Re-run the same question on the same engine a few weeks after the edit and note whether the cited text changed.

Order of work: fix passages on the pages you already have before adding URLs, because a new page with the same structural problems inherits them. Then fill the fan-out gaps that are real. Then do the display fixes. Favicon, site name and dates are cheap and site-wide.

Audit Checklists by Stage

One list per stage. Run them in order. A page that fails stage 1 checks won’t benefit from stage 5 polish.

Retrieval and chunking

• Search crawlers allowed: Googlebot, OAI-SearchBot, PerplexityBot (and any others you want in).
• Page indexed and eligible for a snippet; no accidental nosnippet or data-nosnippet on the answer.
• Answer text is in the HTML, not only in images or behind a click.
• One topic per H2/H3; no section is a single long paragraph.
• Every section’s first sentence names its subject.
• Claim and evidence sit in the same section.
• Lists are introduced by a sentence and kept short, or grouped.
• For each cited page: the passage that was cited is logged, by text fragment or by hand.

Query fan-out

• Priority questions listed, each with its inferred branches (specification, use case, comparison).
• Each branch marked yes, partial or no for coverage.
• Every “yes” page has a distinct main intent; no two pages compete for one branch.
• Long-tail variants handled as sections, not new pages.
• Siblings and main page link to each other.
• Siblings refreshed on the same schedule as the main page.
• Branch map re-checked on a set cadence.

Reranking

• Each key passage opens with its answer.
• Product, brand or standard named in the passage, not only in the title.
• Vague claims replaced with specific, sourced ones; every number has a source or is cut.
• Visible updated date matches dateModified, and both change only with real edits.
• For a lost citation: cause identified (stale, outcompeted, entity confusion) before editing.
• Edit scope matches the cause (page-wide for dates and entity, passage-level for wording).

Synthesis

• Each cited source logged as quoted, paraphrased or listed only, with its position.
• Key passages make sense with no surrounding text.
• First sentences follow [entity] [verb] [specific claim] [qualifier].
• Key concepts named precisely rather than described generically.
• Author, publisher and date visible on the page.
• Failure type diagnosed (warm-up opening, missing context, blander wording) before rewriting.

Citation display

• Anchor candidates read correctly alone and contain the claim and entity early.
• No long sentences with stacked dashes or parentheticals in key passages.
• Favicon square, larger than 48x48px, crawlable, one per hostname.
• WebSite structured data on the home page with a consistent name (and alternateName if useful).
• Brand spelled the same way in markup, logo text and footer.
• Titles unique, distinctive words first, no boilerplate.
• Relevant og:image on every priority page.
• Card contents and rationale text captured over time; drift diagnosed before reacting.

Related Guides

• How to get cited by AI search engines covers the wider program: comparison queries, multi-turn answers and competitor citation mapping.
• Brand entity disambiguation for when engines confuse your brand with another.
• Building a content refresh calendar for keeping dates and facts current.
• Implementing llms.txt, an optional file some sites use to point AI tools at key pages.
• AI search attribution for tracking visits and revenue from cited answers.

Frequently Asked Questions