Why “Yes Go On” Is Showing Up in Your Search Console

If your Search Console query table has started showing rows like “yes”, “yes go on” or “yes, pricing”, nothing is broken and nobody is spamming you. Those are real people, mid-conversation inside Google’s AI Mode, and Google’s own documentation explains exactly why they end up in your query list: every follow-up question inside AI Mode is counted as a brand-new query.

That single sentence of documentation has a consequence most teams have not priced in. Your Performance report is no longer a list of things people searched for. It is a list of things people searched for, plus fragments of conversations they had with a model that happened to cite your site. Those fragments carry impressions, positions and clicks, and they flow into every average you compute on top of the query dimension.

This is a data-quality diagnostic, not another AI Mode explainer. We already cover tracking AI Overview traffic in Search Console, the opt-out controls for AI Overviews and AI Mode and deciding whether to block your content from AI responses. What follows instead is the measurement problem: how to recognise these rows, why every published cleanup heuristic misses them, and what to do about it before your next client report.

The story started the way most Search Console oddities do: someone looked at a report, saw something that made no sense, and asked publicly. In early August 2026, SEO practitioner Anastasia Kourou posted a screenshot of her Performance report on LinkedIn and addressed the question directly to Google’s John Mueller. The rows she was seeing did not read like searches. They read like replies.

Mueller answered, and his answer was short: Search Console includes information on AI Overviews and AI Mode in the general performance report, and there is more detail on the help page that documents how clicks and impressions are counted. No announcement, no bug report, no fix — a pointer to documentation that had been sitting there the whole time.

Search Engine Roundtable picked the thread up on 6 August 2026 and named the three example queries that have since been repeated everywhere: “yes”, “yes go on” and “yes, pricing”. Search Engine Watch followed the next day with an independently written account of the same phenomenon, rendering the second example with slightly different punctuation. That small discrepancy is worth noting rather than resolving — both outlets appear to be transcribing the same screenshot, and neither rendering should be treated as canonical.

One more detail from the thread deserves a hedge rather than a headline. A commenter asked what 657 impressions and 43 clicks for a query like “ok” were supposed to tell them. That is a single, unverified account from one anonymous property — it is a good illustration of the frustration and a terrible benchmark. Do not carry that number into a client deck, and do not let anyone else carry it into yours. A separate reaction quoted by Search Engine Roundtable, attributed to Ross Tavendale, asked the sharper question: if Search Console is recording responses to AI Mode, can anything be reverse-engineered from them? We think the honest answer is mostly no, and Section 04 explains where the exceptions sit.

The behaviour is not an inference from screenshots. It is written down. Under an AI Mode subhead, Google’s help page on how Search Console counts clicks and impressions states that if a user asks a follow-up question within AI Mode, they are essentially performing a new query, and that all impression, position and click data in the new response are counted as coming from this new user query.

Read that mechanically and the degenerate rows stop being mysterious. A user enters AI Mode with a real question. Your page is cited in the response. The user types “yes go on” to continue. AI Mode generates a new response, cites your page again, and Search Console attributes that second appearance to the string the user typed — because that string is, by Google’s own definition, the query that produced the response.

The same page documents the surrounding rules independently: clicking a link to an external page in AI Mode counts as a click, standard impression rules apply, and position in AI Mode follows the same methodology as a Google Search results page. So these rows are not phantom impressions. They are ordinary Search Console rows whose query string happens to be a piece of conversation.

Here is the inversion that makes this problem stick around. Google announced dedicated Search generative-AI performance reports on 3 June 2026, written by Hillel Maoz and Moshe Samet, with separate views for Search and Discover. That report was supposed to be the clean, AI-specific lens on generative-AI visibility. It offers five data categories: Impressions, Pages, Countries, Devices and Dates.

There is no Queries category in that list. Google’s dedicated help-center article for the report confirms the same set minus Impressions: four selectable dimensions in the report table — Pages, Countries, Dates and Devices — with no Queries dimension offered anywhere on the page. Two Google-owned pages, same answer. The report designed to isolate generative-AI performance is structurally incapable of showing you a single query string.

