结构化数据里价格64个站全写了，规格只有7个

摘要：80个电商独立站的产品页，63个页面上找得到规格字段名，一共187处。把这些字段名放回机器实际拿到的那条文本流里逐条人工核对，字段名后面紧跟的内容只有51.9%真是它的值；15.0%是另一个字段名或分组标题，33.2%是评价区、促销条、标签页名这类不相干的东西。站一级的中位配对成功率正好50.0%，20个站一条都没对上。而能让机器不必靠猜的三条通道，使用率分别是8.8%、7.5%、8.8%。

产品页上那张规格表，你大概很久没认真看过了。它长得规规矩矩：左边一列字段名，右边一列值，行距均匀，字号统一，扫一眼就知道净重多少、尺寸多大、什么材质。

现在把浏览器的样式关掉。设置里有“禁用样式”，或者干脆开阅读模式。那张表会塌成一根竖着的字符串：

Specifications
Input
9.0V⎓3A / 12V⎓3A / 15V⎓3A
Output
Phone: 25W Max
Dimensions
3.74 × 2.38 × 1.22 in
Weight
8.11 oz

这是anker一个充电站产品页塌下来的样子。读起来还行，字段名和值一上一下交替出现，谁都能还原出那张表。

问题在于，这个“还行”背后没有任何东西在保证它。它成立，仅仅因为写模板的人恰好把字段名的div写在了值的div前面。哪天设计改成两列、字段名全进左边那个容器、值全进右边那个，塌下来就成了“Input Output Dimensions Weight 9.0V 25W 3.74in 8.11oz”。人看着还是那张表，机器拿到的已经是两堆互不认识的词。

所以这一轮想量的不是“机器读不读得到”，而是机器读对的时候，究竟是有人保证它对，还是顺序碰巧对。

把CSS关掉之后，你的规格表还剩什么？

先说清楚这件事为什么值得单独量一次。

前面几轮量过内容整段掉出通道的情形。图上的字62%在文本层里一个都找不到是一种，屏幕上最大那行字44.6%不是标题标签是另一种。这两种的共同点是信息真的没了：机器那边整段消失，而且不报错。

规格不一样。规格的字全都在文本里，一个字符都没少。少掉的是字段和值之间的那根线。人靠对齐看出这根线——这一行左边是名、右边是值，因为它们横着排在一起。机器没有“横着排在一起”这个概念，它只有一串按DOM顺序展开的字符。

这根线在HTML里本来有专门的表达方式。表格里，th和同一行的td是一对；定义列表里，dt和紧跟的dd是一对；结构化数据里，additionalProperty下面每个PropertyValue自带name和value两个字段。这三种写法都不依赖顺序碰巧对，它们把配对关系直接写进了标签。

可要是用两个div拼出同样的视觉效果，这根线就只存在于CSS里。CSS不进索引。

51.9%——这是63个站给出的配对成功率

口径先摆出来，每一层的站数都不一样，混着说会得出很难看的错误结论。

• 起手131个英文电商与消费品牌站；
• 首页采集成功130个（getquip.com导航超时）；
• 从首页找到并打开产品页的80个，这是本文所有产品页统计的分母；
• 产品页上匹配到规格字段名的63个站，字段名共出现187处。

“字段名”的判定用了一份写死的词表：material、weight、dimensions、capacity、warranty、country of origin、tech specs这一类，六十多个词，并且要求这个元素显示出来的全部文字就是这个词本身——不然正文里那句“materials and features…”也会被当成字段名。

然后取document.body.innerText。这大致就是把样式关掉之后剩下的东西，也接近爬虫和大模型切段时拿到的形态。按行切开，找到每个字段名所在的行，看它下一行是什么。

187条全部人工过了一遍，分成三类：

同一个站同一个字段去重之后（评价区经常把“Fit”重复五六遍），156条的分布是51.9%、14.1%、34.0%。去重前后第一档一模一样，说明51.9%不是被重复项撑出来的。

换成站的口径：63个站的配对成功率中位数正好50.0%；20个站一条都没对上，占31.7%；13个站全对，占20.6%。

也就是说，你的产品页上的规格，机器大概能拿对一半。至于是哪一半，它自己也不知道。

配错的那一半，都错在哪里？

两类错法性质完全不同，得分开讲。

第一类：值和名分了家

28条属于这类，特征是字段名的下一行还是个字段名。

• anker的“Specifications”，下一行是“Input”；
• decathlon的“Specifications”，下一行是“Materials”；
• menuspace的“Dimensions”，下一行是“Specifications”；
• nomadgoods的“Tech Specs”，下一行是“Materials”；
• beistravel更彻底，“Fabric”“color”“fits”“style”四个词连着落下来，中间一个值都没夹。

