Google给商品结构化数据加了个category：页面标记和数据源的分类终于对上了

摘要：Google在2026年7月给商家信息结构化数据加了一个category属性，推荐填但不强制。它能写成纯文本，等价于商品数据源里的product_type；也能写成CategoryCode对象，用inCodeSet指向Google的商品分类法、用codeValue填数字ID或者完整路径，等价于数据源里的google_product_category。同批更新还把促销时长的表达方式说清楚了，用validFrom、validThrough配priceValidUntil。这件事真正的分量不在多写一个字段，而在于它第一次让页面上的标记和数据源里提交的分类能对上口径——过去这两套数据各说各话，谁也不知道Google最后信了哪一套。这篇拆清楚两种写法怎么选、路径和ID为什么不能同时给、独立站三大平台各自怎么落地，以及分类口径统一之后对AI购物答案意味着什么。

Google这次到底加了什么？

2026年7月上旬，Google更新了商家信息结构化数据的文档，一共三处新增，其中分量最重的是给Product类型加的category属性。

先把术语理顺。在schema.org的体系里，类型（Type）用来说明一个东西是什么，属性（Property）用来描述这个类型的某个特征。Product是类型，category是挂在它下面的新属性。这个属性不是必填，Google把它列为推荐项。

推荐项这三个字很容易让人直接跳过。过去几年里，被列为推荐但后来变得几乎等同于必需的属性，实在不算少见。

更值得注意的是同批更新的第二件事：促销时长的表达方式。文档明确了用validFrom和validThrough这一对属性来框定促销的起止，配合priceValidUntil使用。Search Engine Land在报道里点明了这次更新的意图：它对齐的是商品数据源里sale_price_effective_date那个字段。

两件事指向同一个方向——把网页上的标记和数据源里的申报，往同一个口径上收。

为什么说“多写一个字段”其实是件大事？

要理解这次更新的分量，得先看清一个长期存在的裂缝。

一件商品在Google眼里其实有两份档案。一份是你在网页上用结构化数据标出来的，另一份是你通过商品数据源提交到商家中心的。这两份档案描述的是同一件商品，但字段体系一直不完全通用。

分类就是最典型的例子。数据源里有google_product_category和product_type两个字段，前者填Google官方分类法里的类目，后者填你自己定义的分类。而在网页的结构化数据里，过去根本没有一个标准位置来表达这件事。

结果就是：你在数据源里把某件商品归到“服饰配件 > 服装 > 连衣裙”，网页上却完全没提这件事。Google拿到两份不一致的档案，只能自己判断该信哪一份，或者自己重新归类一遍。

这个裂缝平时不显眼，出问题的时候很难查。商品在购物结果里被归到了奇怪的类目下，你去查数据源，字段填得好好的；去查网页标记，那里压根没有这个信息。中间发生了什么，全靠猜。

category属性做的事，就是把这条缝焊上。

纯文本和CategoryCode，这两种写法该怎么选？

新属性接受两种写法，它们对应的是数据源里两个不同的字段，用途也完全不同。

纯文本写法：对应product_type

直接把分类写成一个字符串，比如“户外装备 > 电源 > 便携储能”。这等价于数据源里的product_type字段，也就是你自己定义的分类体系，Google不校验内容，你想怎么分就怎么分。文档建议单个值不超过750个字符。

这种写法的价值在于表达你自己的商品组织逻辑。你的站内分类结构、你的导航层级，都可以原样搬过来。

CategoryCode写法：对应google_product_category

这是一个结构化对象，里面有两个关键字段：inCodeSet指向Google的商品分类法，codeValue填具体的类目。schema.org上CategoryCode这个类型本身是个通用设计，codeValue表示唯一标识该值的短代码，inCodeSet表示它属于哪个代码集，继承链是DefinedTerm到Intangible再到Thing。

用在商品上，它表达的就是Google官方分类法里的那个类目。这一套是有标准答案的，不是你自己定义的。

那到底选哪个？

正确答案是两个都写。文档明确说了category可以接受一个数组，纯文本字符串和CategoryCode对象可以混着放。

选择逻辑其实很清楚：CategoryCode是说给Google听的，纯文本是说给你自己和其他消费方听的。前者让Google知道该把你放进哪个标准类目，后者保留你自己的商品组织逻辑，也方便别的抓取方理解你的站内结构。两者不冲突，各干各的活。

codeValue填ID还是填路径，有什么讲究？

