Search Console's generative AI report counts impressions and nothing else

What the generative AI performance report actually contains

Google's help page for the report is short, and the shortness is the finding. It states that the default view shows impression data for the site in the supported features, and defines the metric plainly: impressions are how many times links to your site were shown to a user in a generative AI feature on Google Search. That is the whole metric list. There is no clicks figure, no click-through rate derived from one, and no average position, and the page never explains their absence because it never raises them.

Four dimensions group that single number. Pages groups by the final URL linked by a generative AI feature after any redirects, with the page noting that most performance data in the report is assigned to the canonical URL rather than to a duplicate. Countries groups by where the search originated. Dates groups by day, week or month, in Pacific Time. Devices groups by desktop, tablet or mobile, and that one is marked as available for Search results. Set against the standard report, whose own help page lists queries, pages, countries, devices, search appearance and dates, the missing dimension is queries, and it is the one that would tell a site owner which questions their pages are being pulled into.

The scope is narrow in two further ways worth knowing before anybody plans around the numbers. The report covers AI Overviews and AI Mode, with the page adding that Google expects to update that list over time as it develops Search, and Discover's generative features are reported separately. Search Console does not include data from experiments in Search Labs, on the stated grounds that those experiments are still in active development. The usual constraints of the performance report also carry over, including the 1,000 row limit on the table, and the newest data can be preliminary and is drawn on the chart as a dotted line.

None of this makes the report a bad instrument. It makes it a narrow one, and a narrow instrument is only dangerous when it is read as a wide one. A count of appearances is a real signal and the only first-party one that exists for these surfaces, which is more than any of the other answer engines gives a publisher about how to get cited in ChatGPT. The care needed is in the sentence that follows the number, because impressions alone cannot separate a page that was shown and ignored from a page that was shown and acted on.

Search and Discover count an impression by opposite rules

There are two generative AI performance reports, one for Search and one for Discover, and they do not agree on what one impression is. This is documented rather than hidden, and it is the kind of detail that quietly ruins a spreadsheet when two numbers from two tabs are added together.

The Search report describes chart aggregation by property, and gives the example directly: if two results from the same site appeared in a generative AI search results feature, they count as a single impression in the chart total. Add a URL filter and the chart aggregates by URL instead. In the table below the chart the rule changes with the dimension, with data grouped by country, device or date aggregated by property, and data grouped by page aggregated by page. The help page notes that chart totals and table totals can therefore differ, and points at the standard report's troubleshooting guidance for why.

The Discover report states the opposite convention in one sentence. All data is aggregated by page, and if two generative AI results from the same property appear in the same Discover list, each impression is counted separately. It also imposes a display condition the Search report does not: the link must be scrolled into view, for example as a standard Discover card or embedded in a carousel, and only one impression is counted per result per session, so a user who scrolls past a card and then scrolls back generates one impression rather than two.

The pages dimension differs too, and the Discover version has a consequence a multi-property site will meet. It groups by the canonical page URL, which the documentation is careful to say is the page that served as the source of the information rather than the page the user lands on when they click. If that canonical URL is not in the property being viewed, the alternate page URL will not appear in the table for that property at all. A site whose canonicals point at a domain verified as a separate property will therefore see a hole in one report and no explanation of it in the other, which is a variation on the ordering problem that decides so much of what an AI crawler is credited with reading.

The practical rule is that these are two datasets, not one metric split across two screens. Comparing Search impressions with Discover impressions compares a property-level count against a result-level count, and the ratio between them will move with how often multiple pages from one site surface together, which is a property of the answer rather than of the site. That is the same class of error as treating a raw citation tally as a measure of influence, set out in citation count is not answer influence.

Why the report cannot tell you why you are absent

The most common question a site owner brings to a visibility report is not how many, it is why not. Google's help page answers a version of that question directly, under a heading asking what to do if you are not seeing the report, and the answer has exactly three entries. Not all properties have access, because the report is rolling out over time. The site may not have received enough impressions in generative AI features. Or the site may have been excluded from Search generative AI features, in which case the fix named is to include it again.

Read that list against what actually stops a page reaching an AI answer and the gap is the whole reason a scanner exists. Nothing in it concerns whether a crawler was permitted by robots.txt, whether the origin or the CDN in front of it returned the page to a non-browser client, whether the text was present in the HTML before JavaScript ran, or whether an interstitial stood between the crawler and the article. Those failures do not produce a special value in the report. They produce the same thing an unpopular page produces, which is no row at all.