规律其实很清楚：分组标题和字段名，在文本流里长得一模一样。“Specifications”是这一整块的名字，“Input”是这一块里的一条，可它们都是独立成行的短词，字面上没有任何区别。人靠字号和缩进一眼分清层级，机器要么两个都当字段名、于是把“Input”当成“Specifications”的值，要么两个都当标题、于是这一块一条也抽不出来。

untuckit那条最有喜剧效果：“Fit”的下一行还是“Fit”。一个是筛选器的分组名，一个是规格里的字段名，同一个单词连着出现两次，中间什么都没有。机器读到这儿，多半会以为自己卡带了。

everlane的“Materials & Care”下一行是“Materials:”，同一个毛病——外层是合并的分组名，内层才是真字段，两层用了同一个词根。

第二类：下一行压根是别的模块

62条，占三分之一，这类才是真会让人一惊的。

• burrow的“Dimensions”下一行是“Up To 35% OFF”，一条促销带插在了规格和它的值中间；
• govee的“Specifications”下一行是“Reviews”，soundcore、nomadgoods、jackery的“Tech Specs”下一行都是“FAQ”——这是标签页的名字，规格藏在没被激活的那个面板里；
• rapha的“Materials & Care”下一行是“YOU MAY ALSO LIKE”，推荐位直接顶上来了；
• tentree的“Size & Fit”下一行是“$25”；
• vuoriclothing的“Height”下一行是“Showing 60 results”；
• menuspace的“Care Instructions”下一行是“Privacy Policy”，页脚都挤进来了；
• hellotushy的“Specifications”下一行是“Download PDF”。规格是有的，在一个PDF里。

这类的成因大多是字段名本身就是标签页或折叠块的把手，内容在另一个还没展开的容器里。采集时已经把所有原生details展开过一次，但用div加JavaScript自己实现的手风琴展不开——这恰恰就是机器面对的真实情况。隐藏内容到底算不算数那一轮拆过十六种藏法各自的裁决，这里是它落在规格上的具体后果：不是内容被降权，是字段和值被彻底切断。

说个题外的观察。规格书在屏幕上好好的、机器复制走的却是另一串字符那件事，跟hellotushy这个“Download PDF”是同一个逻辑的两端：一个是把规格搬进了PDF的图层，一个是把规格搬进了PDF这个文件。人点开就能看，机器要多走一道，而多走的那道往往没人走。

为什么“机器读对了”和“机器有把握”是两回事？

这是本文真正想说的一句话，值得单独展开。

51.9%第一眼看着不算灾难：一半能对上，剩下一半改改就是了。但换个角度问——那对上的51.9%，靠的是什么机制？

答案是DOM书写顺序。字段名的元素恰好写在值的元素前面，中间恰好没插别的东西，塌下来就是对的。这里没有任何一层在做校验，没有任何一层在声明“这两个是一对”。它对，是因为写模板的那个人当时顺手就那么写了。

顺手写对的东西，会被顺手改错。改版把规格区从一列改成两列，把促销带挪到规格上面，给规格加一层标签页容器——任何一次都能让某一批字段从对的那半掉进错的那半，而页面上看不出一点变化。对齐是CSS在管，CSS没坏。

这就是它和“信息整段消失”的关键区别。信息消失至少还有明确的失败信号：打开阅读模式，那句话不在，一眼就看见了。配对关系断掉这件事没有信号，塌下来的文本流照样通顺，你甚至会觉得它读着挺好。

做SEO的人对这种事其实不陌生。一个尾逗号就能让整页结构化数据失效是同一类：肉眼看页面完全正常，机器那侧已经全丢。区别只是JSON-LD好歹有校验器会红着脸告诉你，而“字段和值靠顺序凑在一起”这件事，没有任何工具会报警。

能给出把握的三条通道，现在各有多少人在用？

HTML和schema.org一共提供了三种把配对关系写死的办法。80个产品页上的实际使用情况：

再从字段那一侧看：171个独立成块的字段名里，真正靠th与td、或dt与dd建立起配对关系的只有13个，7.6%。剩下92.4%全靠相邻。

字段名用的标签排下来是这样：span 39次、div 35次、button 18次、p 16次、h2 13次、h3 11次、dt 7次、h5 7次、h4 6次、strong 5次、b 4次、th 3次。前两名加起来43%，都是完全没有语义的容器。

