Google Search Grounding, Explained

Part of a series on running AI workflows across model providers — this one's about the specific problem of models not knowing what happened this morning.

Every language model has a knowledge cutoff, and every language model will occasionally answer a question about current events, prices, or availability with something confident and wrong. Retrieval against your own knowledge base fixes this for information you own. It does nothing for information that lives on the open web and changes daily — a stock price, a product's current specs, whether a store is still open. Gemini's built-in Google Search grounding is Google's answer to that specific gap, and it's worth understanding how it actually works rather than just knowing it exists.

What it actually does

When grounding is enabled, Gemini can decide, mid-response, that a question would benefit from a live web search — and run one, automatically, as part of answering. You're not managing a separate search API call, parsing results yourself, and stuffing them back into a follow-up prompt. It's one call in, one grounded answer out, with the search step handled inside the request.

The mechanism is straightforward to enable: passing a Google Search tool declaration alongside your prompt is enough. The model decides, per request, whether searching is actually useful for that particular question — it's not forcing a search on every call regardless of need.

What comes back with the answer

Grounded responses carry more than just the final text:

Search queries the model actually ran. You can see what it searched for, not just what it concluded — useful for debugging a wrong answer, since you can tell whether the search itself was off-target or the model misread good results.

Inline citations. Specific spans of the output text are annotated with which source URL backs that particular claim — not just a general "sources" list at the bottom, but per-passage attribution. That's what lets you build a UI that shows this specific sentence came from that specific page, the way a well-built research tool should.

Search suggestion content, formatted for display, if you want to show users what else the model found along the way.

[ User question ] ──► [ Gemini + optional Google Search ] ──► [ Answer + citations ]

The search step and the citations both happen inside the one call.

Why per-sentence citation matters more than it sounds

A model that says "according to several sources, X is true" is asking for trust it hasn't earned. A model that says "X is true [→ source]" and lets you click through to verify is doing something different — it's making its own claim checkable, sentence by sentence, rather than asking you to take the whole paragraph on faith. For anything customer-facing where being wrong has a real cost — pricing, availability, compliance-adjacent questions — that difference is the whole point.

A real use case: a shopping assistant that isn't stale

Say you're building a product-recommendation assistant for an e-commerce app, and customers ask things like "is the X-500 still in stock anywhere" or "what's the current price on this." Without grounding, the model answers from training data that could be months old — confidently, and wrong, in a way that erodes trust fast the first time a customer catches it. With Google Search grounding routed through DNotifier, the same question triggers a live search, and the response reflects what's actually true right now, with a citation the customer can check themselves if they don't believe it.

const answer = await notifier.sendAI({
  senderId: userId,
  message: {
    text: "Is the X-500 model currently in stock, and what's the going price?",
  },
  tools: [{ type: "google_search" }],
});

That single flag is the difference between an assistant confidently guessing and one actually checking.

The billing model, and why it's not one-size-fits-all

Pricing for grounding differs by Gemini generation. On the current Gemini 3 model family, billing is per search query actually executed — a request that triggers three separate searches costs more than one that triggers a single search or none at all. On the older Gemini 2.5 generation, billing works per prompt rather than per search, regardless of how many searches ran underneath it. The practical implication: if you're on Gemini 3 and letting the model decide freely how many searches a complex question deserves, it's worth watching actual search-count patterns in production rather than assuming a fixed cost per call.

Where grounding isn't the right tool

Grounding solves "the answer depends on live, public web information." It doesn't solve a few adjacent problems that look similar:

Your own private or internal data. That's what a connected knowledge base and RAG are for — Google Search grounding only reaches the public web, not your product database or internal docs.

Deterministic lookups you already have an API for. If you already have a real-time inventory API, calling that directly is more reliable and usually cheaper than asking a model to search the web for the same fact.

Anything where "roughly current" isn't good enough. Search results reflect what's indexed and public at query time, which is usually fast but isn't instantaneous — for genuinely real-time data (a live auction price, a stock quote mid-trading-day), a direct data feed still beats grounding.

Frequently asked questions

Does grounding work with DNotifier's own knowledge base retrieval at the same time?

Yes — they're independent tools. A single Gemini call can draw on your connected knowledge base for internal content and Google Search grounding for public, current information, depending on what the question actually needs.

Can I force grounding to always run, rather than letting the model decide?

The tool declaration makes search available to the model; whether a specific query benefits from it is generally left to the model's judgment per request, which is usually the right default since not every question needs a live search.

Is grounded output guaranteed to be accurate?

No — grounding substantially reduces the "confidently wrong from stale training data" failure mode, but it inherits whatever's actually on the web pages it searches, which can itself be outdated, biased, or wrong. Citations are what let you or your users verify rather than just trust.

Does this work through DNotifier the same way it works calling Gemini directly?

Yes — the grounding tool declaration passes through DNotifier's sendAI() call the same way any other Gemini-specific feature does; you're not losing access to it by going through the orchestration layer.

How is this different from a general "web search plugin" pattern other providers offer?

The underlying idea — let the model search the web mid-answer — isn't unique to Gemini. What's specific here is that it's Google's own search index, natively integrated, with per-passage citation metadata built into the response format rather than something you construct yourself from raw search results.

The Bottom Line

Next in this series: Google's own Agent Development Kit, and where its all-in-on-Gemini approach differs from building on a model-agnostic layer.

Read part one: Gemini on DNotifier: Setup Guide. Explore dnotifier.com.