直接结论
出海品牌应把Product.category作为商品实体治理字段，而不是随手添加的SEO关键词。先确定内部类目、Google Product Taxonomy对应值、目标市场和产品变体范围，再让页面可见分类、Merchant Center feed与JSON-LD表达一致；无法确认的标准代码不要猜。
官方变化是什么
Google Search Central在2026年7月7日更新Merchant listing文档，说明Product.category既可使用Text，也可使用CategoryCode。官方指出，这与Merchant Center中的product_type和google_product_category属性对齐，使商家可以同时表达自定义分类与Google定义的分类信息。
Text适合承载企业自己的商品树，例如“工业视觉检测设备 > 表面缺陷检测”；CategoryCode适合使用明确的分类体系代码。两者解决的是语义表达和数据一致性问题，不是把一串热门词塞进Schema。页面正文、面包屑、分类导航、Product实体和Feed若互相矛盾，新增字段反而会放大歧义。
对品牌出海企业的影响
对多品类出海企业，分类是AI理解“产品属于什么、与什么比较、适合什么任务”的基础。网站常见问题是中文ERP、英文官网、经销商目录和Merchant Center各有一套类目名称，导致同一SKU被描述成不同产品族。建立统一映射后，产品页、集合页、Feed和知识页可以共享稳定术语。
B2B产品尤其需要避免消费品式的宽泛分类。一个产品既可能被归入行业类目，也可能按应用、工艺或安装方式组织。Product.category只能承载选定分类，不会替代model、sku、brand、manufacturer、material、audience或适用场景。复杂产品应在可见正文中说明分类依据与边界。
多语言站还要处理翻译与代码的关系。标准CategoryCode可保持跨语言稳定，自定义Text则应由术语表控制，避免同一类别在英语、西班牙语和中文站点中出现多个不一致翻译。hreflang页面之间的产品实体应使用相同@id或可追踪映射。
智核增长的判断
智核增长认为，这次更新的价值在于让“类目”进入页面级SSOT，而不是多加一个Schema属性。企业应先决定谁维护分类、何时变更、哪些系统是源头、哪个字段面向Google，再生成标记。没有治理流程的Schema很快会落后于ERP和商品Feed。
对于品牌出海GEO，类目一致性可以帮助形成产品到知识、FAQ、证据和应用场景的解释链。例如产品页声明类别，知识页解释选择标准，FAQ回答边界问题，证据页提供认证或测试。AI在检索某个应用时，更容易找到相互支持而非互相冲突的页面。
执行清单
- 1. 导出官网、ERP、PIM与Merchant Center现有类目，建立一张字段映射表。
- 2. 为每个核心产品确定自定义product_type与Google标准分类，保留版本和负责人。
- 3. 在页面可见面包屑或分类说明中使用与Schema一致的术语。
- 4. 确认Product.category挂在正确Product节点，避免把列表页误标为单一商品。
- 5. 抽查语言版本和变体页，确保category、brand、sku与canonical关系稳定。
- 6. 在Rich Results Test和Merchant Center诊断中检查语法，但另行复核事实正确性。
限制条件
Google支持某个属性并不意味着所有页面都会获得Merchant listing展示，也不代表CategoryCode比Text具有更高排名权重。结构化数据必须与页面可见内容相符并满足完整资格要求。
Google Product Taxonomy和企业内部类目可能随业务变化。若产品横跨多个用途，应选择最能代表销售实体的分类，并在正文解释其他适用场景，不宜堆叠互相冲突的代码。
官方来源
- Google Search Central：Merchant listing structured data用于核对Product.category、Text、CategoryCode及商品标记要求。
- Google Search Central：July 2026 documentation updates用于核对7月7日更新原因及与Merchant Center字段的对齐关系。