这是最容易踩坑的一处，因为文档给了两种格式，而商家中心那边有一条硬规则。

两种格式分别是：填数字ID，比如2271；或者填完整路径，用大于号分隔，比如“Apparel & Accessories > Clothing > Dresses”。

Google商家中心关于商品类别的规范把话说死了：ID和完整路径二选一，不能同时提交；每件商品只能有一个类目；这个字段不可重复。

实际操作里保哥倾向于用数字ID，原因有三个。第一，路径字符串很长，拼错一个空格或者一个连接符就匹配不上，而ID只有几位数。第二，Google偶尔会调整分类法的路径名称，ID相对稳定。第三，路径是有语言版本的，做多语言站的时候用路径会立刻变成一笔糊涂账，ID则跨语言通用。

唯一的代价是ID不可读，你在代码里看到2271完全不知道那是什么。解决办法也简单：在模板里留一行注释，或者在后台的分类管理界面上把ID和名称一起存。

什么时候才该手工指定类目？

这里有个反直觉的地方：Google会自动给你的商品归类，大多数情况下你不需要管。

商家中心的规范列了三种应该覆盖自动归类的情形：

• 为了解锁类目专属的必填字段。某些类目会追加要求，比如服饰类会要尺码、颜色、性别、年龄段，手机类会要型号标识，软件类有自己的一套。不指定类目，这些字段的校验规则就不会生效。
• 为了按类目做广告定向。如果你的广告系列是按商品类目分组投放的，那类目就必须由你自己控制，不能交给自动归类。
• 纠正误判。规范里点名了酒精饮品这一类——被误分类的后果可能是整批商品被拒。

除这三种之外，硬要手工指定反而可能不如自动归类准。这一点和很多人的直觉相反：不是填得越多越好，而是该填的地方填对。

顺带提醒一句，服饰、手机、软件这几个类目会追加必填字段，这意味着你一旦手工指定了类目，可能会连带触发一批原本不存在的校验错误。改完记得回商家中心看一眼诊断报告，别改完就走人。

促销时长这一处，为什么单独拎出来说？

第三处更新是关于促销价的有效期。文档说明了怎么用validFrom和validThrough表达一段促销的起止时间，配合priceValidUntil使用。

这里有一条容易忽略的连带规则：Google的商家信息文档里写明，priceValidUntil一旦过期，商品可能就不再展示富媒体结果了。也就是说这个字段填了但没维护，比不填还糟——不填只是少个信息，填了过期是直接掉展示。

时间格式建议用带时区的ISO 8601。这一条对做出海的团队格外重要：你的服务器在国内，促销活动按目标市场时间开始，不写时区的话差个大半天，促销价要么提前露出要么迟到。

见过一个很典型的翻车：黑五促销价标记里的结束时间写的是本地时间午夜，结果目标市场那边还在周五下午，价格就先掉回原价了。客服接了一下午的投诉电话，技术查了两天才想到是时区的问题。

这套东西和AI购物答案有什么关系？

说到这儿该把视线拉远一点。分类口径统一这件事，在AI购物场景下的分量比在传统购物结果里更重。

原因在于提问方式变了。传统搜索里用户搜的是“便携储能1000W”，匹配靠的是关键词。而在助手里，用户问的是“露营用的电源，能带上飞机的那种，预算三千以内”。要回答这个问题，模型得先理解这是哪一类商品，再在这一类里筛条件。

类目在这个链条里是第一道筛子。如果你的商品在分类这一层就没被正确识别，后面的属性再全也进不了候选池——它压根没进到那个筛选范围里。

这也是为什么保哥认为这个“推荐非必填”的属性值得优先做。它成本极低，一次模板改动的事，但它影响的是最上游的那一道判断。站内讲结构化数据对AI搜索到底有没有用那篇里提过一个基本判断：结构化数据不是排名信号，但它是理解成本的削减器。分类属性是这个判断的一个新例证。

写出来的标记，长什么样？

把上面的规则落成实际的标记，大概是这个形状。假设一件便携储能电源，Google分类法里的类目ID是5710，站内自己的分类是户外装备下的电源。

category那一项是个数组，里面第一个元素是CategoryCode对象，第二个元素是纯文本字符串。CategoryCode对象里，@type写死是CategoryCode，inCodeSet指向Google商品分类法的地址，codeValue填5710。纯文本那一项直接写你自己的分类路径，用大于号分层。