The third entry on Google's list is worth separating from the other two because it is the one with no external trace whatsoever. The Search generative AI setting lives inside an authenticated Search Console property, not in any file on the site, which means no fetch of any URL you own can reveal it, a point covered here when the control was announced in the AI Overviews opt out does not live on your site. An empty report and an excluded property look identical from outside, and they also look identical from inside unless somebody opens the settings page and reads it.

So the report answers a narrow question well and a broad question not at all. It tells you how often links to your pages were shown, on Google's surfaces, to the extent the rollout has reached your property. It does not tell you whether the absence of a row is a content problem, a demand problem, a permission problem or a rendering problem, and those four have entirely different fixes. Distinguishing them is what the scan methodology is for, and refusing to state a grade when the evidence cannot support one is a rule this scanner applies to itself in why we withhold a grade.

What Google says a page needs before it can appear at all

Google publishes the eligibility rule separately from the report, and it is unusually plain. Its guide on AI features and your website states that to be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements, and that there are no additional technical requirements. The same page says there are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary.

That framing puts the whole of the access layer upstream of anything the report can show. Among the fundamentals the guide lists is ensuring that crawling is allowed in robots.txt and by any CDN or hosting infrastructure, and separately, making sure that important content is available in textual form. Those two sentences name precisely the two conditions that a page can fail silently and that a performance report can only ever register as absence. The guide also states that you do not need to create new machine readable files, AI text files, or markup to appear in these features, and that there is no special structured data required, which is the same conclusion the evidence pointed to in what the evidence says about llms.txt.

The two named conditions are both observable from outside without any Search Console access, which is what makes them the cheap checks to run first. Whether a given token is permitted is a question you can put to a robots.txt tester directly, per crawler rather than in aggregate, and the answer differs by token more often than most site owners expect. Whether the text is in the response before JavaScript runs is what a what GPTBot sees fetch shows, and the gap between the served HTML and the rendered page is the measure called prose parity.

There is a layer between those two that the guide gestures at with the words CDN or hosting infrastructure, and it deserves the emphasis Google gives it. A permission granted in robots.txt can be overridden by a rule at the edge that the person who wrote the robots file never saw, which is the argument in two layers decide if AI can read your site. A related failure is a consent interstitial that a stateless client can never dismiss, covered in consent gates never open for a stateless crawler. Neither shows up in a report of impressions, because neither produces an impression.

What to check when the generative AI report shows nothing

Take the three documented causes in order of cost, because the cheapest one is also the one with no external evidence. Open Search Console settings and read the Search generative AI control on every property that matters, including child properties, which inherit from a parent unless somebody has overridden them. If the section is not there, the property is not in the rollout and there is nothing to read. That check costs a minute and rules out the only cause that no scan of your own site could ever detect.

Then work the access layer, which is where the causes the report does not enumerate live. Request your own page with a crawler user agent from an address outside your own network and read the status code, then read the body and search it for a sentence from the middle of the article. A 200 with the sentence present means the access question is answered and the problem is elsewhere. A 403, a 429 or a body that carries only a shell means the report was never going to have a row to show you, and no amount of content work changes that until the fetch succeeds. The tokens worth testing individually are listed on the AI crawlers reference, and this scanner publishes what its own agent is and does on its bot page.

Then be careful about what you conclude from impressions once they do arrive. Without clicks or a click-through rate the report cannot separate a link shown at the bottom of a long answer from a link that carried the answer, and without a query dimension it cannot tell you which questions produced either. Anyone trying to close that gap is building an estimate, and the honest version of that estimate states its sample and its prompt set, which is the argument in how many prompts an AI visibility measurement needs. The related trap is assuming AI citations track classic rankings, which measured evidence contradicts in AI Overview citations are not page one.

Finally, keep the scope of the report in view when reading it as a picture of generative engine optimization performance. It describes Google's surfaces, on a Google property, and says nothing about any other answer engine, so a site that is well represented in AI Overviews may be absent from Perplexity for reasons this report has no column for. What Google asks for on the surfaces the report does cover is summarised on this site's Google AI Overviews page, and the dated write-ups behind claims like the ones here are collected on the research page. A first-party count of appearances is a real improvement on having nothing. It is not the same thing as knowing why the count is what it is.