Google's Generative AI Report, Next to a Citation Sweep of the Same Site

本文目前只有英文版。站点其余部分已汉化，这篇内容尚未翻译。

Disclosure first: eonebill.ai's figures are published here with that site's permission. It is measured here twice, by two independent systems, and published because the comparison is more interesting than the result. Google's side is a Search Console export of its generative AI features report, generated 2026-08-31 and covering 2026-08-01 through 2026-08-28 (GSC export 2026-08-31, sheet Filters (过滤器)). Our side is a production read of TriRank's own citation sweep over the same window, taken 2026-08-31. Below, dataset L<n> is a line in our working note, eonebill-gsc-ai-x-engines-2026-08-31.md, and GSC export is the spreadsheet it was built from.

The two denominators are not comparable, and that comes first

Google's half. The export carries 257 data rows in its page sheet (dataset L13), summing to 18,165 impressions on the page dimension and 17,940 on the daily dimension (dataset L15, dataset L16). Those 257 rows collapse to 256 distinct pages once URLs are normalised, because Search Console reported one page both with and without its trailing slash (dataset L14). Both denominators are used below; neither replaces the other. The filters applied were search type = web and date = last 28 days (GSC export 2026-08-31, sheet Filters).

What the export does not carry matters as much. Every sheet has exactly two columns, and the metric column is always impressions (GSC export 2026-08-31, sheets Chart (图表) / Pages (网页) / Countries (国家_地区) / Devices (设备) / Filters). No clicks, and no query sheet at all. Google tells you a page appeared inside a generative AI feature, and stops there.

Our half is far smaller, and this is the number to hold onto. In that same window our sweep of this property ran against 5 tracked queries across 8 scan days (dataset L34, and the per-engine table at dataset L43–L50). One engine, ai_mode, has only 3 scan days in the window rather than 8. Five queries cannot reach 257 pages. A 0 in an engine column below means "this sweep did not see a citation to this page", and it does not mean that no engine has ever cited that page.

That is a 51× difference in scope — 257 pages against 5 queries — and every figure below should be read through it. The working note this table is built from overstates that gap in its own header line; 51× is the arithmetic, and it is the note's phrasing there that is wrong, not the figures under it.

Top pages by generative AI impressions

The engine columns below come from different vendors, and the mapping is not one vendor per column. aio is a legacy key name and means Gemini plus Google Search grounding, not the AI Overview product, wording copied from our own schema comment (dataset L110). google_aio is the actual AI Overview — read off a live Google SERP by DataForSEO's SERP API rather than fetched by us, through serp/google/organic/live/advanced (queryGoogleAioCitation, src/geo/google-aio.ts). ai_mode is Google's AI Mode tab, which we read through that same vendor. The three Google surfaces are never merged, because the point of a third engine is seeing them disagree.

Rows are the 30 highest-impression pages in the export, cut at 94 (dataset L137–L166 of the full 257-row table).

Footnote on the chatgpt column. Under the matching rule our working note uses, that column is 0 on all 257 rows, and the zero is a fact about URL shapes, not about ChatGPT. In this window ChatGPT cited 7 distinct URLs on the site, all 7 carrying ?utm_source=openai; no other engine attached one (dataset L126, dataset L129). Our normaliser keeps query strings deliberately and Google reports clean URLs, so those rows cannot match. The column above uses the de-parameterised reading, under which 3 of the 7 match pages in the export (dataset L129), one being /free-tools/bill-generator inside this top 30 (dataset L95, dataset L139). Switching readings leaves summary figures ① and ③ unchanged (dataset L463–L467).

What the two datasets say together

Three things, and only three.

Every page our Google-surface engines cited turned up in Google's own report. google_aio cited 10 pages in the window, of which 10 appear among Google's 256 distinct pages, leaving 0 outside (dataset L63). For ai_mode the figures are 8, 8 and 0 (dataset L69). Both of those engines read Google's live surfaces, and they agree with Google's own export on every page.

Our 5 queries landed on 20 of the 257 pages. Across every engine on the sweep's roster it cited 34 page-URLs, 20 of them in Google's export (dataset L75). That overlap is bounded by the query set, not by the site, so 20 describes scope rather than grade. Run the same idea on your own property with our free AI visibility audit and the caveat travels with it.