So the phenomenon is only visible in the general Performance report: the one report SEO teams trust least for AI-specific analysis, because it blends everything together. Google’s own announcement is explicit that generative-AI data is included in the overall performance report, where it continues to be tracked. The clean report cannot see the problem; the messy report can, but only if you know what you are looking at.

Worth being precise here, because this is the easiest factual error the topic invites: these are two different reports with two different behaviours. The general Performance report does carry AI Mode query rows, with clicks and positions attached. The dedicated generative-AI report does not have a Queries dimension at all. Merging those two statements produces a claim that is wrong in both directions. If you need the wider background on what the generative-AI reports do and do not include, our piece on Google’s billions-of-AI-clicks claim and the missing data behind it covers that ground.

Every piece of coverage we found stops at “isn’t this strange”. None of it tells you what to do with the rows once you have found them, and the answer is not uniform — one of the three reported examples is genuinely useful, and the other two are not. The matrix below splits the pattern into handling classes and answers two questions per row: should it feed your CTR and position benchmarks, and should it feed your keyword-opportunity mining? Those two decisions come apart more often than teams expect.

The column that surprises people is the last one. A qualified follow-up such as “yes, pricing” is worthless as a benchmark row and genuinely interesting as an insight row. It tells you that somebody reading a model’s summary of your content wanted pricing next. That is a content-brief signal you would normally pay for in user research, arriving free in an export — as long as you never let it near an average position calculation. Splitting the two decisions per row is the whole point of the table.

This is the part nobody in the coverage connects. There is an established practitioner technique for finding AI-style prompts inside Search Console: filter the Query dimension with a regex that matches ten or more words. Search Engine Land published a version of it in February 2026, and at least one other practitioner blog documents a family of variants — a seven-plus-word pattern, a question-word prefix pattern, and a combined comparison-and-how-to pattern.

Every one of those filters assumes AI-influenced queries are long. That assumption was reasonable: the visible signature of conversational search has been the sprawling natural-language prompt. But a follow-up query is the opposite shape. “yes” is one word. It does not merely fail the ten-word test — it fails it in the direction that makes it look like ordinary short-tail data, the most trusted rows in the entire report.

The audit below runs the standard cleanup toolkit against this specific failure mode. The first group is sourced to published techniques; the second is standard SEO-QA practice and is our own reasoning rather than anything a source claims.

The row worth staring at is the high-impression, low-CTR flag. That heuristic does not merely fail to catch these rows — it actively promotes them. A phrase that recurs across enough AI Mode conversations accumulates impressions, converts poorly relative to a genuine query, and lands squarely in the queue of pages your team has decided need better titles. You then spend a sprint rewriting metadata to win clicks on a word that was never a search. This is the same class of problem as hybrid human-and-agent sessions distorting web analytics: the measurement layer keeps reporting confidently while the thing it is measuring quietly changes shape underneath it.

Be careful here, because this is where a diagnostic post can quietly turn into fiction. No source measures the effect. Nobody has published an average-position delta, a CTR impact, or a percentage of query rows affected. Anyone quoting you a figure for how much these queries dilute your reporting invented it. What follows is reasoning about the mechanism, and it should be read that way.

The mechanism itself is simple enough to reason about honestly. Search Console reports average position across queries. Each follow-up row enters that aggregate with its own position value, derived from where your URL sat inside a generated response rather than from competitive standing on a term anyone was searching for. When you compute a site-level or page-level average across a query set that includes those rows, you are averaging two different kinds of measurement together. The direction and size of the effect depend entirely on your own data — which is exactly why you should measure it rather than assume it.

The same logic applies to CTR. A follow-up row can carry clicks, because clicking an external link in AI Mode counts as a click. It can also carry impressions with no click at all, when the user reads the generated response and continues the conversation instead. Both behaviours are legitimate. Neither tells you anything about how persuasive your title tag is, which is the question a CTR column is usually being asked to answer.

