AI Overview presence is a rate, not a yes or no

Why the same query answers differently twice

Two sources of variation stack on top of each other. The first is query fan-out. Google describes it in its own documentation as a set of concurrent related queries generated by the model, and gives a worked example: a question about fixing a weedy lawn becomes queries about herbicides, chemical-free removal and prevention. Your one question is a dozen questions, and different sub-questions retrieve different candidate sources. The second is sampling in the generation itself, which produces a different composition from the same retrieved material.

The visible consequence is that presence flickers. In one category we track, the same query, the same location and the same request settings returned an overview with ten references and then, roughly twenty minutes later, no overview element at all. Nothing about the page or the category changed in twenty minutes. The surface is simply probabilistic, and any instrument that reports it as a boolean is discarding the part that matters.

An empty block is not an absent overview

Google serves most overviews asynchronously. A request that does not explicitly ask for the expanded block gets a stub back: the element is there, the text is empty, the citation list is empty. Read naively, that looks exactly like a query where an overview appeared and cited nobody, or like a query with no overview at all.

We scored our own false zeros on it. In a pass on 2026-08-07, six of eight categories we checked came back as no overview present for exactly this reason. The overviews existed. Our request had not loaded them. Re-running with the expansion flag on 2026-08-09 returned a ten-reference overview for a query that had previously returned nothing, and every figure from the earlier pass was discarded rather than corrected, because a capture taken with the wrong flag is not a capture with a smaller number.

The operational rule that came out of it: an overview block carrying zero references is flagged as an unloaded stub, never scored as an overview with no citations. Any figure computed before the flag was fixed is void, and the honest response to a void figure is to say so and re-capture, not to publish it with a caveat.

How many passes before presence means anything

Presence is a rate, so it needs a denominator. Three passes is the floor we use before reporting presence at all, and more than that before reading anything into which sources were cited, because the citation list moves even when the overview is stable. The output is k of n: the overview appeared on four of six passes, on these dates, from this location, with the expansion flag on.

The citations are unioned across the passes that loaded, because a source that appears in two of four passes is a real participant in that answer even though it is absent from half of it. A source that appears in every pass is a different kind of finding: it is the stable core of that answer, and it is the standard your section has to meet to displace anyone.

We do not publish a number of passes that makes presence certain, because we have not measured one and it would differ by category. What we publish is k, n, the dates and the location, which lets you judge the strength of the reading yourself rather than trusting our confidence in it.

Why absence is the harder claim

Detection fails in one direction. When a capture returns an overview, an overview was there. When a capture returns nothing, the possibilities are that no overview was served, that one was served and not loaded, that the request was rate-limited, or that the automated session was challenged and served a block page instead of results. Three of those four look identical in the output.

That is not hypothetical. One of our own automated runs returned a clean report of no overview present for a session that had actually been stopped by a bot challenge. A failure had scored as a finding, silently, with no error anywhere in the output. Every run we make now carries an explicit blocked field that the automation has to set, so that a failure is distinguishable from a result. It is a small piece of engineering and it is the difference between a report and a guess.

So a zero from us is stated as a floor: across n passes on these dates we did not observe an overview, and that bounds how often one can be appearing without saying it never does. Anyone who tells you their tool proved an absence has told you something about their tool.

What we publish instead of a yes or no

Four things travel with every presence figure. The rate as k of n. The location the capture was pinned to, because a national default measures the wrong market for anyone selling locally. The date range. And the request configuration, specifically whether the asynchronous block was expanded, since that single flag is the difference between our own correct numbers and our own false zeros.

The reason to publish all four is not modesty. It is that a presence figure is the input to a decision about whether a category is worth entering at all, and a decision taken off a boolean that was actually a loading failure is an expensive decision taken for no reason.