这个分布跟全网大盘一致。Web Almanac 2024的标记章节统计出div占了全部HTML元素的29%，那一节里的原话是“divitis依然存在，而且看不出未来几年会改变”。产品页的规格区，只是这个大趋势里最不该出现div的一块地方。

还有一个可以当旁证的数字：页面上有93个容器在视觉上排成了两列以上、两行以上的网格，也就是“看起来就是张表”，其中落在table或dl里的只有3个。35个站的产品页上网格有好几处，表格和定义列表一个都没有。八类语义标签对SEO的真实影响那篇里排过这些标签的实际分量，表格和定义列表恰好属于少数几个“语义确实带来功能差异”的标签，不是可有可无的洁癖。

用了表格的那7个站，表格本身合格吗？

不完全合格。7个站一共9个可见表格，逐个拆开：

9个表格里4个一个th都没有，全是td。这种表格在渲染上和有表头的完全一样（表头那行加粗是CSS加的），但对机器来说它退化成了一个纯网格：知道有几行几列，不知道哪一列是名、哪一列是值。

MDN关于th元素的说明把这件事讲得很直白：scope的作用是明确这个表头管的是它那一行还是那一列，两列以上的表格没有scope就得靠算法猜。9个表格里带scope的只有两个站，taylorstitch和drinkolipop。

drinkolipop还是唯一写了caption的，而且写了两次。一个卖气泡水的站，把营养成分表写得比多数工具站还规范，多少有点意外。

有dd没有dt的定义列表，是怎么长出来的？

定义列表这条通道的情况更奇怪。6个站一共30个可见的dl，其中13个的dt与dd数量对不上。

具体看两个：aboutyou有4个dl，每个都是0个dt加1个dd；dollarshaveclub有8个，同样每个0个dt加1个dd。

一个定义列表，里面只有定义，没有被定义的那个词。

HTML规范的分组内容那一章把dl定义成“名称—值组的列表”，MDN的dl元素文档也强调每一组必须由一个或多个dt加一个或多个dd构成。只有dd的dl在规范上不成立，机器读到它只能理解成“这里有一个值，它是什么的值不知道”。

这大概率不是谁故意写成这样，而是组件库的产物：某个UI库把dl当成通用的“信息条”容器，名字那部分用span或者干脆用::before渲染，值那部分用dd。视觉上一模一样，语义上把最关键的那一半删掉了。

做对的是ritual（3个dl，每个4对dt/dd整整齐齐）和baseus（6个dl，全是1对1）。

价格都写进去了，规格为什么没有？

结构化数据这一侧的数字，是这一轮最值得盯着看的一组。

80个产品页里，64个带Product结构化数据，占80.0%。渗透率比很多人以为的高。作为对照，Web Almanac 2024的结构化数据章节给出的全网数字是Product schema只出现在0.77%的页面上。两个数并不矛盾，分母完全不同——全网绝大多数页面根本不是产品页。但它至少说明，在真正的产品页上这件事已经是标配了。

然后是关键的一步。这64个页面里：

• 写了offers（价格、货币、库存状态）的：64个，一个不落；
• 写了additionalProperty（规格参数）的：7个。

同一段JSON-LD，同一个开发，同一次部署，价格写全了100%，规格写了10.9%。

原因不难猜，而且不能全怪做的人。价格是富媒体结果的硬门槛，不写就拿不到那个带价格和星级的搜索结果，收益立刻能看见；additionalProperty不参与任何一种富媒体展示，写了在搜索结果里看不出半点变化。整个行业是被富媒体结果牵着走的，牵到哪儿写到哪儿，没牵到的地方就是空的。

问题是这套激励在AI那一侧不成立了。AI答案要回答“这个杯子多重”“这件衣服什么面料”“这个充电器支持多少瓦”，靠的不是价格，正是那些从来没人写的字段。结构化数据对AI搜索到底有没有用那篇拆过官方说法和实测的差距，这里可以补一句更具体的：你已经写了的那部分结构化数据，喂的是十年前的富媒体结果；AI要的那部分，绝大多数人还一个字没写。面向AI推荐优化产品页的那套动作里，规格结构化排在第一位，实测下来它也确实是缺口最大的一项。

写了additionalProperty的那7个是buckmason、burrow、fahertybrand、flyingtiger、fromourplace、gymshark、lookfantastic。凑巧的是burrow同时也是有表格的那7个之一，而它的表格一个th都没有。这倒说明一件事：两条通道彼此独立，做了一条不等于另一条也做了，别指望互相兜底。

我这把尺子差点也骗了我自己

这一段是方法论，但它比上面任何一个结论都更该被记住。

