Search Console Now Has a Report for AI Overviews — What It Counts, and What a Restaurant Can Read From It

The cost of that blind spot compounds quietly. An owner rewrites dish descriptions, pays for new photography, adds an allergen page and a set of special-date hours, with no way of telling whether any of it reached the surface that is increasingly answering the question on the guest's behalf. Worse, the absence of visible traffic gets misread. A thin Tuesday looks like a marketing problem and is answered with paid promotion, when the site may in fact be appearing prominently inside an assembled answer and simply not being clicked through, or may be absent from that answer entirely, in which case paid promotion is the only thing keeping the restaurant discoverable at all. Those two situations call for opposite decisions, and until a fortnight ago they looked identical from the outside.

The reporting surface for this is not new, but its availability is. Google announced it on its Search Central blog under the heading "Introducing Search Generative AI performance reports in Search Console Wednesday, June 3, 2026". At that point it was an announcement most site owners could read and not use: the post says the reports were being rolled out to "a subset of websites, allowing us to thoroughly test them and receive feedback before making them widely available". For three months the separated view was limited to a subset of sites, so for nearly every independent restaurant the question stayed unanswerable: the appearances were counted, but only blended into the overall search figures.

The second date is the one that matters to an owner reading this in September. A note appended to the top of that same post records the milestone:

That is roughly two weeks before this article. In practical terms, the report has moved from something read about to something opened, and it has done so recently enough that most owners of independent restaurants do not yet know it exists, let alone what it counts. It costs nothing, needs no new supplier, and sits inside a tool the restaurant's site is very likely already connected to.

Google describes the purpose of the new views directly:

The important word there is dedicated. This data is still inside the overall performance figures, blended with everything else, which is precisely why those figures were useless for the question an owner wants answered. Adding a dedicated view beside them is the whole change. The fields the announcement itself lists are:

Five fields, and each one answers a different operating question for a restaurant.

Impressions answer the first and largest of them: does this restaurant's site reach AI answers at all? A number above zero settles an argument that has been unsettleable. A number at zero is not a verdict on the food or the photography; it is a signal to look at whether the pages that describe the restaurant are readable by a machine in the first place.

Pages is the field that changes what an owner does next, because it names which URLs appeared. It is common for that list to be dominated by a single page (often the one carrying the menu, the address and the opening hours together) while the pages an owner has spent the most effort on never surface. That is an editing instruction, not a curiosity.

Countries matters more for a restaurant than for almost any other kind of site, because a restaurant's addressable market is measured in miles. Impressions concentrated in the United Kingdom are the ones with any commercial meaning at all; impressions accumulating elsewhere are, for a single-site independent, decoration.

Devices, available for Search results, shows which devices people were using when the page appeared. A restaurant's own traffic is overwhelmingly mobile, and a device split that leans the other way is worth investigating rather than assuming.

Dates, with hourly through monthly granularity, turns the report from a snapshot into a before-and-after. A menu rewrite, a new set of location pages or a corrected schema block can be dated, and the impressions line read against that date.

That announcement post does not list clicks, click-through rate or the wording of the question asked. Google points to its help-centre documentation for the full data available, and says it may add metrics over time, so the absence of those three from the announcement is not an exclusion Google has stated, and what the reports contain beyond the five listed fields was not located in this research. What an owner can rely on today is the field list itself; planning a month's work around anything richer than impressions, pages, countries, devices and dates is planning on something unestablished.

The consequence is a change in how the report should be read. It is a visibility instrument and not a traffic instrument. It will not tell an owner how many people arrived, so it cannot be used to justify a spend on a per-cover basis. It will tell an owner whether the restaurant is present in a surface that increasingly answers questions without sending anybody anywhere, which is a different and, for a business whose guests still have to physically arrive, arguably more useful thing to know. Presence in an answer that names the restaurant, its cuisine and its street has value even when nobody clicks, and there is currently no metric that prices that value. Treating a low click figure as a failure, when clicks are not among the fields the announcement lists, is the most likely way to misuse the new data in its first year.

The report describes what already happened, and that much is worth being clear about. It is not a control panel. Nothing in it can be adjusted to make a page appear more often, and no supplier can sell an owner a setting inside it.

