A Gemini citation tool is not an AI Overview tool

What a Gemini citation tool actually calls

The answer registry in this codebase holds exactly five engines, and Gemini is the second, so a Gemini answer appears second in a prompt's answer list whenever it ran. Whether it ran is a separate question with two named non-answers, and the fifth section is about those. Its row is not marketing text, it is a typed spec: label "Gemini with Google Search grounding", vendor Google, default model gemini-3.6-flash with a GEMINI_MODEL environment override so a model rename never needs a deploy, retrieval "live", citations true, tier "free_tier". Those last three fields are what every downstream surface reads when it decides what it is allowed to say about the answer. An engine with retrieval "none" can never be described as having searched. An engine with citations false can never appear in the citation table, no matter what its answer text looks like. The registry's own comment calls those three fields the honesty contract, and it is worth being specific about what that buys: the report renders its claims from data rather than from a hardcoded engine name, so adding an engine cannot accidentally teach the interface to say something the engine does not support.

The call itself is unremarkable, which is the point. It is a POST to generativelanguage.googleapis.com/v1beta/models/{model}:generateContent, with the question as a single text part, and one line that does all the work: tools set to a single google_search entry. That is Google's grounding tool, and it is the entire mechanism by which the answer becomes a retrieval answer rather than a recall answer. Output is capped at 500 tokens per answer, deliberately, so that a brand named in one engine's answer is not missing from another's purely because that answer got cut shorter. The registry policy comment is explicit that the alternative is worse than the token saving: brand detection reads the whole answer, so a smaller cap would bias the naming metric by engine. The shipped Gemini caller aborts at 20 seconds; the registry's ceiling for any live-retrieval engine is 30 seconds, because a search pass before generation legitimately takes longer than pure recall does, and both are bounded because a run holds a queue consumer open while it waits.

Citations come out of one field. The parser reads candidates[0].groundingMetadata.groundingChunks, takes web.uri from each chunk, drops empty strings, and keeps at most the first eight. Eight is a cap we chose, not a number Google returns, and it matters when you read any citation count: a source total from this tool is bounded by our parser as well as by Gemini. If an answer grounded in twelve places, four of them are not in the count. We have never seen a reason to publish a "sources per answer" average and this is one of the reasons we will not, because the number would describe our slice as much as it describes Gemini.

If GEMINI_API_KEY is not set, the caller is null and the engine simply does not exist for that run. That is a legitimate permanent state in the design, not an error path, and the report says so rather than showing a zero. Our own integration inventory records Gemini as connected with that secret present, in a table whose header notes the secrets were confirmed live against the deployed Workers, which is the strongest thing a code repository can honestly say about a production secret.

Two comparisons are worth making here because they are checkable rather than competitive. The registry holds three paid engines and all three are citation-capable: Perplexity Sonar returns its search results on every answer, the OpenAI row reads url_citation annotations off the output text, and the Anthropic row reads web_search_tool_result blocks. Sonar is the cheapest of the three at 8,000 booked micro-USD a call against 15,000 for each of the others, which is why it is the first paid engine a plan unlocks, and Perplexity documents its crawlers publicly at its bot documentation. The open-weight chain that answers on every plan is the other direction entirely: retrieval "none" and citations false, so it can never enter the citation table whatever its answer text says. It is the same chain behind what AI says about you, where it measures recall rather than sources. If you want the earning side for one of the paid engines rather than the plumbing, getting cited in Perplexity is the reference page for it.

A grounded answer is not an AI Overview

An AI Overview is a unit rendered inside a Google Search results page for a query a person typed. A grounded generateContent call is a developer API request that runs its own retrieval pass and returns text plus grounding metadata. Different entry point, different retrieval, different ranking, different eligibility rules, and nothing published lets you map one onto the other. Lantad measures the second. It does not measure the first, and this post exists partly so that nobody reads our grounded answers as an AI visibility claim about Google Search itself.

The honest way to hold this is that a grounded Gemini answer is evidence about how Google's models describe your category when they search, and it is not evidence about your presence in Search results. Those two can move independently and there is no published mapping that would let anyone convert one into the other. If you want the earning side of AI Overviews specifically, that is a reference question and it lives on the how to get cited in Google AI Overviews page rather than here, because "how do I earn this" and "what can a tool measure" are different jobs and blurring them is how a reference page turns into a sales page.

Three limitations follow directly, and each one is a place where our own product stops.