最开始判断“下一行是不是值”，用的是一条自动规则：下一行非空，并且不在字段词表里，就算它是值。跑出来的数字是93.6%。看到这个数的第一反应是这选题废了——九成多都对，哪来的问题。

然后按惯例抽了24条人工核对。核到第五条就发现不对劲：avocadogreenmattress的“Warranty”下一行是“FINANCING”，被判成了值；burrow的“Dimensions”下一行是“Up To 35% OFF”，也被判成了值。这条自动规则唯一排除的是“下一行是词表里的另一个字段名”，可绝大多数干扰项根本不在词表里——它们是标签页名、促销语、按钮文字、评论片段。

全部187条人工标完之后：

自动规则把79条不是值的东西算成了值，同时漏判了1条真正的值，净差78条，整体虚高1.80倍。误判拆开看，17条是把分组标题或另一个字段名当成了值，62条是把完全不相干的模块当成了值。后者才是大头，也正是那条自动规则完全没设防的方向。

所以结论要写清楚：这一轮51.9%这个数，是人一条条看出来的，不是脚本算出来的。脚本那个93.6%如果直接发出去，就是一篇结论完全相反的文章，而且没有任何读者能从数字上看出它错了。

这个坑的形状值得单独记一笔：当你的自动判据是“排除已知的坏情况”而不是“确认它符合好情况”，你量到的永远是上界。排除法只挡得住你想得到的那些，想不到的全部按“好”计入。改成确认法——要求下一行必须包含数字加单位、或者匹配值的形态——数字会偏低，但至少偏在安全的一侧。这跟做SEO时用工具跑审计是一个道理，调试JSON-LD那类工具亮绿灯只代表它检查的那几项没问题，不代表它没检查的那些也没问题。

做对的那几个站，做法有什么共同点？

13个全对的站里，挑三个看得最清楚的。

snowpeak：sku对上SDE-001-IV-US，weight对上19.6 LB（8.9kg），capacity对上4 Person，materials对上75D Polyester、PU Coating 1,800mm、Teflon Water Repellent。四条全中。它的规格区是一个独立区块，字段名和值一上一下紧挨着，中间没有任何按钮、促销条或标签页容器。

on.com：materials对上“Main Fabric: Polyamide (recycled) 100%. Lower Part: Polyamide…”，country of origin对上Vietnam，care instructions对上Do not bleach，size & fit对上True to size。它的做法更省事——把字段名和值写进同一行，“Main Fabric:”这个前缀直接跟在值前面。这样即使塌成文本流，冒号本身就是那根线。

wusthof：9条里7条对上，country of origin对上Germany，length对上3.7 in，sku对上1040336812。它同时是唯一一个既有表格、又有4个规范dl的站。

三个站的做法各不相同，共同点只有一条：字段名和它的值之间，没有第三样东西。要么紧挨着，要么写在同一行，要么用标签绑在一起。而错的那些，中间总是插着点什么——一个促销带、一个标签页把手、一个推荐位、一个折叠容器。

这就给出了一条不需要任何工具的自查方法：把产品页复制到记事本里，找到那几个字段名，看它下面那行是不是它的值。不用装插件，不用跑脚本，一分钟能查完一个页面。内容可提取性那套结构原则讲的是同一件事的通用版本，规格区只是它最容易验证、也最容易翻车的那一块。产品详情页SEO那套做法里反复强调的“摆脱供应商文案”是内容层的事，这一条是结构层的事，两件事不冲突，但只做前者不会让后者自动变好。

想让规格从“碰巧对”变成“保证对”，先动哪三处？

按投入产出排，从小到大。

第一处：把冒号加回去

成本最低的一步，改模板里一个字符串。字段名后面带上冒号、和值写在同一个文本节点里，塌下来就是“Material: 100% Organic Cotton”，无论DOM怎么变、中间插什么，这一对都拆不散。on.com和kotn走的就是这条路。

这一招不解决语义问题——机器仍然要靠冒号猜配对——但它把“靠顺序”换成了“靠字符”，抗改版能力强了一个量级。当天就能上线。

第二处：把规格区换成表格或定义列表

如果规格是标准的两列，就用table，第一列写th并加scope="row"；如果是“一个名对一段描述”的形态，就用dl，一个dt配一个dd。这两种写法在CSS里都能排成任何你想要的样子，用display: grid覆盖表格的默认渲染是常规操作，视觉上和现在的div方案没有区别。

顺带一提，这一步同时是无障碍的必修项。屏幕阅读器在表格里能按行按列朗读“材质：有机棉”，在两个div里只能读出两句互不相干的话。

第三处：把规格补进additionalProperty

