8 月中旬接了一个母婴零售站的生成式引擎优化（Generative Engine Optimization, GEO）诊断，翻遍全站 1,200 个商品页的 JSON-LD，category 字段清一色写着「商品」两个字。AI 搜索引擎拿到的类目信号等于零，商品自然进不了候选集。这篇把当时的排查过程和改造方案拆成三条规则讲清楚：映射表怎么建、三个字段各管什么、AI 引擎拿类目词去干什么。

现场还原：1,200 个商品页，category 全是「商品」

用脚本顺着 sitemap 扫了一遍商品页的 application/ld+json，结果比预想的还整齐：

• 1,183 个商品页的 Product.category 值为「商品」，占比 97.4%；
• 剩下 17 个页面写了「母婴用品」「家居日用」这类一级大类，同样细不到叶子层；
• 站内真实的类目树其实有四层：大类 > 品类 > 子类 > 款式，共 214 个末级类目，但这套树只活在导航栏和筛选器里，从未进入结构化数据。

先做了一轮基线测试：挑 60 条品类问句喂给主流 AI 搜索（比如「推荐一款适合新生儿的分腿睡袋」「有无纯棉 A 类标准的婴儿床品」），记录回答里是否出现本站域名、是否出现与本站商品对应的细分类目词。结果 60 条里只有 4 条回答提到本站，出现「婴儿睡袋」这类类目锚点词并同时带出本站的，只有 1 条。

类目栏全站一个泛分类，等于告诉 AI 引擎：这个站的商品没有品类属性，没法归档，也就没法在回答里被按品类召回。

AI 引擎读类目的机制：类目是召回的分诊台

这里把机制说透。AI 搜索引擎抓到商品页后，并不会像传统爬虫那样只存正文，而是把结构化数据解析成一堆实体槽位：品牌是什么、价格区间、属于哪个品类、有什么属性。其中类目槽位承担「分诊」职能——回答引擎生成内容时，先根据问句语义锁定一个候选品类集（比如「婴儿睡袋」），再从已索引的商品实体里筛出类目匹配的那些进入候选池。

flowchart LR
    A[商品页 JSON-LD] --> B[抓取并解析结构化数据]
    B --> C{category 能否归档}
    C -- 泛分类「商品」 --> D[无法进入候选品类集]
    C -- Taxonomy 叶子类目 --> E[锁定候选品类集]
    E --> F[回答文本落下类目锚点词]
    D --> G[商品实体被跳过或降权]

如果 category 是「商品」，这个实体在分诊环节就挂了：候选池建立阶段根本轮不到它，后面的价格对比、属性补充、链接引用全部无从谈起。这就是为什么那家站 60 条问句只命中 4 条——不是内容不行，是入口就被关了。

类目词在最终回答里的「落点」也有讲究。回答引擎倾向把品类词作为叙述锚点，比如「挑选婴儿睡袋时可以关注……」，锚点词一旦出现，引擎会顺手挂上同品类的商品链接。类目词命中回答文本，是被推荐的前置条件。

映射表怎么建：站内类目树对齐 Google 商品分类体系

Google 维护了一套公开的商品分类体系（Google Product Taxonomy），每条分类是一条全路径，形如「服装与配饰 > 婴幼儿服装 > 婴儿睡袋」，官方提供包括简体中文在内的多语言版本，并有明确的版本号和更新节奏。做 GEO 改造时，映射表是地基，我们的表结构长这样：

建表流程没有秘密，就是把「按末级类目名查官方分类」这件事自动化，剩下的疑难杂症走人工队列。当时的脚本逻辑如下：

# 依赖：Python 3.10+，无第三方库
# 环境：内网跳板机运行，taxonomy 文件用官方发布的简体中文版文本文件
# 用法：python build_category_map.py shop_categories.csv taxonomy_zh-CN.txt
import csv
import sys
import unicodedata

def load_taxonomy(path):
    # 读官方分类文件，建立「末级分类名 -> 全路径列表」倒排索引
    leaf_index = {}
    with open(path, encoding="utf-8") as fh:
        for line in fh:
            full = line.strip()
            if not full:
                continue
            # 全路径形如：服装与配饰 > 婴幼儿服装 > 婴儿睡袋
            leaf = full.split(" > ")[-1]
            key = unicodedata.normalize("NFKC", leaf)
            leaf_index.setdefault(key, []).append(full)
    return leaf_index

