Gemini Deep Research Max ships blended retrieval: agents fuse the public web with private files, CRM, and MCP servers. What it means, plus 3 fixes to make now.
Until this spring, every AI visitor to your site arrived the same way: empty-handed. It fetched your page, read it against other pages, and decided whether you were worth citing. That model just changed. The agents now arriving from Gemini Deep Research Max carry the user's own data with them, and they judge your page against it. Your pricing table is no longer competing with a rival's pricing table. It is competing with the contract PDF the user uploaded ten seconds ago.
Blended retrieval is an AI agent pulling from the public web and the user's private context, in a single reasoning pass, and weighing every source against every other. Google's announcement describes agents that retrieve from "the public web, arbitrary remote MCPs, file uploads and connected file stores, or any subset of them." One pass, one fused answer.
The older pattern was sequential: search the web, summarize, then maybe glance at an attached file. Blended retrieval flattens that. A financial-data MCP server, an enterprise CRM connection, a folder of uploaded documents, and your product page all land in the same context window at the same time, and the model reconciles them together.
For site owners, the consequence is blunt. You used to be the source. Now you are a source, and often not the most trusted one in the room, because the user's private data is, by definition, about the user.
Be precise about the status, because the gap between spec-truth and market-truth is where bad strategy gets written. Gemini Deep Research Max launched on April 21, 2026 as a public preview on the paid Gemini API tier. That is the entire footprint today. There is no consumer rollout, no default-on surface, and no announced date for one.
The coverage itself is careful on this point: most websites will not be read by a blended-retrieval agent this quarter. Treat the launch as a leading indicator, not a traffic event.
Why pay attention at all, then? Because paid API previews are where developer behavior gets set. Whoever is building research tools, deal-analysis agents, or procurement assistants on the Gemini API is wiring blended retrieval into products right now, and the Model Context Protocol those agents connect through passed 97 million monthly SDK downloads as of March 2026. The plumbing is mainstream even if the faucet is not. When a capability this useful exists behind an API, consumer surfaces tend to follow, and the sites that win that wave will have done the structural work during the quiet period. This is the quiet period.
The analysis around the launch uses a phrase worth memorizing: "signal share collapses when the agent has better alternatives." In a blended pass, the weight any single source gets is proportional to how cleanly the agent can extract its signal and fuse it with everything else it is holding.
Walk through a concrete case. A user asks an agent to evaluate vendors for a software purchase. The agent holds the user's budget spreadsheet, last year's vendor contracts from a connected file store, and live pricing from a financial-data MCP. Then it fetches your pricing page. If that page is a clean Product-and-Offer schema block with unambiguous numbers, the agent can line your offer up against the spreadsheet in one step. You get cited, compared, maybe chosen.
If the page is a JavaScript-rendered grid with prices that only appear after a click, the agent has a choice: spend effort untangling you, or lean on the sources it can already read. It leans. Your signal share goes to the user's own files, and you exit the comparison without ever knowing you were in it.
This punishes a specific kind of site: the one that ranked fine in classic search despite messy formatting, because links and authority papered over the structure. Authority does not transfer into a fused reasoning pass. Extractability does. And some queries will now be answered entirely from private context, routing no traffic to any website at all. That slice of zero-click is structural, and no amount of citation optimization claws it back. Your job is to win the queries where public data still matters.
The recommended posture coming out of the launch is "structural predictability: clean entity relationships, canonical identity, live data, rendering independence." That collapses into three jobs, in priority order.
1. Structured data that validates, on every money page. Product and Offer schema get cited more in blended passes because they fuse cheaply: a price in JSON-LD needs no interpretation. Audit your key pages for schema that actually validates, matches the visible content, and carries real values rather than placeholder strings. Our guide to schema markup for AI search covers which types pull weight; for blended retrieval, Product, Offer, Organization, and FAQPage are the ones doing the heavy lifting.
2. One canonical entity identity. An agent fusing your site with a CRM record needs to be certain that "Acme Corp," "Acme Corporation," and "acme.io" are the same entity. Pick one canonical name, one sameAs cluster pointing at your real profiles, and consistent Organization markup across every page. Ambiguous identity does not just weaken you; it can get your data merged with someone else's, or quietly dropped as unreliable. This is the least glamorous fix on the list and probably the highest-payoff one for B2B sites, where the user's private context is full of entity names waiting to be matched against yours.
3. Rendering independence. A page whose content hides behind JavaScript is hard for the agent to merge with the user's private context, so it gets down-weighted or skipped. Load your important pages with JavaScript disabled. Whatever content disappears is content a blended pass may never see. Server-render it, or at minimum make sure prices, specs, and entity facts live in the initial HTML. This is the same fix that AEO work has been demanding for a year; blended retrieval just raised the price of skipping it.
None of these is exotic. That is the point. The sites that lose signal share are not the ones missing some new protocol. They are the ones that never finished the basics.
There is a longer game here. Blended retrieval treats "arbitrary remote MCPs" as first-class sources, sitting in the same reasoning pass as the public web. Today those connections are things users plug in themselves: financial data providers, CRMs, internal tools. But nothing in the architecture limits MCP servers to private enterprise data.
A site that exposes its own MCP endpoint (or a WebMCP interface, the in-browser variant) is offering agents something a crawled page cannot: live, structured, queryable data inside the reasoning loop rather than a static snapshot fetched before it. To be clear, this is our read on where the architecture points, not something Google has announced for Deep Research Max consumer use. No mainstream consumer agent connects to site-owned MCP endpoints by default today.
But the trajectory is legible. The retrieval layer already speaks MCP. The download numbers say developers already build with it. When agent products start letting users (or agents themselves) discover and connect site endpoints, the sites that publish one move from "cited" to "connected," from a page in the pass to a tool in the loop. If you sell anything online, the WebMCP commerce snippet is the cheap way to be early; it no-ops harmlessly on agents that don't speak it.
Sequence matters, though. An MCP endpoint on a site with broken schema and JavaScript-gated content is an advanced feature on an unfinished foundation. Do the three fixes first.
Blended retrieval is real, shipped, and narrow: a paid API preview that most of your traffic will not touch this quarter. That combination is exactly what makes it actionable. The structural work (schema, entity identity, rendering independence) takes weeks, costs little, and pays off in classic search and AEO today regardless of how fast Deep Research Max spreads. Run the JavaScript-off test on your three most valuable pages this week. What breaks is your roadmap.
Written by Crawlytics Team. Crawlytics tracks AI bots, generates llms.txt, and powers WebMCP commerce, all from one snippet on any stack. See how it works →
No. Blended retrieval shipped in Gemini Deep Research Max on April 21, 2026 as a public preview on the paid Gemini API tier only. There is no consumer rollout and no announced date for one, and most websites will not be read by a blended-retrieval agent this quarter. The reason to act now is that developers are building agent products on the API today, and the structural fixes it rewards (validated schema, canonical entity identity, server-rendered content) take time to ship and already pay off in existing AI search surfaces.
No, it adds a layer on top. llms.txt remains the map that tells agents what your site contains and which pages matter; blended retrieval changes what happens after the agent arrives, when your page is fused with the user's private context. The practical update is emphasis: pages you list in llms.txt should be the ones with validated structured data and content that renders without JavaScript, because those are the pages that hold signal share inside a blended pass. A great map to unfuseable pages wins you a fetch and nothing else.
Run three checks. First, disable JavaScript and reload the page: if prices, specs, and key facts vanish, the agent may never see them. Second, validate your structured data and confirm it matches the visible content with real values, not placeholders. Third, search your own site for your company and product names: if the naming is inconsistent across pages, an agent matching your entity against a user's CRM data may fail the match. Then check your logs (or a tracker like Crawlytics) to see whether AI agents are already fetching those pages, which tells you how urgent the fixes are.
This page is part of Crawlytics.app. View all pages: llms.txt · llms-full.txt