The Google Shopping Graph indexes 60 billion products: what it reads from your feed

The Google Shopping Graph reads your product feed for two very different jobs, and confusing them is why most stores misread it: it reads your identifiers — GTIN, brand, MPN — to match your listing to a canonical product it already knows, and it reads your offer — price, availability, shipping — to rank you against everyone else selling that same product. The 60 billion listings Google announced at I/O 2026 is a headline about scale, not about you; the only number that actually decides your visibility is whether your listing cleared the match — a 1 or a 0.

That match is where we spend our attention. We build Contexta, a WooCommerce plugin, and the failure we see over and over isn't a badly written product — it's a good product the Shopping Graph never managed to place, because the one field that would have matched it to an entity was left blank. So here is what the Shopping Graph actually does with your feed, why 60 billion is the wrong number to watch, and the short list of fields that move you from an unmatched island to a ranked contender.

What is the Shopping Graph, and is 60 billion products really the point?

The Shopping Graph is Google's machine-learning dataset of the world's products — not a list of listings but a map of canonical product entities, each stitched together from many sellers' feeds, crawled pages, reviews and web signals. At Google I/O 2026, Google put its size past 60 billion listings, with more than 2 billion of them refreshed every hour, up from roughly 35 billion a few years earlier.

The reason 60 billion is a distraction is that it counts listings, not distinct products. Ten sellers offering the same headphones are ten listings that collapse into one canonical entity, and Google ranks the sellers inside that entity. Your feed isn't adding a 60-billion-and-first product to a pile — it's making a claim to be one of the sellers on a product the graph already holds. Get impressed by the pile and you optimize the wrong thing; the useful question is whether Google placed your listing on the right entity at all. That placement can only happen once your listing is in the graph, which for a WooCommerce store means a Merchant Center free listing — the on-ramp the 60-billion number never mentions.

What does the Shopping Graph actually read from your feed?

It reads your feed for identity first and offer second, and the two are not interchangeable. Identity is the set of resolvable identifiers — GTIN, brand, MPN — that let Google look your item up in its Knowledge Graph and say "this listing is that product." Offer is everything that then competes: price, availability, shipping, the fields that decide your rank once you're matched. A feed can carry a flawless offer and still lose, because an offer on a product the graph couldn't identify is an offer on nothing.

This is why Google requires two of three identifiers — brand, GTIN, MPN — for most products, and why the GTIN is the single field that does the matching. Submit a valid GTIN and Google resolves it to a pre-existing entity carrying brand classification, category, cross-seller pricing and aggregated reviews; leave it blank and Google has to guess from your title and description, which for a commodity product it usually gets wrong or gives up on. The identifier isn't paperwork — it's the difference between joining a comparison and being excluded from one.

Why does the entity match decide everything?

Because the match is a gate, not a dial — you're either on the canonical entity or you're an island, and almost every rich Shopping surface is reserved for the matched. Entity-matched products appear in multi-seller comparison panels, inherit aggregated reviews and specs from across the web, and qualify for the buy-box-style layouts; unmatched listings can be indexed and still never surface in any of it, because there's no entity to attach them to.

Once you're through the gate, the offer fields decide placement, and those are the same fields an AI shopping agent scores a product record on — price against the budget, availability against "in stock," weight against "delivered by." The order is what stores get backwards: they polish the offer fields on a listing that never matched, when the identifier that would have matched it was the cheapest fix on the list. Clear the gate first; refine the offer second.

Is your feed the only thing the Shopping Graph reads?

No — and this is the part that turns a small data problem into a visibility one. The Shopping Graph merges several inputs into each entity: your Merchant Center feed, your crawled product page, your Product schema markup, other sellers' feeds for the same item, and third-party reviews. Google treats your feed and your on-page structured data as two separate inputs it cross-verifies, which is why a price in your feed that contradicts the price on your landing page doesn't just look sloppy — it can get the product disapproved outright.

A self-hosted WooCommerce store is unusually exposed here, because those inputs are generated by different systems that don't talk to each other: core emits the JSON-LD, a feed plugin builds the export, and the theme renders the page. The durable fix isn't reconciling the downstream feed by hand every week — it's engineering the single source those inputs derive from so they can't disagree in the first place. When the graph sees one consistent story about your product across every input, it trusts your claim on the entity; when the inputs contradict each other, it has a reason to distrust the whole record.

Why does this matter beyond the Shopping tab now?

Because the same Shopping Graph is what grounds AI Mode, Gemini shopping and Google's agentic checkout — so the entity match that once decided Shopping-tab placement now gates whether an AI agent can find and buy your product at all. When a shopper asks their assistant to compare options and buy the best one, the assistant is querying the Shopping Graph, and an unmatched island isn't in the candidate set it reasons over.

That collapses what used to be separate optimization projects into one. The feed work that wins a comparison panel is the same work that gets you into an AI Mode or AI Overviews answer and into a Universal Cart an agent fills on a shopper's behalf, because all of them draw candidates from the same graph. As of mid-2026, the merchants pulling ahead aren't the ones with a special "AI feed" — there isn't one — they're the ones whose ordinary Merchant Center data is clean enough to match, everywhere the graph is consumed.

What should a WooCommerce store do about the Shopping Graph?

Fix identity before offer, and consistency before either. Concretely: backfill a valid GTIN on every product that has one, and make sure two of the three identifiers (brand, GTIN, MPN) are present on each SKU so Google can match it; reconcile price and availability across your page, your schema and your feed so nothing contradicts; and confirm those values render without JavaScript, since the crawl half of the graph often builds its record before any script runs.

Doing that across a few hundred WooCommerce products by hand is the sweep nobody finishes, which is the gap Contexta's Commerce Readiness audit is built to close: it checks each product for the identifiers and offer fields the graph matches on — GTIN, brand, price, availability, weight — and returns a per-product fix link, so you're working a list instead of guessing. The 60 billion will keep climbing and it will keep not being about you. Whether your listing cleared the match, on the other hand, is entirely yours to fix.