def match(row, leaf_index):
    # 入参 row 是站内类目导出的一行，leaf_index 是官方分类倒排索引
    # 返回值：官方分类全路径 + 匹配方式，全路径为空则必须人工复核
    # 匹配策略：末级类目名精确命中 -> 命中一条直接自动通过
    # NFKC 归一化是为了吸收全角括号、不可见空格这类导出噪音
    leaf = unicodedata.normalize("NFKC", row["名称"])
    hits = leaf_index.get(leaf, [])
    if len(hits) == 1:
        # 恰好一条命中才算自动通过，两条以上同名分类必须消歧
        return hits[0], "末级精确匹配"
    if len(hits) > 1:
        # 命中多条说明有同名分类，交给人工按上级路径消歧
        return "", "人工复核"
    # 精确未命中，退化成包含匹配，命中同样进人工队列
    # 包含匹配只做兜底，结果同样要过人工复核再落表
    for leaf_name, paths in leaf_index.items():
        if leaf_name in leaf or leaf in leaf_name:
            return paths[0], "关键词匹配"
    # 兜底也没命中：站内自造类目词，落人工复核
    return "", "人工复核"

leaf_index = load_taxonomy(sys.argv[2])
with open(sys.argv[1], encoding="utf-8") as fh:
    # 站内类目按在售 SKU 数倒序排，优先处理流量大的类目
    rows = sorted(csv.DictReader(fh), key=lambda r: -int(r["sku_count"]))
    for row in rows:
        taxonomy, method = match(row, leaf_index)
        print(f"{row['id']},{row['full_path']},{taxonomy},{method}")

跑完这版脚本，214 个末级类目里 137 个自动通过，61 个走关键词匹配进人工队列，16 个确实在官方体系里找不到对应（比如「宝宝辅食盒」这类跨界品），按最接近的父级分类落位并在映射表里标注了争议。映射表是资产不是一次性脚本，官方分类每年更新版本，映射表要跟着比对 diff。

category、AdditionalProperty 与 BreadcrumbList：三个字段各管一段

规则二解决字段分工。很多团队的困惑是：类目语境到底写在哪、要不要重复写。我们定下的口径是三条线，各管一段：

1. Product.category 是单值字符串，只写映射后 Taxonomy 全路径的最细一级，整条全路径用「 > 」连接。不要塞数组、不要堆同义词、不要把品牌词混进去。
2. AdditionalProperty 承担属性语境，类目之外的尺码、材质、适用月龄、执行标准都放这里，用 PropertyValue 的 name/value 成对表达，帮 AI 引擎补全商品属性槽位。
3. BreadcrumbList 表达站内导航语境，面包屑链上的类目词必须与 category 的分类语境一致——category 写了「婴幼儿服装 > 婴儿睡袋」，面包屑就不能是「首页 > 母婴专区 > 精选推荐」这种运营位链路。

语境一致性是最容易被忽略的一条。AI 引擎会把面包屑和 category 做交叉校验，两边对不上，实体可信度就打折。三个字段如何被引擎组合使用，见下面的时序：

sequenceDiagram
    participant E as AI 搜索引擎
    participant C as Product.category
    participant P as AdditionalProperty
    participant B as BreadcrumbList
    E->>C: 读取单值类目（Taxonomy 全路径）
    C-->>E: 归入候选品类集
    E->>P: 读取属性语境（月龄/材质/标准）
    P-->>E: 补全商品属性槽位
    E->>B: 校验导航链与类目语境一致
    B-->>E: 站内层级可信度确认
    E->>E: 回答文本落下类目锚点词并引用商品

落到商品页 JSON-LD 里就是下面这个样子（注释仅作讲解用，实际部署时去掉注释行）：

