Schema里三个字段的中文名对不上，AI抓了三次都没认出来，我改了命名才通

上周给一个做工业配件的客户做结构化数据体检，遇到一个挺典型的问题，记录一下。

现场情况

他们官网产品页有 Product 和 Offer 两段 JSON-LD，看着挺全，schema.org 校验也能过。但抓日志里，AI 爬虫一周来了 11 次，页面级索引没问题，字段级抽取就是缺 material 和 sku 这两项。

我先把口径锁死：只查 JSON-LD 里 Product 节点的字段完整性，不看正文，不碰别的变量。

拆变量发现的问题

逐个对字段名，发现三处命名对不齐：

1. 页面正文写的是「材质：304不锈钢」，JSON-LD 里写 material: "304"，中文名没进结构化数据，模型拿到的就是个裸字符串，上下文全靠猜。
2. sku 字段前端展示的是「型号-A203」，但 JSON-LD 里填的是内部 ERP 编号「E-77812」，两边对不上。
3. brand 用了中文简称，@type 又没写 Brand，直接是字符串。

这三处单独看都不致命，但叠加起来，页面正文和结构化数据的口径是分裂的。AI 抽取时等于看到两套事实，它选保守路径，直接不填。

改法

• material 改成对象，@type: "Text"，值写成「304不锈钢（GB/T 3280）」，跟正文一字不差。
• sku 统一成展示型号，ERP 编号挪到 identifier 里，用 PropertyValue 包一层。
• brand 补 @type: "Brand"，name 用全称。

改完第二周，字段级抽取 material 从 0 到 9 次命中，sku 从 2 次到 8 次。抓取频次没变，还是那天两次左右，说明不是爬虫来得勤了，是它终于能认了。

一个判断

结构化数据这块，@type 写对只是及格线，字段值的口径跟正文对齐才是拿分项。很多团队卡在「校验通过但抽不出来」，八成就是命名和值域两套皮。

另外提醒一句：别指望改 schema 能提抓取频次，我前后测过几轮，抓取节奏跟站点整体权重和更新频率挂钩，单页 schema 改动影响不到那块。

想问下

你们做 Product 结构化数据时，sku 这种内外两套编号的字段是怎么处理的？是统一成对外展示值，还是用 identifier 分开放？我想看看有没有更稳的写法。