品类树怎么建，AI 才听得懂

三月上旬，一家做手冲咖啡器具的独立站刚上完新品。运营在 ChatGPT 里问“新手手冲套装买哪套”，答案列了三个品牌，其中一个型号去年就停产了，他们自己的套装没出现。技术同事查了一圈：页面能抓、schema 有、价格也对。问题出在类目——站内把套装放在“器具 > 套装”，Amazon 上挂在滤杯节点下面，Google 商品类目填的是三年前那版磨豆机的 ID。

内部品类、平台类目与 Google 商品类目是三套语言，GEO 不是挑一套统一，而是建一张映射表，让 AI 在任何一套语言下都能走到同一个商品。

三套类目，三种语言

把三套类目当成同一件事，是品类重构最常见的失败原因。它们各有硬约束，谁也不能替代谁。

体系	为谁服务	决定什么	谁在维护
内部品类树	采购、运营、活动与库存	站内导航、页面归属、报表口径	商品与运营团队
平台类目（Amazon、Shopee 等）	平台的搜索、筛选、佣金与合规	能不能上架、必填属性、被谁搜到	平台定规则，卖家选节点
Google 商品类目	购物广告、免费商品列表与比价	feed 里怎么归类、进哪个比较场景	Google 维护分类，卖家填 ID

内部树按团队习惯长出来，常带毛利、供应商、季节这些运营维度，买家从不会这样发问。平台类目是强制题：节点选错，跟着错的是必填属性与筛选条件。Google 类目是一套固定 ID，一个商品可填多个，第一个算主类目；截至 2026-03，字段与层级仍以官方文档为准，别抄二手清单。

判断： 三套语言不必合并，但必须能互相翻译；翻译不出来的 SKU，在三个入口里都会失真。

类目树是 AI 的落点，不是仓库的货架

买家问“适合新手的整套手冲器具”时，AI 不会只拿关键词匹配标题。它先要框出一组商品，边界由五样东西共同定义：类目页、面包屑、URL 路径、站内链接、商品数据里的类目字段。

五样指向同一个父类，商品才是一个能被比较的实体；指向五个方向，模型只能按最保守的方式处理——要么降级成单品，要么干脆不选。这五样拼起来，就是AI 眼里的商品实体。一致性因此比精确度更重要：AI 不需要类目名和 Google 一字不差，它需要“这件商品属于哪里”只有一个答案。

反例很常见：有团队把 Google 类目直接搬成站内一级导航，导航变成 Glassware、Drinkware、Cookware & Bakeware。买家带着场景来——露营怎么煮咖啡、办公桌放不放得下——场景在比价分类里没有位置。类目页退化成货架，AI 抓到一屏商品名，摘不出一句“这一类怎么选”。把比价引擎的标签当导航结构，是这套体系最典型的误用。

映射表的最小字段

映射表不是一份文档，是一份要进系统的数据。字段多一个没人填，少一个就断链。

sku_id 与变体关系：哪个是主 SKU，哪些是颜色尺码变体；变体不单独建类目。
internal_path：站内完整路径，附层级深度。
平台 + platform_category_id：一个平台一列，不要混填。
google_category_id 与完整路径：填 ID，不填自由文本。
primary / secondary：主类目决定面包屑、URL 与 canonical；副类目只做交叉链接，不复制 URL。
buyer_question：这个类目回答买家的哪一句话。写不出来，说明这个类目不该存在。
owner 与 last_verified：谁负责、上次核对是哪天。

落地分五步，每步都有验收口径：