这是唯一一条完全不依赖页面结构的通道。JSON-LD里加一段：

"additionalProperty": [
  {"@type": "PropertyValue", "name": "Material", "value": "100% Organic Cotton"},
  {"@type": "PropertyValue", "name": "Weight", "value": "8.11 oz"}
]

它不会带来任何富媒体结果，搜索结果里看不出一点变化，这也是它被跳过这么多年的原因。但它是三条通道里唯一一条把“名”和“值”明确写成两个独立字段的，不需要任何推断。如果你的商品数据本来就在数据库里按字段存着，这一段是模板循环里加三行的事，成本可能比改前端结构还低。结构化数据落地那套流程里的字段优先级可以直接拿来排期，GTIN那类商品标识字段和additionalProperty往往在同一次改动里一起补，别分两回做。

顺序上，保哥的建议是先做第三处再做第二处。第三处不动前端、不影响视觉、不需要设计参与，改完就有；第二处要动组件，要过设计和测试，排期常常两周起。Schema生成器那类工具可以先拿一个页面手动生成一版对照着改，别一上来就动模板。做Shopify的话，给Shopify页面加结构化数据要注意主题自带的那一份和你新加的那份会同时出现，先确认合并策略再动手。

顺手能做的第四件事

把规格区从标签页里搬出来。这一轮62条“下一行是别的模块”里，很大一部分病根就是规格被放进了默认不激活的标签页。JS渲染那一轮实测的结论是渲染本身没大家担心的那么可怕，但那说的是内容能不能被渲染出来。能渲染出来和默认展开是两件事：标签页里的东西即使渲染了，在文本流里也照样和它的字段名隔着一整个面板的距离。

做完这四件，再回头把电商内容SEO那套六层矩阵里产品页那一层重新过一遍，你会发现原先写在文案里的很多卖点，其实本来就该以字段的形式存在。几种被AI引用得更多的结构化内容格式里，参数表一直排在前列，原因不是它信息量大，而是它歧义最小。

常见问题解答

规格没写进结构化数据，会影响Google的自然排名吗？

直接影响排名的证据没有，Google官方也从来没把additionalProperty列为排名因素。它影响的是另外两件事：一是AI答案在回答具体参数问题时能不能确定地取到你的值，二是购物类结果里商品属性的完整度。把它当排名手段做会失望，把它当“让机器不必猜”的手段做才对得上。

用div加CSS grid排出来的规格表，Google真的看不懂吗？

“看不懂”说得太绝对。Google会渲染页面，能拿到布局信息，也有能力从相邻关系里推断配对。问题不在能不能，在有没有保证。推断出来的结果没有确定性，改版之后可能悄悄变化，而且不同的抓取方——Googlebot、各家AI爬虫、比价工具、你自己的数据管道——推断能力差得很远。用table或additionalProperty，等于把这件事从“可能推对”变成“不需要推”。

这一轮为什么只看首屏能找到的产品页，不做全站抽样？

因为要控制一个变量：这些页面都是从首页两跳之内能到的，属于每个站最主要的商品模板。全站抽样会混进大量旧模板、活动页和第三方托管页，样本更大，但对不上“这个站现在的产品页长什么样”这个问题。代价是每个站只有一个页面，站内的模板差异看不到。

字段词表是英文的，中文站的规格是不是查不出来？

是。这一轮样本全是英文站，词表也只写了英文字段名，中文站的“材质”“净含量”“适用机型”一个都不在里面。方法本身通用——把词表换成中文，其余流程一字不改就能跑。但本文的所有比例只代表这批英文电商站，不要直接搬去描述中文站。

51.9%这个数，换个人标注会不会差很多？

会有出入，但不至于翻盘。争议集中在两类边界情况：一是评价区那些“True to size”，它确实回答了Fit这个字段，但来源是用户评分不是官方规格，本文按值计入了；二是像jackery的“Capacity”下面跟着“7200W”这种，字段和值不完全对应但确实是参数。把这两类全部改判成不算，51.9%会掉到四十几个百分点，结论方向不变。真正稳的是另外两个数：7.6%的语义配对率和8.8%的additionalProperty使用率，这两个是标签层面的事实，不涉及判断。

那20个一条都没对上的站，是不是页面做得特别差？

恰恰相反，里面有不少是这批样本里做得最精致的。它们的共同特征是重视觉、重交互：规格塞进标签页，参数做成可展开的手风琴，字段名当成筛选器的分组名复用。交互做得越精细，文本流塌下来越碎。这也是这个问题最难被发现的原因——它跟“页面做得糙”没关系，反而跟“做得讲究”正相关。

权威参考资料