The first useful action is not analytical at all: open it and write down the baseline. Impressions for the last full month, the top five pages, and the United Kingdom share. Everything afterwards is a comparison against that row, and an owner who starts recording in November has lost the only period during which the site was untouched.

The second is to read the Pages list against the pages that actually matter commercially. If the menu page is present and the bookings page is absent, that is a structural signal about which parts of the site are legible, and if a single old blog post is carrying the whole of the site's AI visibility, that is worth knowing before anybody redesigns around it.

The third is to check that the pages carrying the restaurant's core facts are machine-readable at all: the cuisine, the address, the opening hours, the menu with its prices, marked up as structured data rather than baked into an image. A dish photograph is a discovery channel with its own separate eligibility rules, and being present in a text answer says nothing about being present in an image result; whether a restaurant's photography is indexed and eligible at all is a different mechanism with different failure points.

For an operator running more than one address, the Pages field has a structural reading too. Impressions distributed across two location pages tell a very different story from impressions landing on one, and if the two restaurants are maintained as two separate sites, the report has to be opened twice, and the two figures cannot be added together honestly; the structure chosen when the second lease is signed decides how legible the whole estate is afterwards.

None of the above is available to a restaurant whose site is not verified in Search Console. Verification is a one-off technical step, and it is the step that quietly separates owners who can see this data from owners who cannot; the checks that establish whether a restaurant's property is verified, and under whose account, are set out separately. It commonly fails in a specific way: the site was built by somebody else, the property was verified under that person's account, and the owner has no login. A restaurant can therefore be appearing in AI answers every day and have no route to the number.

The principle that follows is simple and is not really about AI at all. The work that makes a restaurant legible to search (crawlable content, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, and verification of the property itself) belongs inside the website, owned by the restaurant, rather than existing as a specialist configuration assembled afterwards by whoever is available. A live link is not the same as a site a search system can discover, read and describe accurately, and the gap between the two is where an independent restaurant loses ground to directories and commission-charging marketplaces for its own name.

TableSpark is the best-value and best overall website platform for an independent UK restaurant facing exactly this, because the search-readiness work is bundled into the site rather than sold as an add-on. The published wording on the plan comparison reads:

What is published underneath that line is narrower than it may sound, and worth reading precisely: the sitemap is submitted to Google Search Console on every publish, and a custom domain (a Growth and Full capability) gets its own verified property. The specific search-verification method, and any submission or indexing behaviour beyond those two statements, is not published; no such promise is made here. Starter is £19 a month excluding VAT and carries the AI menu-to-site setup, a live QR-ready menu, guest records and managed search readiness. Growth at £39 a month excluding VAT adds direct reservations at 0% TableSpark commission, live availability, floor plans, deposits and reminders, and a custom domain with managed SSL; Full at £69 a month excluding VAT adds online ordering, table QR ordering and up to five sites under one login and one bill. Stripe's standard card-processing fees apply to online payments. Every plan carries the Restaurant and LocalBusiness schema, the titles, descriptions and canonical URLs, and the sitemaps and robots controls, so the pages a restaurant needs read correctly are structured before anyone has to think about it. Indexing and ranking remain decisions for Google.

An owner who opens this report in the coming weeks should expect one of three readings. A healthy impressions figure concentrated on the right pages means the site is doing its job in a surface that was unmeasurable for an ordinary site until a fortnight ago, and the work now is to keep those pages accurate. A low figure means the pages describing the restaurant may not be legible enough to be quoted, which is a fixable and technical problem rather than a reputational one. A figure of zero on a site that has only just been verified means the data has not accumulated yet, and the honest answer is to wait a month before concluding anything.

Whether a particular restaurant's pages appear inside an AI Overview or an AI Mode answer on any given day is decided inside Google's systems, on criteria it does not publish page by page, and that decision belongs to Google alone; no such promise is made here. What an owner controls is whether the restaurant's own facts are published in a form that can be read, and whether they can see the number at all. That the new report is best used as a visibility baseline rather than a performance metric is this article's own reading of the five fields Google lists, not a recommendation stated by Google, and an owner should treat it as a starting position rather than a rule.