促销时长那部分挂在offers里面：priceValidUntil写这个价格的失效时间，validFrom和validThrough框定促销的起止，三个时间都带时区偏移。

几个实现细节，都是踩出来的：

• inCodeSet填的是分类法本身的标识，不是你那个类目的地址。这一点最容易搞混——它回答的是“这个代码属于哪套体系”，而不是“这个代码指向哪一页”。
• codeValue是字符串还是数字都能识别，但整站保持一致更省心，别一半引号一半不引号。
• 数组里的顺序不影响解析，但把CategoryCode放前面更符合阅读习惯，也方便排查的时候一眼看到。
• 时间一律带时区偏移，别图省事写成纯日期。Ahrefs那份结构化数据指南里对格式选型讲得比较全，JSON-LD之外还有微数据和RDFa两条路，但对商品这个场景来说JSON-LD基本是唯一值得考虑的。

分类填错了，会以什么方式暴露出来？

这一节可能是最实用的：如果你压根不知道自己填错了，前面讲的所有规则都用不上。分类出问题的症状往往不长在分类上，而是长在别的地方，很容易误诊。

症状一：商品在购物结果里和一批不相干的东西排在一起。这是最直接的信号。搜自己的商品，看同一屏里出现的其他商品是不是同一个品类。如果你的便携电源旁边全是充电宝，那多半是被归到了移动电源那一类。

症状二：商家中心突然冒出一批新的必填字段错误。这通常发生在你刚改完类目之后。前面说过，服饰、手机、软件这几类会追加必填字段，一指定类目校验规则就生效了。这其实是好事，说明类目生效了，但很多人会误以为是自己改坏了什么。

症状三：广告系列的商品分组数量对不上。如果你按类目分组投放，某个组的商品数突然变了，八成是自动归类改了主意。这条最容易被当成广告端的问题去查，其实根子在商品数据上。

症状四：AI购物答案里死活出不来。这条最难查也最没法直接验证，因为你看不到候选池。可以侧面试探：把你的商品品类当成关键词去问助手，看它给出的推荐里有没有你的同类竞品。如果同行都在、只有你不在，而你的商品信息本身没问题，那分类值得查一遍。

诊断顺序建议从便宜到贵：先看商家中心诊断报告（免费、即时），再看购物结果实际归属（免费、要点耐心），最后才是去猜AI那一层（几乎无法证伪，别在这上面花太多时间）。

映射表怎么建，才不会变成烂尾工程？

前面提到WooCommerce和Magento都需要自己维护一张分类映射表。这件事的失败率相当高，值得单独说说。

失败的典型路径是这样的：立项时决心很大，打算把全部两百个类目一次映射完；做到第三十个的时候发现有些类目在Google分类法里找不到对应；开始纠结该往上归还是往下归；纠结了两周，这事就搁置了。半年后有人问起，答案是“当时做了一半”。

三条能显著提高成活率的做法：

第一，按商品数量排序，不按类目编号排序。把你的类目按下挂商品数从多到少排，先做头部。通常前20% 的类目覆盖80% 的商品，做完这一截收益就已经拿到大半了。

第二，找不到精确对应就往上归一级，别硬凑。Google的分类法有几千个类目，但未必有你那个细分品类。归到上一级是完全可接受的，比归到一个语义相近但实际不对的类目安全得多。归得粗只是损失一点精度，归错了是给出错误信息。

第三，把映射关系存在能被上新流程读到的地方。存在某个人的表格里，等于没存。要么进数据库当成分类的一个字段，要么进后台的分类管理界面。判断标准很简单：新来的运营在不问任何人的情况下，能不能自己填对。

还有一条经验：映射表要留一列写“为什么这么归”。半年后有人质疑某个归类，没有这一列的话，没人记得当初的理由，只能重新纠结一遍。

三个建站平台各自怎么落地？

说完原理，说落地。独立站常见的三个平台，处理方式差得挺远。

Shopify

Shopify自带的商品结构化数据由主题模板生成，改动点在product模板里的JSON-LD块。Shopify后台的商品编辑页有一个标准化商品类型字段，用的就是Google的分类法，可以直接把这个值读出来写进codeValue。你自己的商品类型字段则适合写成纯文本那一路。

要注意的坑是：如果你装了SEO插件，很可能站上已经有两套JSON-LD在跑了。加字段之前先确认自己在改的是被Google采纳的那一套，别辛苦半天改了个没人读的。

WooCommerce