{
  "@context": "https://schema.org",
  "@type": "Product",
  // name 与品牌语境保持常规写法，本例重点看 category 与属性块
  "name": "纯棉分腿婴儿睡袋 春秋款",
  // category 只写一个值：官方分类体系里最细一级的全路径
  // 全路径用「 > 」连接，层级从粗到细，不塞数组不堆同义词
  "category": "服装与配饰 > 婴幼儿服装 > 婴儿睡袋",
  "brand": { "@type": "Brand", "name": "Example Baby" },
  "offers": {
    "@type": "Offer",
    "price": "129.00",
    "priceCurrency": "CNY",
    // 价格与库存语境放 offers，与类目字段互不干扰
    "availability": "https://schema.org/InStock"
  },
  // 类目之外的属性语境全部收进 additionalProperty
  // 每条属性 name/value 成对出现，帮引擎补全商品属性槽位
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "适用月龄", "value": "0-18个月" },
    { "@type": "PropertyValue", "name": "面料", "value": "100%棉" },
    // 执行标准这类权威属性对可信度加成明显，建议单独成条
    { "@type": "PropertyValue", "name": "执行标准", "value": "GB/T 23158" }
  ],
  // 面包屑的末级词必须与 category 的类目语境对齐
  // 不能写「首页 > 活动专区 > 爆款推荐」这类运营位链路
  "breadcrumb": {
    "@type": "BreadcrumbList",
    "itemListElement": [
      // position 从 1 开始，逐级对应类目树的上层与末级
      { "@type": "ListItem", "position": 1, "name": "婴幼儿服装" },
      { "@type": "ListItem", "position": 2, "name": "婴儿睡袋" }
    ]
  }
}

模板批量下发到商品详情页渲染层，1,200 个页面两天内全部替换完成，category 字段覆盖率从 2.6% 拉到 100%。

改造前后：AI 回答里的类目词命中对照

结构化数据改完不等于立刻见效，抓取和索引有滞后。8 月 20 日全量下发，9 月 5 日用同一组 60 条品类问句复测，对照数据如下：

几个具体的对比例子更直观：

复测结论和当时预判一致：类目信号修好之后，AI 搜索回答里最先回来的是品类锚点词，其次才是商品引用。 类目词命中率翻到六成多，站点被引用的量翻了三倍，中间的差距是属性语境（AdditionalProperty）和站内内容厚度补的，那是另一个话题。

三个容易踩的坑

• category 填了但只填到大类。 「母婴用品」这种一级大类对分诊环节几乎没有增益，务必写到映射表里 Taxonomy 的叶子层。宁可部分类目暂时空缺走人工复核，也别全站先上一个粗粒度值凑数。
• 面包屑用运营位链路。 首页 > 活动专区 > 爆款推荐这种链路和 category 完全对不上，引擎交叉校验直接扣可信度。面包屑必须走类目树的实时数据源。
• 官方分类更新后映射表不动。 Google 商品分类体系有版本号，每年都会增删调整。我们把这步挂进了季度任务：下载新版文件，diff 出变化项，回放映射表，改动超过 20 条就重新过一遍人工队列。

误区澄清与趋势判断

常见误区是把「填了 category」当成终点。类目字段的价值不在字段本身，而在它把商品实体接进了 AI 引擎的品类召回体系——分诊台进不去，后面所有优化都是空转。另一个反向误区是过度填写：往 category 里堆关键词、塞多个值，引擎解析到的是脏数据，效果反而差，单值、叶子层、语境一致这三点守住了就够了。

趋势上看，主流 AI 搜索正在把购物类问答往「品类意图识别 + 商品实体推荐」的方向收紧，类目层级的语义利用会越来越深。零售站与其等着引擎猜自己的类目，不如主动把站内类目树翻译成官方分类语言送上去。改造细节或映射表字段设计有疑问，欢迎评论区交流。

参考与延伸

• Schema.org Product 定义与属性说明：https://schema.org/Product
• Schema.org BreadcrumbList 定义：https://schema.org/BreadcrumbList
• Schema.org PropertyValue 与 AdditionalProperty：https://schema.org/PropertyValue
• Google 商品分类体系官方文档与多语言文件下载：https://developers.google.com/shopping-content/guides/product-taxonomy

GEO · AI 搜索 · Product.category · Google 商品分类 · 类目映射 · 结构化数据 · 零售电商