First, crawl access. An AI Overview appears on a Google Search results page, so anything upstream of Search is upstream of it, starting with whether Googlebot can reach and render your pages. That is reasoning from where the unit appears rather than a measurement, and we would rather say so than dress it up. Our bot registry carries fifteen tokens and Googlebot is not one of them: the name appears only inside a comment. So the AI crawler checker and the robots.txt tester tell you nothing about the crawler that feeds the Search index. They tell you about AI assistant crawlers, which is a different and narrower fact, and the bot reference says which tokens those are. If a vendor's AI Overview product is built on a robots.txt parse, ask which user agent it parsed for, because that answer is the whole product.

Second, training and grounding controls. Google-Extended is registered in our bot registry with purpose "training" and no user agent string at all, so it can never appear in an access log; the registry note records why, which is that requests come from ordinary Googlebot infrastructure and there is nothing separate to probe. We wrote that up in the crawler tokens that never appear in your logs and will not re-explain it, and Google's own crawler overview documentation, which is the URL our registry stores for that token, is the primary source for which tokens are robots-only. The practical consequence for tooling is blunt: any dashboard reporting Google-Extended "activity" is reporting something it did not observe.

Third, referral traffic. Our first-party request classifier keeps a list of assistant referrer hosts, and gemini.google.com is on that list while google.com is not. The reasoning is ours and is worth stating as reasoning rather than as a recorded decision, because the file does not record it: an AI Overview click and an ordinary Google click both arrive from google.com, so nothing at the receiving end separates them. What the file's comment does record is the neighbouring rule, that a human arriving from an assistant and a crawler fetching a page are kept in separate fields so that a downstream sum has to be written deliberately rather than falling out of a shared column. And that classifier runs in the edge Worker over lantad.co's own requests. It is our analytics, not a customer connector. The same applies to Search Console: our integration pulls exactly one property, lantad.co, on a nightly cron for an internal admin page. We do not read your Search Console, we do not read your generative AI performance reports, and if a tool tells you it can see your AI Overview referrals without a Search Console connection, that is worth a direct question.

None of that is an argument that AI Overviews do not matter. It is an argument that external measurement of them is bounded, which is the same shape of argument as a user agent is a claim, not an identity, applied to a different surface.

The redirect that breaks the host table

Here is the finding that cost the most work. When Gemini returns groundingChunks, the web.uri can be a grounding-api-redirect URL on vertexaisearch.cloud.google.com rather than the publisher's own URL. The host of the cited URI is then Google's redirector, not the site that grounded the answer. The config comment that registers those hosts uses the word "often" for how frequently this happens, and we are not going to launder that word into a statistic: no scan, fixture or metric in this repository counts the rate, so the opaque count printed in your own report is the only number that describes your run.

The consequence is stated in full in the same comment, and it is worth reading as engineering rather than copy: aggregating those by host "would produce a citation table that is one Google row and nothing else, and would report every customer as never cited". Two hosts are registered as redirectors, vertexaisearch.cloud.google.com and grounding-api-redirect.googleapis.com. If you have ever seen a Gemini citation dashboard whose top cited domain is a Google infrastructure hostname, this is the mechanism behind it.

There were three ways to handle it and only one of them is defensible. Dropping the redirect URIs silently would undercount sources and make every customer look worse than the data supports. Crediting them to the redirector's host would fill the table with Google. Both are the kind of quiet distortion that a withheld grade exists to prevent, because both produce a number that looks like knowledge and is not. So the shipped rule is the third option: a citation resolving to a redirect host is classed opaque, counted in the source total, excluded from the own-domain check in both directions, and still given a labelled row in the host table so the reader can see how much of the picture is hidden. That rule is written down twice, which is deliberate. It is honesty rule seven in the metrics module, and it is stated to the customer in the basis line under the table, which says those links "cannot be attributed to a domain without following them, which this page does not do, so they are never counted for or against your own domain". A test pins the behaviour, asserting that one redirect URI produces one total source, one opaque source and zero own-domain sources, so a future refactor cannot quietly turn an unreadable citation into a miss.

Now the inconvenient part. This means Lantad cannot reliably tell you which publishers Gemini cited. It can tell you how many sources came back, how many of them were opaque, and which hosts the readable ones belong to. Resolving an opaque URI would mean issuing an outbound request per citation to see where it lands, and this product does not do that. So the correct reading of a Lantad citation table with a high opaque count is "we could not see most of this", and that is exactly what the basis line under it says, in those words, to the person paying for it.