Google's report gives neither queries nor clicks; ours gives queries and citations. Google can say a page appeared inside a generative AI feature but not what was asked. Our sweep starts from the query, so it names the prompt that produced a citation and the URL the engine returned, across engines Google does not report on at all. If you are comparing tools that track this, we keep an honest rundown of the alternatives.

What we cannot do with this

Quite a lot, and it is worth being specific.

We cannot make a causal claim in either direction. Two systems observing the same page is agreement between measurements, not evidence that one produced the other, and nothing here separates those.

We cannot generalise beyond this property. One site, one 28-day window (GSC export 2026-08-31, sheet Filters), one export read on one day, five tracked queries.

We cannot say anything about the pages our sweep did not reach. With 5 queries against 257 pages (dataset L34, dataset L13), the sweep's silence on a page carries no information; it is the expected consequence of the denominator, and reading it as a finding would be the easiest mistake to make with this table.

And we cannot resolve the two arms of our own measurement into one number. Our citation data has a primary arm, the full list of source URLs an engine returned, and a secondary arm, the single URL a probe recorded as chosen. They disagree on 18 page-engine combinations, all in the same direction, primary reading 1 and secondary 0 (dataset L402, dataset L425). That one-directional pattern is falsifiable, since scrambled data would disagree both ways, and it points at the arms answering different questions rather than at a fault. We publish the 18 rather than quietly taking the union.

Sources

• The GSC export cited above as GSC export 2026-08-31: gsc-ai-features-eonebill-2026-08-31.xlsx, generated 2026-08-31, window 2026-08-01 to 2026-08-28, sheets Chart / Pages / Countries / Devices / Filters. Published byte for byte as we read it.
• The working note cited above as dataset L<n>: eonebill-gsc-ai-x-engines-2026-08-31.md, a production read of the same property and window taken 2026-08-31, carrying the full 257-row table, both denominators, and the matching rule with its known defect written out. One line of it is redacted and this is that disclosure: the site row's internal database id on line 33 is replaced by an equal-length string of x characters, so the line numbers cited above all still point where they did. Nothing else in the file differs from the copy we worked from.

FAQ

What does Google's generative AI features export actually contain?

For this property, one metric and four dimensions. The export has five sheets — chart by day, top pages, country, device, and the filters that were applied — and every one of them carries exactly two columns, where the metric column is impressions (GSC export 2026-08-31, sheets Chart / Pages / Countries / Devices / Filters). There is no clicks column and no query sheet at all. So the report tells you that a page was shown inside a generative AI feature, and it does not tell you what someone asked to get there, or whether anyone clicked.

Why do the two impression totals in the same export disagree?

Because one of them is not additive. Summing the page sheet gives 18,165 and summing the daily chart gives 17,940, a gap of 225. Neither side undercounted: the country sheet and the device sheet also sum to 17,940, so three separate dimensions agree on the same total and only the page dimension runs high. A single impression can land on more than one page, which makes the page dimension non-additive by construction (GSC export 2026-08-31, sheets Pages / Chart / Countries / Devices). The figures in our table are the raw page-dimension values, with nothing apportioned.

Why is the ChatGPT column mostly zero when ChatGPT did cite the site?

It is a URL-shape artefact, not a statement about ChatGPT. In this window ChatGPT cited 7 distinct URLs on the site and all 7 carried a ?utm_source=openai tracking parameter, while no other engine attached one. Our matching rule keeps query strings on purpose, because ?page=2 really is a different page — and Google reports clean URLs. So the two sets cannot line up on those rows (dataset L126, dataset L129). Reading the strict column and the de-parameterised column side by side, the site-level summary figures do not move at all.

Does a small overlap between the two datasets mean the sweep is weak?

No, it means the two measurements have different scopes, which is why the denominators come before the table. Google reported 257 rows for this property across 28 days. Our sweep in that same window tracked 5 queries over 8 scan days, so the pages our probes can possibly reach is bounded by what those 5 queries surface. An overlap of 20 pages is what that scope produces (dataset L13, dataset L34, dataset L75); it is not a score, and it would be wrong to read it as one.

What can this comparison not tell you?

Anything causal, and anything about another site. Two independent measurements agreeing on a page does not establish that one caused the other, and nothing here supports a claim about how long anything takes or what would happen elsewhere. It is one property, one 28-day window (GSC export 2026-08-31, sheet Filters), one export read on a single day — and the site in question is our own, which is exactly why the denominators are printed before the table rather than after it.