GEO-029·Issue 03·Strategy & Market·29 / 132
Build a Category Tree AI Can Understand
Internal tree, marketplace node, and Google product category are three languages. Build the mapping table that translates them, with five steps and limits.
Issue focusGet Understood: Product Entities, Structured Data, and the Product Graph
Early March, a specialty-coffee gear brand ships a pour-over starter kit to its US and German stores. A week later someone asks ChatGPT for the best beginner setup and gets three kits, one discontinued, none theirs. Crawling is clean, Product schema validates, prices match the feed. The fault sits a level up: the site files the kit under Gear > Kits, the marketplace list sits under drippers, and the Google product category still carries the old grinder ID.
Your internal tree, the marketplace node, and the Google product category are three languages — GEO builds the translation between them, not a winner.
Three category systems, three languages
Treating the three as one system is the most common reason a taxonomy rebuild fails. Each has a hard constraint; none substitutes for another.
| System | Serves | Decides | Maintained by |
|---|---|---|---|
| Internal tree | Buying, merchandising, campaigns, stock | Site navigation, page ownership, reporting | Merchandising and operations |
| Marketplace category | The platform’s search, filters, fees, compliance | Whether you can list, required attributes, who finds you | Platform rules, seller picks |
| Google product category | Shopping ads, free listings, comparisons | Feed classification, comparison surface | Google maintains, seller supplies |
Internal trees grow from team habits: margin, supplier, seasonality — dimensions no buyer asks in. The marketplace node is forced; pick wrong and required attributes follow it down. Google’s taxonomy is a fixed ID set; a product can carry several, the first primary. As of March 2026, confirm field definitions in Google’s documentation, not a copied list.
The three do not need to merge, but they must translate. A SKU that cannot be translated is distorted at every entry point.
The category page is where AI lands, not a warehouse shelf
When a buyer asks for a complete beginner setup, the model does not start with keyword matching. It draws a boundary around a set of products, defined by five things: the category page, breadcrumb, URL path, internal links, and the category field in the product data.
Point all five at one parent and the product becomes a comparable entity. Point them five ways and the model gets conservative: downgrade to a single item, or skip the set. Consistency beats precision. AI does not need your category name to match Google’s wording; it needs one answer to “where does this belong.” That is the graph behind the product graph AI reads.
A team lifted Google’s top-level taxonomy into site navigation, so the menu read Glassware, Drinkware, Cookware & Bakeware. Buyers arrive with scenes — can I brew at a campsite, does it fit a shared desk — and a comparison taxonomy has no slot for one. The category page becomes a shelf: AI crawls product names and finds no sentence about how to choose.
A mapping table, then five steps
The table is not a document but data in a system. Every field earns its place.
sku_idand variants: which is the parent, which are color and size. Variants do not get categories.internal_path: the full site path, with depth.- Platform plus
platform_category_id: one column per platform. google_category_idwith the full path: the ID, not free text.primary/secondary: primary sets breadcrumb, URL, and canonical; secondary only cross-links.buyer_question: the sentence this category answers. Cannot write it, the category should not exist.ownerandlast_verified.
| Step | What you do | Owner | Passes when |
|---|---|---|---|
| 1 Inventory | Export live SKUs with internal path and both category IDs | Merchandising and engineering | One row per SKU, no empty columns |
| 2 Assign primary | One primary, at most two secondaries, each with its question | Merchandising and operations | 30 SKUs checked, single primary, secondaries linked |
| 3 Fix structure | Clickable breadcrumbs, four levels max, server-rendered subcategories | Engineering | JS off still yields links and titles |
| 4 Align the feed | Load the same table into marketplace backends and the shopping feed | Engineering | IDs in backend, feed, and table match |
| 5 Re-test | Run the same question set, check where AI answers land | Growth | Landing URLs trace back to table rows |
Step 4 is the one teams skip: one edit in the backend, one in the sheet, and the copies diverge without raising an error.
Depth, breadcrumbs, one canonical path
Depth is not the problem; a broken chain is. Three or four levels is enough. Go deeper and a middle level with links but no content is a shell: AI crawls links, finds nothing quotable. Depth pays only when navigation stays crawlable without JavaScript.
Breadcrumbs must be clickable and exist once. Breadcrumb, URL path, and category field must agree; a JavaScript-only breadcrumb is absent to a no-JS fetch.
One canonical path per SKU. A tumbler belongs to outdoor and kitchen. Primary sets the path, secondary cross-links. Duplicated URLs leave copies that disagree on attributes, so the model trusts neither.
Example: one starter kit in three systems
Example — a fictional specialty-coffee gear store, about 120 live SKUs, no real brand or figures. Its kit is the failure: a bundle with no standalone SKU on the site, sold as single items on the marketplace, tagged with Google’s old grinder ID.
Three fixes. Create a bundle entity stating contents, substitutions, and warranty. Add a three-level path such as /coffee/brewers/pour-over-starter-kit/ with a self-referencing breadcrumb and an opening section on assembling a first setup. Align the systems: marketplace node for the bundle, Google primary from the kit’s main component, grinder as a secondary cross-link, no second URL.
Acceptance: with JS off the page shows contents and price; the beginner questions resolve here, not the campaign page.
Where this breaks
A single-category brand with a few dozen SKUs. The table is over-engineering; a hand-kept crosswalk and a sitemap suffice. Spend the time on attributes.
Categories that close inside a marketplace. The platform node and required attributes come first; a tidy site tree buys no recommendation slot.
A PIM migration in flight. Settle product master data first; a table built on a moving tree expires within a quarter.
Multi-language markets. Add a locale column; translated names drifting from platform IDs is the common silent error.
Generated mappings. Never accept model-written rows unchecked: one wrong digit files a product into the wrong comparison silently. Sample against entity coverage, not by eye.
This month, take the second-level category buyers ask about most, complete the three category fields for its 20 to 30 SKUs into one table, validate 10 rows in the marketplace backend and feed checker, and write “how to choose in this category” atop the page. One category first. The rest of this line lives in the strategy and market hub.