The client-reporting row is the one that causes arguments. Search Console has always mixed measurement changes into performance data without flagging them, and the analyst is left explaining a movement they cannot fully attribute. The defensible position is to annotate: state that AI Mode follow-ups are counted as distinct queries per Google’s documentation, state that you have segmented them out of the headline figures, and show the segmented and unsegmented views side by side once. After that, report the clean number.

None of this requires new tooling. It requires an export, a filter list you maintain deliberately, and the discipline to apply it before anyone computes an average. The sequence below is how we run it.

1. Export at the query level, not the summary level. The Performance report UI truncates and the aggregate views hide the pattern. Pull the query dimension for a long enough window that you can compare periods, either from the export or from the Search Console API.

2. Sort ascending by query length. This is the inverse of the published technique and it takes about ten seconds. The degenerate rows cluster at the very top of an ascending-by-character-count sort, next to genuine one-word brand terms. Read that block manually the first time — you are building a list, not automating blindly.

3. Build an exclusion list, not an exclusion regex. A word-count rule will eat legitimate short-tail terms. An explicit list of conversational tokens observed in your own property will not. Start with the affirmatives and continuation prompts you actually see, and add to it as new ones appear.

4. Split qualified follow-ups into a separate bucket. Rows that pair an affirmative with a topic token go into an insight file, not the bin. Review that file monthly as content-brief input and keep it out of every quantitative view.

5. Re-baseline your comparison periods. If your month-over-month view spans the point at which these rows started appearing in your data, apply the exclusion list to both periods before comparing. Otherwise you will read a measurement change as a performance change.

6. Write the rule down. Whoever builds next quarter’s report needs to apply the same exclusions or the numbers will not reconcile. This belongs in your reporting documentation alongside your brand-term list, not in one analyst’s head.

The interesting question is not whether these rows exist — Google has documented that they do. It is what the reporting surface looks like once conversational search stops being a minority of sessions. Three developments would each change the calculus, and none of them has been announced.

A queries dimension in the generative-AI report. The dedicated report launched to a subset of sites, explicitly as a test that Google said it wanted feedback on before making it widely available. If a Queries dimension ever appears there, the segmentation problem largely solves itself: AI-sourced queries would live in their own view instead of blending into the general Performance report. Until then, the report built for AI visibility remains the one report that cannot show you AI query strings.

A conversation identifier, or the absence of one. Today a follow-up row is orphaned — you cannot tie “yes go on” back to the question that preceded it, which is why so little can be reverse-engineered from these rows. Any grouping signal that let practitioners reconstruct a conversation would turn a data-quality nuisance into a genuinely new research dataset. Nothing suggests this is coming, and the privacy argument against it is obvious.

Tooling that catches up. Every rank tracker, reporting platform and agency dashboard that ingests Search Console query data inherits this problem, and most of them normalise and average that data before anyone sees it. Expect the first vendors to ship conversational-token filters, and expect the filter lists to be wrong for a while. Verify what your platform excludes rather than assuming it excludes anything. The same caution applies to the newer Search Console surfaces generally — our look at Search Console platform properties for social and video covers a parallel case where the data model shifted faster than the reporting habits around it.

The broader pattern is worth naming. Search Console’s query dimension was built on an assumption that has quietly stopped holding: that a query is a discrete, self-contained expression of intent. In a conversational interface, intent is distributed across turns, and any single turn is a fragment. Google’s documentation handles this by declaring each turn a new query, which is a defensible engineering answer and a poor analytical one. Reporting practice has to absorb the difference, because the schema is not going to.

For teams building AI-era search strategy rather than just maintaining reports, this is the moment to separate the two questions you have been answering with one dataset: how visible are we, and how well do we convert visibility into clicks. Follow-up rows are evidence for the first and noise for the second. Treating them as one thing is what produces the confused month-over-month narratives. Our agentic SEO engagements are built around exactly that separation.