Search Console Is the Most Underrated AEO Dataset

There is an odd blind spot in how teams approach AI visibility. Having decided that Google is no longer the whole story, many of them stop looking at the one dataset Google gives them for free — the only first-party, measured record of what real people search for and where you actually appear.

Every other input into an AEO programme is either inferred (what an engine said when we asked it), estimated (third-party volume data), or partial (referral traffic with a large invisible share). Search Console is measured. Google is not modelling your impressions; it is counting them.

That makes it the sturdiest input you have. It also makes it the easiest to misreport, because a measured number carries an authority that survives being computed wrongly. Four traps below are the ones that actually bite, and all four produce figures that look completely reasonable.

Trap 1: averaging position the obvious way

Average position is a weighted quantity, and the weight is impressions.

Compute it as a plain mean across query rows and a term with three impressions pulls exactly as hard as one with thirty thousand. Your long tail is enormous and mostly irrelevant; a plain mean lets it dominate. The correct form is SUM(position × impressions) / SUM(impressions).

The gap between the two is not cosmetic. A site with strong head-term performance and a sprawling tail of position-40 rows will report a decent weighted average and a dismal unweighted one, from identical data. This is also the number most likely to be challenged in a meeting, because anyone can open Search Console and see a different figure. Get it right the first time.

Trap 2: summing the query table and calling it a total

Google withholds queries searched by only a few people. Its performance data documentation is explicit that rare queries are omitted for privacy reasons, and the omission is not marginal — in practice the itemised query rows undercount the property total by a wide margin, frequently somewhere between a fifth and half of all clicks.

So the daily property total and the sum of the query table are two different numbers, and only one of them is your traffic. Presenting the query-table sum as “total clicks” understates you, and understates you by an amount that varies month to month with the shape of your long tail — which means your trend line is measuring Google’s anonymisation threshold as much as your performance.

The right handling is to keep them apart and report the difference as query coverage: what share of measured clicks your itemised queries account for. That number is genuinely useful — it tells you how much of your demand is head versus tail — and it stops the undercount from silently propagating into everything downstream.

There is a third row type worth separating too. A page path and a search query are different things that can look identical: someone really can search for /pricing. Told apart only by parsing the string, they collapse into one another. Kept as distinct row types, they answer distinct questions.

Trap 3: computing the day window in UTC

Search Console reports in Pacific time. Your server almost certainly thinks in UTC.

Take a naive toISOString() boundary and for seven or eight hours of every day you are assigning traffic to the wrong day. Nothing errors. Totals over a long window come out roughly right, which is precisely why this survives review — the bug shows up as small unexplained day-to-day discrepancies that everyone eventually stops asking about, and as week-over-week comparisons that are quietly off by one day’s worth of data.

If you build any derivation on top of Search Console dates, compute the window in America/Los_Angeles.

Related: the data lags about two days. The most recent day is never today, and a report that treats a missing recent day as a decline will manufacture a crisis every Monday morning.

Trap 4: the branded/non-branded denominator

Splitting branded from non-branded search is standard and useful — it separates demand you created earlier from demand you are capturing now.

The trap is the denominator. Take branded share against the property total and the two halves never sum to 100%, because the withheld tail from trap 2 sits in the total and in neither bucket. The result is a chart where branded is 30%, non-branded is 45%, and a quarter of the pie is unexplained. Take the share against itemised clicks only and the arithmetic works, with the coverage figure reported separately as its own line.

What this dataset is actually for in an AEO programme

Having got the numbers right, three uses justify the effort.

It is your prompt-discovery corpus. There is no keyword volume for AI prompts and there is not going to be one — nobody publishes what people type into ChatGPT. Your Search Console queries are the closest thing to a measured record of what your audience wants to know, in their own words. They are terse where prompts are conversational, but the intent maps. Finding AEO queries covers turning them into a tracked prompt set, and choosing tracked prompts covers which are worth the budget.

It is the control group. When AI visibility moves, the first question is whether anything changed at all or whether the engines simply resampled. Search performance over the same window is an independent read on the same content. If organic performance is flat and AI mentions collapsed, the change is on the engine side. If both moved together, something changed about your site or your market. Without a second dataset, every movement is equally attributable to everything.

It is half of the gap analysis. Joining ranked-for against mentioned-by produces the diagnosis neither dataset yields alone — most usefully the ranked-but-not-cited list, where Google already vouches for you and no engine does. That join is what the Search↔AI gap exists to compute, and when Google ranks you and AI doesn’t works through how to act on each quadrant.

Two windows, and conflating them makes a false claim

Worth knowing before you promise anyone sixteen months of history: connecting a property backfills daily property totals over a long window — roughly sixteen months, Google’s own retention limit — but per-query and per-page rows over a much shorter recent window. Query rows are bulkier by orders of magnitude and their long tail is withheld anyway, so pulling sixteen months of them on first connect would be mostly volume and little information.

The consequence is downstream and easy to miss: anything that joins on queries — including the Search↔AI gap — has the shorter history, not the long one. “Sixteen months of gap analysis on day one” is a false claim built from two true ones. The trend line is deep immediately; the query-level joins deepen as syncs accumulate.

Why we put it on every plan

An honest note about a product decision, because it explains something about the dataset.

Search Console is available on every LLM Metrix plan including free, while the other traffic connectors are not. That is not generosity. GSC is the only connector that backfills real history the moment you connect it — every other integration starts collecting from zero, so a new account sees an empty chart and reasonably concludes nothing works. It also costs us nothing to serve: the data, the API and the quota are Google’s.

Gating it would have meant a trial account never seeing the product function. Search performance is where it lands in the dashboard, and it is deliberately kept separate from the AI rankings view — position inside an AI answer and position in Google are different metrics, and merging them would corrupt both.

The summary

Search Console is not an AI dataset and it does not become one. It is a measured record of classic search demand, and its value in an AEO programme comes from being the only measured thing in a room full of inferences.

Which is exactly why the four traps matter. An inferred number that is 20% off is understood to be approximate. A measured number that is 20% off is believed.