步骤	做什么	谁来做	怎么算过
1 盘点	导出在售 SKU、内部路径、各平台类目 ID、Google 类目 ID，按 SKU 对齐	商品与工程	每个在售 SKU 一行，四列都不空
2 定主类目	每个 SKU 指定一个 primary，最多两个 secondary，并写清它回答哪句话	商品与运营	抽查 30 个 SKU，主类目唯一，副类目都有交叉链接
3 改结构	面包屑可点、层级不超过四层、类目页由服务端输出子类目与头部商品	工程	关掉 JS 仍能拿到链接与商品标题
4 对齐 feed	同一张表直接灌进平台后台与购物 feed，不手工二次填写	工程	后台与 feed 里的类目 ID 和表一致
5 复测	用同一批问题看 AI 答案的落地页是否回到你的类目页或商品页	增长	落点路径与映射表能对上，而不是“整体变好了”

第 4 步最容易被跳过：后台改一次、表里改一次，两份数据从第二天起就不一样，而且不报错。

层级深度与面包屑：三条判断

第一，深度不是问题，断链才是。 三到四层足够。再深一层时，中间层若只有链接没有内容，就是空壳：AI 抓到十几个链接，没有一句可摘的话。

第二，面包屑要可点，且只有一个版本。 商品页面包屑、URL 路径、商品数据里的类目三处必须一致。靠 JS 渲染的面包屑，在无 JS 抓取里等于不存在，这和给 AI 看的导航是同一笔账。

第三，一个 SKU 只能有一个 canonical 路径。 多父类目是现实：保温杯既属户外也属厨房。做法是主类目定路径、副类目做交叉链接，不复制 URL。复制之后同一件商品有两份可能不一致的属性，AI 不知信哪份，最后两份都不用。

示例：一套手冲器具的三套类目

示例：一个卖手冲咖啡器具的独立站（假设场景，不含真实品牌与数据），在售约 120 个 SKU，内部树两层：器具下有滤杯、手冲壶、磨豆机、套装，耗材下有滤纸、咖啡豆。

问题在于“套装”是组合商品：站内没有独立 SKU，只在活动页出现；平台把套装拆成单件挂；Google 类目沿用早期磨豆机的 ID。三个体系各说各话，AI 只看到三件互不相关的器具。

改法三步。给“入门套装”建一个组合实体，表里写明包含哪几件、可替换哪件、清洗与保修怎么算。站内新增三级路径 /coffee/brewers/pour-over-starter-kit/，面包屑自指，页首写“新手第一套手冲器具怎么配”，列出组成、替代方案与不适合谁。三套体系对齐：平台节点选套装所属类目，Google 类目以套装主件（滤杯）为主类目，磨豆机作副类目交叉链接，不新建 URL。

验收只看两条：关掉 JS 打开套装页，能看到包含清单与价格；同一批“新手手冲”问题复测时，落地页指向这条路径而不是活动页。两条都过，再复制到第二个套装。

边界：什么时候不该建这套映射

SKU 只有几十个的单品类品牌，映射表是过度工程。一张手工对照表加 sitemap 就够，时间该花在属性与证据上。

成交几乎全在平台内的品类，平台类目与必填属性优先。站内树改得再整齐，也换不来平台内 AI 的推荐位；节点选错，listing 连曝光都拿不到。

主数据正在换 PIM 或类目重组时，先别建映射。先统一商品主数据，再谈映射；建在一棵会动的树上，表三个月就失效。

快时尚与季节性上新，层级越深越容易过期。用标签页和场景页替代深树，类目只留稳定的那一层。

多语言市场要多一列 locale：每个语言各写一版类目名，再和平台类目 ID 对上。翻译后的类目名与 ID 错位，是跨境站最常见的隐性错误。

最后一种误用是让模型一次生成几千行映射，不做抽样校验：类目 ID 错一位，商品就进错比较场景，全程不报错。抽查口径可以用实体覆盖率，别靠肉眼。

类目映射是这条线的地基，属性、标题与对比页都接在这张表上，其余文章在战略与市场主题页。

这个月，先做一件事：挑一个被问得最多的二级类目，把它的 20–30 个 SKU 的三套类目字段补全成一张表，抽查 10 个用平台后台与 feed 的校验功能跑一遍，再在类目页顶部写出“这一类怎么选”。一个类目跑通，再谈全站。