It also means one line of our own marketing copy is ahead of the product. The prompt tracking page says today that a grounded answer arrives "with the source pages it grounded in listed on every answer". The answer does carry a source list. Whether those sources identify a page is a separate question, and when the URI is a redirect the answer is no. That is a claim the measurement does not fully support, and writing this post is how it gets stated in public rather than defended in private. The same standard is why we published what the evidence says about llms.txt against a file this scanner checks for: a product claim that outruns the measurement is a bug in the copy, not a nuance.

None of this is unique to Gemini as a vendor decision, and it is not a complaint. A redirect is a reasonable thing for a grounding API to return, and it costs Google nothing to serve. It is simply a hard limit on what any third-party tool built on that API can report about publishers. If you are comparing products, ask each one what it does with a grounding redirect URI, and ask to see the answer rendered in a real report rather than described in a sentence.

Absent, empty and opaque are three different facts

The optional field is the design. In the answer type, citedUris is optional on purpose, and the doc comment on it is longer than the field: absent means no citation container came back at all, which is "we could not read", while present and empty means a citation-capable engine answered and reported zero sources. Those are not the same fact and they must not render the same way. Which case you are in is settled by the engine's citations flag in the registry, carried onto the run, not by guessing from the answer text, which is the kind of guess that looks harmless until an engine changes its response shape.

That split is why the citations metric is not a single number. It carries source-reporting answers, answers with sources, answers reporting none, answers with no list at all, live answers from engines that do not report sources, prior-knowledge answers, answers whose engine is not in the registry at all, plus total sources, opaque sources and own-domain sources. When nothing was measurable it returns measured false rather than a zero, and the surface prints "not measured on this run" instead of a confident 0%. A zero denominator is not a zero, and an errored answer is not a miss: an engine that failed leaves the denominator entirely and is reported separately, because "the engine did not answer" and "the engine answered without naming you" are different things a customer would act on differently.

This is the same discipline as the visibility scoring methodology, where a signal that could not be checked is reported as unchecked rather than folded into a score, and the same reason we withhold a grade when the evidence does not support one. It is also why our research page publishes scan composite and sub-score aggregates and grade bands and publishes no citation statistic at all. There is no prompt-run aggregate on this site, no "N percent of Gemini answers cite the average site", no citation rate benchmark. We do not have one, and anything we printed would be an invention. If you see such a number from anybody, the questions to ask are what the denominator was, how many engines it covered, and whether opaque URIs were counted in it or quietly removed from it, because those three choices can move a headline percentage further than the underlying reality ever would.

Two display bounds are worth knowing so a table is not misread. The cited-host table shows at most twenty hosts, while the counts behind it cover every source, and the metric carries a truncation flag so a short table can be told from a complete one. The config comment on that limit is one line long and says exactly that: same contract as the name table above it, display bound only. And the eight-URI parser cap from the first section sits underneath all of it, which is an ingest bound, a different thing again. Keeping those two categories apart is what lets a reader work out what a number does and does not describe. The vocabulary for all of this, if you want the terms rather than the plumbing, is in the GEO glossary entry and the answer engine optimisation entry.

The ceiling on how much any tool can ask Gemini

Citation tracking has a cost shape, and the honest version of this section is partly a disclosure. Grounded Gemini calls in this product are hard-stopped by an atomic monthly counter, default 4,500 calls, overridable by an environment variable. That number is set below Google's published free grounding allowance, 5,000 grounded prompts a month, which our config records as verified on ai.google.dev/gemini-api/docs/pricing on 22 July 2026. The 500 of headroom is for counter lag under concurrent runs. The effect of the counter is that the search component of the bill is zero by construction rather than by good behaviour.

Because of that counter, a Gemini call is booked to the internal spend ledger at 1,000 micro-USD of token cost rather than at the 14,000 micro-USD grounded-search rate the same config records for queries past the free tier. That deliberately breaks the rule this codebase otherwise follows of booking costs conservatively high, and the comment says why, plus what has to happen if the posture changes: if the monthly cap is ever raised past the free tier, that number must move to 15,000 in the same commit. Writing the trigger next to the number is the only way a cost assumption survives the person who made it, and there is a test asserting the cap stays under 5,000 so the booking cannot quietly become a lie.

