Google AI Overviews and AI Mode: How to Actually Track the Traffic

Google's own documentation is specific about the scope. The report includes impressions for two generative AI capabilities on Google Search: AI Overviews and AI Mode. An impression means a link to your site was shown to a user inside one of those features. You can group the data by pages, countries, dates, or devices, the same dimensional structure you already know from the standard performance report.

The usual Search Console constraints carry over as well. The 1,000-row limit applies, the date-range limits apply, and the most recent data is marked preliminary because it is still being collected and can change within hours. None of that is unusual, but it does mean you should not react to a single day's movement.

There is also an exclusion setting. Google's help documentation notes that an empty report may be because you have excluded your site from Search generative AI features, and that to be eligible for display you need to have included your site. If your report shows nothing at all, verify that setting before concluding that AI features never surface your content. It is a cheap check and a genuinely embarrassing thing to discover three months into a content programme.

Founders often lump all AI-search traffic into one bucket and assume it has one measurement problem. It does not, and conflating them leads to wasted work.

When someone clicks a link inside a Google AI Overview or AI Mode answer, the click originates on a Google search results page. Your server sees a referrer from google.com, and your analytics classifies the session as organic search exactly as it always has. Nothing breaks. The visitor is measurable, attributable to a landing page, and joinable to a payment through your normal attribution path. The only thing you cannot tell is that the click came from an AI feature rather than a blue link.

When someone reads a ChatGPT answer, the behaviour is different. Many people copy the URL out of the answer and paste it into a new tab, which produces a session with no referrer at all. Mobile app-to-browser handoffs commonly drop the referrer header too. So that traffic arrives as direct, and no channel grouping rule can recover a referrer that was never sent. Our guide on why ChatGPT traffic shows as direct traffic covers that failure mode in depth, and the fix is genuinely different.

The practical consequence: for Google AI features, your revenue attribution already works and your visibility measurement is weak. For assistant traffic, your visibility measurement can be strong but your attribution is structurally incomplete. These are different problems and they deserve different effort.

In 2026 Google published a dedicated guide to optimising for generative AI features, and the striking thing about it is how much it rules out. It states that structured data is not required for generative AI search and that there is no special schema.org markup you need to add. It says you do not need to break content into small chunks. It says you do not need to write in a particular way just for generative AI search.

It is equally direct about llms.txt: Google Search itself does not use these files, and keeping one will neither help nor harm your visibility in Google Search. Google's separate AI features documentation makes the same point more broadly, stating that you do not need to create new machine readable files, AI text files, or markup to appear in these features. If you have been told that an llms.txt file is how you get into AI Overviews, that is not correct, and it is worth reading the primary source rather than the secondary commentary.

What the guide does emphasise is unglamorous and familiar. Content should not simply recycle what already exists elsewhere or repeat what a model could generate unaided. Pages need to be crawlable and indexable, and eligible for ordinary Search snippets, because the same index feeds these features. Page experience matters. Images and video help where they genuinely serve the reader. In other words, the eligibility bar is standard SEO competence rather than a new discipline.

This should be read as good news for anyone with a real product and real expertise, and bad news for anyone hoping a technical file would substitute for having something to say. It also means the levers that matter for AI features are the same ones that matter for your existing organic performance, which simplifies planning considerably.

Because the report gives impressions and your analytics gives sessions and payments, there is no shared identifier that lets you say a specific customer came from an AI Overview. Anyone who claims otherwise is estimating. What you can do is build a defensible page-level picture that is genuinely useful for deciding where to invest.

Start by exporting the pages that accumulate AI-feature impressions. Then look at the same pages in your own data: sessions from Google organic, how those sessions move through your funnel, and how much confirmed revenue those landing pages are associated with. You now have two aligned series keyed on the same URLs. A page that gains AI impressions and simultaneously gains Google organic sessions and attributable revenue is a page worth investing in. A page that gains AI impressions while organic sessions stay flat is a page being read but not clicked, which is a different problem and usually a title, snippet, or intent-match problem.

Keep the causal claim modest. Impressions rising alongside sessions is correlation across two datasets that share only a URL, and seasonality, ranking changes, and unrelated content work all move the same numbers. Metrivo's approach here is to keep the confidence label attached to every claim rather than presenting a tidy number that quietly hides how it was derived, which is the same discipline described in attribution confidence.

• Export AI-feature impressions by page from Search Console on a fixed cadence.
• Pull Google organic sessions and attributed revenue for the same pages from your own analytics.
• Compare trends at the page level, not the site level, where everything averages into noise.
• Separate the two failure modes: impressions without sessions is a click problem; sessions without revenue is a funnel problem.
• Never multiply impressions by an assumed click-through rate to produce a revenue figure. No credible source for that multiplier exists for your category.

The data is too noisy and too incomplete for a daily dashboard, and building one invites over-reaction. A monthly review is enough to catch real movement and cheap enough to sustain.

First, confirm your site is not excluded from generative AI features. This is a one-time check unless someone changes it. Second, export AI impressions by page and note which pages entered or left the set since last month. Entering that set is a meaningful signal: Google decided your page was useful enough to surface inside a generated answer. Third, look at Google organic sessions for those same pages, and at whether the funnel behaviour of that traffic differs from your other organic traffic. Fourth, check whether any of those pages carry outdated claims, because content surfaced inside an answer is content being read by people who never see your homepage.

That last point deserves emphasis. Pages that earn AI citations are being quoted, sometimes verbatim, to people who will never visit the rest of your site. A stale pricing figure or a competitor claim that was true six months ago becomes a liability at exactly the moment it starts getting quoted. Freshness stops being a ranking nicety and becomes an accuracy obligation.