WooCommerce的商品结构化数据默认由核心生成，可以用过滤器挂进去。它的商品分类是自己的一套taxonomy，和Google分类法没有对应关系，需要你自己维护一张映射表。

映射表这件事没有捷径，但可以偷懒：先按你的一级分类做粗映射，覆盖八成商品，剩下的边缘类目慢慢补。追求一次做全，通常的结果是一次也做不完。

Magento

Magento的属性体系本身就足够灵活，加一个自定义属性存Google类目ID，然后在模板里输出，是最直接的做法。它的麻烦在于多店铺视图，每个视图的分类可能不同，映射表要按视图维护。

三个平台的共同点是：这件事的工作量不在写代码，在维护映射关系。代码是一次性的，映射表是长期的。上新品的时候有没有人记得填这个字段，才是决定它长期有没有用的关键。

变体商品的分类，该写在哪一层？

这是落地时最先会撞上的一个问题：一款T恤有五个颜色三个尺码，十五个变体，category该写在父商品上还是每个变体上？

结论是写在能代表这件商品的那一层，通常就是父商品。理由很直接：颜色和尺码不改变商品的品类。红色M码的T恤和蓝色L码的T恤，在Google分类法里是同一个类目，重复写十五遍除了增加出错概率之外没有任何收益。

但有两种例外值得留意。

第一种，变体跨了品类。有些站会把配件当成主商品的变体来管，比如一台相机的变体里混进了镜头盖和电池。这种情况下变体确实分属不同类目，但更根本的问题是商品结构本身就不该这么建——这属于用变体机制凑数据，早晚会在别处出问题。

第二种，套装和单品混在一起。一个“买一送一”的套装，和单品在分类法里可能落在不同类目。这时候套装应该是独立的商品，不是变体。

换句话说，如果你发现变体之间需要写不同的category，那多半说明它们本来就不该是变体。这个信号很好用，能顺带帮你发现商品结构上的历史遗留问题。

还有一条容易忽略的：变体页如果各自都有独立URL和独立标记，那么规范页策略要和分类策略对齐。被canonical指向父商品的变体页，它的标记未必会被采纳，你写得再仔细也可能白写。这一层的判断逻辑，和站内讲重复内容治理时的思路是一样的。

改完之后怎么确认真的生效了？

给一条务实的验证路径，四步：

第一步，用富媒体结果测试工具跑一遍单个商品页。先确认语法没错、属性被识别了。这一步只验证格式，不验证内容。

第二步，回商家中心看诊断报告。重点看有没有因为你新指定的类目而冒出来的新校验错误，尤其是服饰、手机、软件这几个会追加必填字段的类目。

第三步，看数据源和网页的一致性。随机抽十件商品，把数据源里的类目和网页标记里的codeValue对一遍。不一致的话，两边都得查，不能只改一边。

第四步，隔两周看购物结果里的类目归属。这一步最慢也最真实。Google重新评估需要时间，改完第二天去看是看不出什么的。

关于第四步的等待，可以参考站内那篇canonical标签是提示不是命令里讲的道理：你给的是信号，采不采纳、多久采纳，决定权不在你手里。结构化数据也是一样，写对了只是把话说清楚，不等于对方立刻照办。

顺手该一起查的，还有哪几个高频出错点？

既然要动商品页的结构化数据模板，不如把周边几个高频出错的地方一起过一遍。改一次模板的成本，和改三次是一样的。

价格和货币符号对不上。price字段里带了货币符号、或者用了千分位逗号，是最常见的低级错误。这个字段只该有纯数字，货币单独用priceCurrency表示。多币种站点尤其容易出问题：页面上按用户地区显示了不同货币，标记里却还写着建站时那一种。

库存状态写死不更新。availability填了InStock之后再没人管，商品早就下架了，标记里还说有货。这会直接影响信任，严重的会被判定为数据不实。它的正确做法是从库存系统实时读，而不是在模板里写死。

评分数据和页面显示的对不上。aggregateRating里的评分值、评价数量，必须和页面上用户真能看到的一致。标记里写着4.8分200条评价、页面上一条评价都找不到，这属于典型的踩线行为。

变体商品各写各的。同一款商品的不同尺码颜色，如果每个变体页都独立标记成一个Product，很容易被判成重复。这一块和站内讲过的电商重复内容治理是同一个问题的两面，处理思路要和你的规范页策略保持一致。