The upshot for customers is that Gemini runs on every plan, including free, because its marginal spend is zero. The free row is five prompts per run and zero paid engines, and zero paid engines is not zero engines: a free run still gets both always-on engines and returns real grounded answers. Paid engines behave differently. They answer only the top ten prompts of a run, ranked by relevancy, because breadth is the part of answer tracking that actually costs money and the cap is the difference between a bounded run and an open tab. Gemini answers every selected prompt in the run. That asymmetry is visible in every run report rather than in a plan table, because a partly-covered engine says so in its own run report note rather than looking complete, which the policy comment names as the reason the cap is allowed to exist at all.

Now the disclosure. At the default daily run cap of a hundred runs a day, free traffic alone would ask roughly 15,000 grounded calls a month against an allowance of 4,500. That overrun is recorded in the config and there is a test asserting it so that it cannot be forgotten. The test passes today, and the comment beside it says what its failure would mean: when it starts failing, the overrun is gone, because grounded coverage was capped or free traffic was excluded or the allowance was raised. The fix identified in the config is the first of those, a coverage decision in the run worker that would cap grounded coverage the way paid engines are capped, and it is not shipped. So the accurate statement today is that in a heavy month the grounded engine can run out before the month does. It is not a money overrun, because the counter holds the bill at zero. It is a measurement overrun, which is the kind that shows up in a report rather than on an invoice.

What happens then is the part we are willing to be judged on. Per-engine run status is a five-value vocabulary: answered, not_configured, not_included, budget_stopped, failed. Gemini with no key reports not_configured. Gemini past its monthly counter reports budget_stopped. Not included in your plan reports not_included. The note sentence a reader sees is generated from the counts of what the run actually did, so a plan gate can never read as an engine that had nothing to say, and a stopped engine can never read as a zero. That is the whole point of building the vocabulary before building the dashboard, and it is the same instinct behind the two layers that decide if AI can read your site: name the state precisely, then report it.

One more cost fact, because it is load-bearing for anyone comparing tools. Every citation, share-of-names and sentiment number here is a count over answer rows the run already produced. There is no second model pass and no judge call, so adding a metric can never move the spend ledger. Only engine breadth costs money. That is why scanning many pages at once and adding metrics are separately priced problems, and why a fix sprint is priced on work rather than on API calls.

What to ask before you buy one

If you are evaluating anything sold as a Gemini or AI Overview citation tool, these are the questions that separate a measurement from an inference. Every one of them is answerable in a sentence by a vendor who knows their own pipeline, which is itself the test.

Which surface did you call. Gemini API with search grounding, Gemini app, AI Mode, or an AI Overview in a results page. If the answer is vague, it is the API, because that is the only one with a documented contract. Ours is the API, and the answer registry names the model on every answer.

What do you do with grounding redirect URIs. Drop, credit to the redirect host, follow, or count as unattributable. There are only four answers and each one has a different failure mode. Ours is the fourth.

Can you distinguish "the engine reported no sources" from "the engine returned no source list". If not, one of those is being printed as the other, and the direction of that error is always flattering to the tool.

How many sources per answer do you ingest, and how many rows does the table display. A tool with an ingest cap and no disclosure produces stable-looking counts that are partly an artefact of its own parser. Ours ingests eight and displays twenty hosts.

What does the report say when an engine did not run. If a plan gate, a missing key and a budget stop all render as a zero, the product is teaching customers a false lesson every week.

Here is our own list of what this product does not do yet, in the same spirit. It does not measure AI Overviews or AI Overview eligibility. It does not resolve grounding redirects, so a citation table with a high opaque count is largely unread. It does not check Googlebot crawlability, because Googlebot is not in the bot registry, and whatever Search can reach is upstream of what a Search results page can show. It does not read your Search Console. It does not distinguish AI Overview referral clicks from ordinary Google clicks. It does not cap grounded coverage yet, so heavy months can exhaust the counter. Each of those is written down somewhere in this repository, which is where we would rather have it than in a support conversation.

For the half of the problem that is actually within your control, the reference layer is the better use of an hour than any dashboard, because it is about the pages rather than the scoreboard. How to get cited is the index, with per-platform pages including ChatGPT, Claude and the Google AI Overviews page already mentioned. The structural work sits under fix guides by stack and the free tools, including what GPTBot sees on your page, which is the closest thing here to a direct read of what a model receives. The concepts behind the checks are in the glossary, particularly structured data, prose parity and entity confidence, and the two posts worth reading next are five signals that tell AI who you are and what a crawler meets on a real storefront. If you want to see the grounded answers themselves rather than read about them, that is what AI says about you, and the aggregate scan picture we are willing to publish is on the research page.