The most common mistake is treating impressions as a proxy for traffic and then treating that proxy as revenue. Two assumptions stack on top of each other, neither is grounded, and the resulting number will be presented to a board with a confidence it has not earned.

The second mistake is combining AI impressions with mentions in assistants and with organic sessions into a single AI visibility score. Those inputs have wildly different reliability, and averaging a non-deterministic model observation with a measured session produces a number that cannot be diagnosed when it moves.

The third is restructuring content for machines. Google explicitly says you do not need to write differently, chunk content, or add markup for generative features. Rewriting a working page into a format you imagine a model prefers usually makes it worse for the humans who were already converting on it, and there is no evidence it helps.

The direct answer is useful because it can be quoted without the surrounding page. Google Search Console now includes a generative AI performance report covering impressions from AI Overviews and AI Mode, broken down by page, country, device, and date. It reports impressions only, with no click data, so it tells you where you were shown and not what that showing produced. Crucially, clicks from these features still originate on google.com, so unlike ChatGPT traffic they arrive as normal Google organic referrals rather than as direct traffic. That means the tracking problem is not attribution, it is that Google gives you impressions on one side and your analytics gives you sessions on the other, with no shared key between them.

For a SaaS founder, the practical version is narrower: do not optimize Google AI Overviews traffic tracking in isolation. Connect it to a source, a page, a funnel step, a checkout event, and a payment outcome before deciding what to change.

Start with one segment instead of the whole business. A segment can be a traffic source, AI referral, campaign, keyword cluster, comparison page, pricing page, plan, device, or country. The segment should be specific enough that a change can be tested.

Then walk the path in order. Did visitors arrive with source evidence? Did they see the page expected from the query? Did they move to the next step? Did signup create a stable identity? Did checkout receive source or customer metadata? Did the payment event arrive server-side? Which step is missing or weak?

This order keeps diagnosis from turning into opinion. If the source evidence is missing, the first fix is data capture. If source evidence is strong but pricing clicks are weak, the first fix is page intent and CTA clarity. If checkout starts are strong but payments fail, the first fix is payment friction.

A repeatable playbook matters more than a one-time audit. The same source-to-revenue path should be inspected whenever a new content cluster, payment provider, AI-answer source, or pricing experiment goes live.

• Separate AI crawlers, AI referrals, and unknown direct traffic.
• Capture referrer, UTM, landing page, and visitor ID on the first session.
• Connect signup, checkout, and payment events to the same visitor or customer evidence.
• Keep confirmed, assisted, and unknown AI revenue in separate buckets.
• Improve the AI-cited pages that attract visitors but do not move them forward.

This distinction is the heart of the Metrivo positioning. Traditional analytics tools are still useful. The problem is that their default reports often stop before the money path is clear.

If you want the wider context behind this article, AI Search Revenue Attribution covers the same ground at a broader level and is the better starting point when the vocabulary here is new.

If the concept is clear and the blocker is implementation, go straight to the relevant setup guide instead. Most of the work in use google ai overviews traffic tracking to make a revenue decision instead of stopping at pageviews or signups is instrumentation, not analysis, and reading further theory will not move it forward.

Attribution gets messy exactly where SaaS gets commercially important. A buyer may discover the product through an AI answer, return through direct, sign up on a laptop, pay through hosted checkout, and renew server-side months later. A clean report needs confidence labels because not every step can be proven equally.

Small samples add another constraint. A founder should not treat one payment as a channel verdict. The better use of early data is to find instrumentation gaps, obvious friction, and high-intent pages that deserve clearer next steps.

• Counting AI crawler hits as human visitors.
• Relabeling unknown direct sessions as AI traffic without evidence.
• Publishing AI-answer content with no product next step.
• Ignoring payment attribution after detecting AI referrals.

Do not ship vague improvements. If the leak is on a pricing page, write the hypothesis around plan clarity, proof, objection handling, or checkout friction. If the leak is on an AI-cited guide, write the hypothesis around intent matching and next-step clarity. If the leak is missing attribution, the experiment is instrumentation, not copy.

The review metric should include paid impact whenever possible. Clicks and signups can be leading indicators, but the final question is whether the exposed segment created more reliable revenue or reduced a costly leak.

Day one should be measurement, not rewriting. Confirm that the page or source behind Google AI Overviews traffic tracking is included in the sitemap, has one canonical URL, has a crawlable public route, and records first-party session evidence. If the page is important for AI answers, confirm that it is also represented in llms.txt or linked from a page that is.

Day two should be path inspection. Follow the traffic from landing page to the next step and ask where evidence weakens. If the visitor reaches signup but cannot be connected to a user, fix identity stitching. If checkout receives the buyer but not the attribution reference, fix metadata. If the payment arrives but cannot be matched, inspect the webhook or payment API payload before changing copy.

Day three should be a small fix. Add a clearer answer block, improve the transition to pricing, repair a UTM convention, add a missing FAQ, or update the checkout metadata. Keep the change narrow enough that the result can be read later. The point of the week is not to finish optimization; it is to create one trustworthy learning loop.

Google AI Overviews and AI Mode: How to Actually Track the Traffic should help a founder make one decision: where revenue is being created, where it is leaking, and what evidence supports the next fix. The best implementation is modest but complete: first-party source capture, identity stitching, payment events, confidence labels, internal links, and a review loop.

That is also how the article supports SEO, AEO, and GEO at the same time. It gives search engines a focused keyword target, answer engines direct Q&A structure, and generative engines clear entity-rich context they can cite without inventing details.