标记里的信息页面上没有。这条是所有结构化数据的通则：标记描述的必须是用户在页面上真能看到的内容。保哥见过一个站把商品的全部参数都塞进了标记，页面上却只显示三条，剩下的藏在一个从来没人展开的折叠块里——这种做法在审核趋严之后风险不小。

把这五条和新增的category一起排进同一次模板改动，投入产出比会好得多。

哪些人现在就该动手，哪些人可以先放放？

不是所有站都需要马上做这件事，给个优先级判断：

• 已经在跑商品数据源、有免费商品收录或购物广告的——优先做。你本来就在维护分类字段，把它同步到网页标记上是顺手的事，收益最直接。
• 商品数量多、类目跨度大的——优先做。类目跨度越大，自动归类出错的概率越高。
• 做服饰、手机、软件、酒类的——优先做。这几类要么有追加必填字段，要么有误判风险。
• 单品类小站、商品数量在几十件以内的——可以放一放。自动归类在这种情况下基本不会错，人工维护映射表的成本反而不划算。
• 还没接商家中心的——先去接商家中心。免费商品收录那一步的收益远大于这个属性，顺序别搞反了。

说到底，这次更新的意义是补齐了一块拼图，不是开辟了一条新路。商品数据源该归谁管这个老问题，因为它又多了一个必须回答的理由——现在连网页模板都要读这份数据了，再把它当成投手一个人的事，缝只会越来越大。

常见问题解答

category属性是必填的吗？不写会怎样？

不是必填，Google把它列为推荐属性。不写的直接后果是网页标记里缺少分类信息，Google会依靠自动归类或者你提交的数据源来判断类目。对小型单品类站影响很小；对商品多、类目跨度大的站，自动归类出错的概率会明显上升，而且出错之后很难定位原因。

纯文本和CategoryCode只能选一个吗？

不是，两个都可以写。文档明确说明category接受数组，纯文本字符串和CategoryCode对象可以混合放在同一个数组里。推荐的做法就是两个都给：CategoryCode表达Google官方分类法里的类目，纯文本表达你自己的商品组织逻辑，各自服务不同的消费方。

codeValue里能不能既填ID又填完整路径？

不能。商家中心的规范写得很明确，ID和完整路径二选一，不能同时提交，而且每件商品只能有一个类目、该字段不可重复。建议优先用数字ID：更短更不容易拼错、路径名称调整时更稳定、做多语言站时不受语言版本影响。

我该手工指定类目，还是让Google自动归类？

大多数情况下自动归类就够了。规范列出的三种该手工指定的情形是：需要解锁类目专属的必填字段、需要按类目做广告定向、以及自动归类出现了误判（规范点名了酒精饮品）。除此之外硬要手工指定，准确度未必比自动归类高，还可能触发一批原本不存在的校验错误。

priceValidUntil填了之后过期了会怎样？

可能导致商品不再展示富媒体结果。这个字段属于填了就得维护的类型，填完不管比不填更糟糕。做促销的时候配合validFrom和validThrough使用，时间格式建议用带时区的ISO 8601——出海团队尤其要注意时区，服务器时间和目标市场时间差半天，促销价的露出时机就会整个错位。

这个属性以后会不会变成必填？现在做是不是太早？

没人能替Google保证，但从历史规律看，被列为推荐的属性变成事实上必需的情况并不少见——不一定是文档改成必填，而是不填的商品在竞争中逐渐处于劣势。考虑到这个属性的落地成本极低（一次模板改动加一张映射表），而它影响的是分类识别这道最上游的判断，现在做的性价比是合理的。真要说该等，也只有商品数量在几十件以内、单一品类的小站可以先放放。

变体商品的category写在父商品上还是每个变体上？

通常写在父商品上就够了，因为颜色、尺码这类变体维度不改变商品品类。如果你发现不同变体需要写不同的category，那往往说明它们本来就不该被建成变体——比如把配件混进了主商品的变体里，或者套装和单品混在了一起。另外要注意规范页策略：被canonical指向父商品的变体页，它自己的标记未必会被采纳。

改完结构化数据，多久能看到效果？

格式层面的验证可以立刻做，用富媒体结果测试工具就能确认属性有没有被识别。但类目归属在购物结果里的实际变化需要等Google重新抓取和评估，通常要以周为单位观察，改完第二天去看是看不出什么的。结构化数据给出的是信号而不是指令，写对了只是把话说清楚，采不采纳、多久采纳，决定权不在你这边。

权威参考资料