尺码表实测55个站：有入口的页面里，近一半源码没有表

摘要：拿真实浏览器打开55个英文独立站的258个商品页，把页面上所有“看起来是表”的东西按载体清点了一遍。写着尺码指南的入口一半页面都有，可点进去之后，DOM里既没有表格、也没有网格、也没有图的，占了48.8%。商品页里连一个table标签都没有的，是76.7%。这不是没做尺码表，是那张表根本没有以“表”的形式交出去。

做跨境独立站的人，多半都相信自己站上是有尺码表的。运营截过图，设计师画过稿，客服天天往聊天窗口里粘那张图。可如果换一个身份去看同一页——不是用眼睛，而是用一段只会读HTML的程序——你会发现事情不太一样。

我起这个念头，是因为一件很小的事。一个做户外服饰的朋友问我，为什么AI助手回答“这件冲锋衣XL的胸围是多少”的时候，答的是别家的数据。他的商品页上明明白白有一张尺码表，人人都看得见。我把那页扒下来看了一眼，尺码表在，但它是一张PNG。

于是就有了这次清点。问题很朴素：屏幕上那张尺码表，浏览器交出去的到底是什么东西？

这台实验是怎么搭的，判据又是什么？

样本沿用手上那份英文独立站清单，55个站，覆盖服装、鞋履、家居、寝具、3C、食品饮料几个大类。每个站挑5个商品页：变体最多的两件（通常就是有尺码的那类）、图片与标签最多的主推款一件、最长尾的一件，再随机一件。一共275个请求，其中258页返回200并且能正常解析。

剔掉的那些不算数：everlane、misen、glossier等几个站有页面撞上429限流，另有若干404，这些逐条记在原始数据里，没有拿去凑分母。ugreen整站取不回商品页，直接不进样本。这是老规矩了，拿不到页面不等于人家没写，两件事必须分开。

什么算“表”

判据得先说清楚，不然数出来的东西没法比。HTML标准里表格那一章规定得很死：一张表格是一个二维网格，每个格子的坐标由它所在的行和列共同决定，浏览器解析的时候会真的构建出这个网格。这句话是本文所有判据的地基——凡是把行列关系交给CSS去表达的，浏览器那边就不存在这个网格。

页面渲染完成之后，我在浏览器里同时数五类东西：

另外单独记一件事：页面上有没有“尺码指南”这类入口——按钮、链接、折叠标题，文字命中size guide、fit guide、measurement这几组词。有入口，说明这个站主观上认为自己提供了尺码信息。入口和内容对不对得上，是本文最核心的那一格。

三条不打算展开的边界

第一，不谈尺码数值本身对不对。厘米换英寸这道算术上没人负责，那是另一篇的事，尺码那一栏的数字不归译者管里已经把整条流水线拆过一遍。第二，不谈尺码标准与用户自我认知的错位，行业标准把多数成年人算成大码那篇讲的是另一层。第三，不谈折叠与标签页把信息藏起来对转化的影响，那排标签把商品页收拾得很干净已经算过那笔账。这一篇只问一件事：载体。

五分之四的商品页，一个table标签都没有

先看最粗的一层。258个商品页里，含至少一个table元素的只有60页，占23.3%；剩下的198页，一个都没有。按站算，55个站里只有20个站的商品页上出现过表格，另外35个站整站零表。

这个数字第一眼看着离谱，细想又很合理。商品页是模板生成的，模板里的字段是键值对，前端渲染成什么样全看设计稿。设计稿上没画表格线，工程师就不会去写table。而table这个标签在前端圈子里背了二十年的坏名声——早年拿它做页面布局留下的心理阴影，到现在还在起作用，尽管MDN的table元素说明里写得清清楚楚，它就是用来放二维数据的。

顺带说一句反直觉的：老式CSS表格布局其实已经基本绝迹了。计算样式是table或table-cell的非表格元素，258页里只在4页上出现过，占1.6%。大家不是在用旧办法画表，是压根不用“表”这个概念在想问题。

这些表本身有多大

110张表的规模分布挺能说明问题：行数中位数6行，列数中位数3列，四分之三的表不超过7行4列。最大的一张35行，最宽的一张25列——前者是reebok的中性鞋码指南，后者是aloyoga那张把男码、女码、袜码和英码摞在一起的鞋码对照，7行25列，横过来铺了一整屏。

另一头也值得看。110张里有18张的格子总数不超过2个，占16.4%，基本可以判定是模板留下的空壳。mackweldon那几个最典型：一个1行1列的table，唯一那个格子里写着一个句点，上面挂着标题“Transfer History”。这类东西在体检工具的报表里会被算成“页面含表格”，实际上一个字的信息都没有。做站内审计时如果只数标签个数不看内容，这一格就会把结论抬高一大截。

那20个有表的站，表都是些什么表

把110张表按它最近的那句说明文字归类，前几名很有意思：

• 出现最多的是配送时效表——“The delivery time for items is as follows”，10张；
• 其次是床品尺寸对照，7张；
• 再往下，5张是隐私政策里那张“我们收集哪些个人信息”的表格；
• 营养成分表8张，来自食品饮料类的站；
• 真正写着size chart、size guide、how to measure的，加起来不到三分之一。

allbirds是个典型。它的商品页上确实有一张table，7行2列，写得规规矩矩，还带thead——内容是加州消费者隐私法要求披露的个人信息类别。这个站唯一的一张标准表格，跟鞋没有半点关系，而且它是display: none的。至于鞋码，在另一个地方，下面会说到。

那110张表，用户真能看见的有几张？

把每张表沿着祖先链一路查上去，逐层看计算样式、hidden属性、aria-hidden、未展开的details与dialog，结果是：110张表里，渲染完成那一刻真正可见的只有24张，占21.8%。

另外一个角度：110张表里有67张的祖先容器带着modal、drawer、popup这类类名，占60.9%。也就是说，商品页上的表格，六成活在弹窗和抽屉里，等着用户去点那一下。

藏起来本身不是错。尺码表放在弹窗里是合理的产品决策，商品页首屏塞不下那么多行。真正要紧的是后半句——它在不在DOM里。在，机器至少还有机会；不在，那就是另一回事了。

逐站看，两头的差距比平均值大得多

把这110张表按站摊开，会看到两种截然相反的做法并排站着。

前三家不是不重视尺码，恰恰相反——它们是样本里尺码信息写得最细的几家，只不过整套都收进了弹窗，可见数是零。drinkolipop和wusthof正好反过来，表不算多，但全在明面上。可见与不可见的分界，跟这个站用不用心几乎没有关系，只跟它的前端组件怎么写有关系。

thirdlove是第三种：13张图命中表图判据，真表格零张，而且页面上还挂着一对名叫size-table-scroll-more-arrow.svg的左右箭头。也就是说，那张“表”是一张需要横向滚动去看的图片——连横向滚动这个交互，都是围着图片重新造了一遍。

写着尺码指南的那个入口，点进去到底有没有表？

这是整台实验最想问的一格。258页里有129页带尺码指南入口，正好50.0%，分布在37个站上。我把这129页按“入口背后到底是什么”分了六类：

近一半。decathlon的5个商品页每一页都挂着两三个“Size Guide”的按钮，DOM里零表、零网格、零图。rothys、tentree、untuckit、outdoorvoices、gymshark也是同一个形态：入口在，内容不在。

这一格的解释我原本写错了一次，后面那节的对照实验把它纠正了过来：这些页面上的尺码表，有一部分确实是点了才去取的，但更多的是别的原因。Google的JavaScript SEO基础里反复强调的“渲染之后才有的内容要付出额外成本”是其中一种，而交互触发的那一类比滚动触发的更难拿到。具体是哪一种，得替用户点一下才知道。

ice-watch把尺码表做成了PDF

4个页面的入口指向的是watches-sizes-guide.pdf。这个做法在手表、家具、B2B工业品里并不少见——设计部门出图，市场部门导成PDF，挂上去就算完事。问题是PDF的文字层是另一套东西，能不能被读出来取决于它是怎么生成的，PDF怎么做成无障碍又能长期归档里拆过标签结构与阅读顺序这一层，那页规格书在屏幕上是好好的泰语那篇里还有更糟的一种：屏幕上完全正确，复制出来是另一串字符。

不用table，那张表是拿什么画出来的？

剩下的三类载体，一类一类看。

网格伪表：行和列只存在于渲染结果里

先交代判据是怎么定的。MDN的display属性把网格和表格列成两种彼此独立的显示模式：设成网格的元素会按你写的列数把子元素排成矩阵，但这个矩阵只存在于布局阶段，DOM里那些子元素依然是平级的兄弟节点。我把“至少3列、至少6个子元素”当作伪表的门槛，宽了会把导航菜单也算进来，窄了会漏掉小尺码表。

258页里有126页至少有一个符合条件的网格容器，其中落在尺码语境里的有30页。allbirds那张鞋码对照就是这么做的：一个display: grid的容器，7列，14个子元素，第一行是男码8、8.5、9一路到11.5，第二行是对应的女码。在屏幕上它是一张两行七列的对照表；在DOM里它是14个并排的div，谁跟谁一组，只写在CSS的列数里。

aloyoga更彻底一点，27个格子3列，每个格子里写着“3M/4.5W”这样的组合值，男码女码被压进了同一个字符串。fahertybrand的腰围网格是36个格子6列，第一行连着三个28，第二行三个29——那三个28分别属于三个不同的裤长，可这层归属在DOM里没有任何痕迹。

reebok那组更值得说。它的尺码网格是visibility: hidden的，27个格子4列，而第一个格子里的文字是.sliderow__links.g——一段CSS选择器漏进了DOM，被当作内容渲染了出来。眼睛看不见，因为整块是隐藏的；机器读得到，而且会把它当成这张表的第一个数据。

这个门槛也确实会误伤。mackweldon那9个被判成尺码网格的容器，点开看其实是变体选择器——6个格子，写着S、M、L、XL、XXL加上“Out of Stock”，是让人挑码的，不是给人查尺寸的。所以本文把网格伪表的严格判据（类名或标签里明写size chart、size guide这类词）和宽判据（只要出现size、fit这类词）分开算，严格口径下命中的是18页，宽口径是30页。这12页的差额，就是“挑码的控件”和“查尺寸的表”之间的模糊地带。

要补一句公平话：ARIA的table角色本来就是给这种情况准备的，一个div加上role="table"、role="row"、role="cell"，语义可以补回来。这55个站上，我一个都没数到。

整张图片：13页命中，替代文本各写各的

命中“表图”的有13页、8个站。同样是把尺码表做成图，替代文本的写法差得非常远：

• casper把整张床垫尺寸图的替代文本写成了“King Dimensions 76"x80", California King Dimensions…”——数据本身写进了alt，这是全样本里唯一一家这么干的；
• italic的浴巾尺码指南是一张2570×4289的PNG，alt写着“Size Guide”，等于告诉机器“这里有张图，内容不告诉你”；
• brooklynbedding的床垫尺码图，alt是“FAQ Image”；
• liquiddeath的T恤尺码图，alt是商品名“Tatum Henderson #66 Official Tee”；
• materialkitchen那两张尺寸图，alt=""，按规范这是在声明“这是装饰图，请忽略”。

这几行差别，是图片alt能帮上什么忙、帮不上什么忙那篇结论最直接的一次落地：alt对网页排名帮不上什么，但当图里装的是本该可读的数据时，它是唯一的出口。想批量查一遍自己站上的alt，可以用一页图片的alt与属性批量体检那套流程。

还有一类载体，几乎没人拿它装尺码

方法那一节列了五类载体，前面说了四类，第五类是定义列表。dl加dt加dd是HTML里唯一天生就把“名字”和“值”绑在一起的结构，写“材质：美利奴羊毛”这种一对一的属性，它比表格更合适。258页里有43页出现过dl，占16.7%，来自9个站。

但仔细看会发现，这些dl基本没有一个是拿来装商品属性的。它们绝大多数出自导航菜单、页脚链接组和第三方组件的模板，最夸张的一页里有259个dl、1749个dt——那是一整套多级导航。MDN的dl元素说明里专门提醒过不要拿它做布局，可现实里它最常见的用途恰恰就是布局。真正该用它的那个地方——商品的材质、产地、重量、保养方式——反而清一色是div套div。

同一个页面等5秒和等25秒，量出来一样吗？

这一问必须做，不然前面的数字全是浮的。做法很笨：挑30个站各一页，同一个浏览器标签，等5秒量一次，再等20秒量第二次，中间滚到底再滚回顶。

结果是30页里有3页至少一项读数变了，占10.0%。aloyoga那一页第一次量到0张表，第二次量到1张——那张7行25列的尺码对照表是在第5秒之后才被注入的，同时正文字符数从3566涨到5540。brooklinen从4张变5张，jackery那张表的数量没变，但从不可见变成了可见。

10%听起来不高，可这三页恰好都是有尺码表的那类。反过来说，那些一张表都没有的页面，等多久都还是零，两次一致得毫无信息量。真正会抖的，恰恰是你想量的那一部分。

还有更细的一种。italic的4个商品页被两条采集通道各跑了一次，两次的正文字符数一模一样，但尺码指南入口一次数到0个、一次数到5个。页面主体是同一份，挂在上面的那几个按钮是异步补上去的。

所以本文所有数字的正确读法是：它们是等大约7秒、滚动一次之后的下限。真人拿着手机在弱网下打开，看到的多半更少；一个只抓首字节的爬虫，看到的更少。这条教训在渲染对比这件事上翻来覆去出现过，量出来的差异有多少是页面真的不一样、有多少是自己的尺子在抖，必须先分开。

不点那个按钮，表在不在页面里？

第二组自基线，是替用户点一下。30个页面里成功点开29个，点完等3.5秒再量一次。这一组把我原来的猜测改掉了一半。

先说数字：29个页面里，点完之后读数变了的只有6个，占20.7%。这6个里真正“点了才出现”的只有两个——rothys点开之后凭空多出3张表，而且全部可见；fromourplace多出1张。另外三个变的不是表的数量，是可见性：表一直躺在DOM里，点击只是把盖在上面的那层样式掀开。

还有一个是反过来的：monos点完之后，原本DOM里那2张尺码表反而不见了——那个按钮触发的是一次视图切换，旧的表格节点被整块替换掉了。

最要紧的是剩下那批：29个页面里有13个，替它点完之后DOM里依然既没有表也没有网格。这13个里有几个是我的判据认错了入口——harrys那个按钮上的文字其实是“Full-Size (18oz)$8.00”，那是商品规格不是尺码指南；ice-watch指向的是PDF，点击当然不会在页面里长出表来。但decathlon、gymshark、peakdesign、liquiddeath这几个是实打实的：入口在，点了，什么都没出现。它们要么把内容放在另一个地址里，要么需要比合成点击更真实的用户手势。

所以前面那48.8%不是一句话能解释的，它至少混着四种情况：真的要点才加载、点了也加载不出来、内容在另一个页面上，以及我这把尺子本身认错了入口。能确定的只有一件事：对一个抓完HTML就走的程序来说，这四种的结果一模一样。

顺带说个操作上的坑，写给要复现这套的人：用自动化框架的标准点击方法会大面积超时，因为它要等元素“可交互”，而这些站上同名的隐藏元素往往排在前面。换成在页面里自己找到那个可见的元素再触发点击，29比30的成功率立刻就有了。

原始HTML里有几张表，浏览器里有几张？

顺手做的一层对照：在页面上下文里再请求一次同一个地址，拿到服务器发出的那份原始HTML，数里面的table标签，跟渲染完成后的DOM比。

258页里88.0%两边一致；7.0%的页面渲染之后表变多了，说明是JS注入的；还有5.0%反过来，原始HTML里有、渲染完反而没了——前端框架接管之后把服务端那份结构换掉了。有11页原始HTML一张表都没有，DOM里才出现。

这几个数字看着不大，但它们决定了一件事：你用不同的工具审自己的站，会得到不同的答案，而两个答案都不算错。拿源码查看器看是一回事，拿爬虫抓是一回事，拿浏览器开发者工具看又是一回事。这和JS渲染的页面Google抓不到时该从哪查起是同一类问题，只是这次被检查的对象是一张表。

这件事到底影响谁？

搜索这一侧

Google早就不给表格单独出富媒体结果了，所以别指望写了table就能多一块展示位。真正的收益在别处：一张有表头的表格，是这个页面上信息密度最高、最容易被摘出来当答案的一段。主体内容占比这件事在商品页上尤其难看——商品页本来就没多少字，尺码表往往是整页字数最多、最独有的一块。把它做成图，等于把这一页最不可替代的内容从可读文本里删掉了。产品详情页怎么做出唯一内容那篇里讲的“摆脱供应商文案”，其实这张表就是现成的答案。

AI购物这一侧

用户问“我平时穿US 9，这双该选几码”，模型要么能从页面上取到那一行，要么就得去别处找。智能体读的是无障碍树，不是页面截图这个判断，在尺码表上兑现得最直接：一张display: grid的伪表在无障碍树里是一堆平级的文本节点，图片里的表连节点都没有。AI代理替用户逛店下单的时候，这一格取不到，它就换一家。

客服这一侧，账最好算

保哥手上有个做宠物出行装备的客户，去年把尺码问题的客服会话捞出来数过一遍：问“这个尺寸我家狗能不能用”的会话，占了售前咨询的两成出头。他们的尺码对照原本是一张放在弹窗里的图，客服每次回答都要重新打一遍数字。后来只做了一件事——把那张图旁边补了一份可选中的表格，客服可以直接复制粘贴。会话数没有明显下降，但单次会话的处理时长短了一截，因为不用再手打了。这不是SEO收益，是运营侧顺手捡的，可它恰好说明同一件事：能不能被复制、被摘取、被引用，取决于那份数据是不是以文本的形式存在。

读屏用户这一侧

这一侧最直接。网站无障碍那18个改动里，表格语义是投入产出比最高的一项之一：一张写了表头的表，读屏软件念到某一格时会先报出它属于哪一行哪一列；一张没写的，念出来就是一串孤零零的数字。语义化HTML那8类标签讲的是同一件事的一般形式，表格只是其中最容易被忽略的一类。

自己站上怎么查，查完改哪里？

不用搭实验台，四步就够：

1. 打开一个有尺码的商品页，什么都别点，直接在控制台里数document.querySelectorAll('table').length。为0，说明尺码表不是表格做的；不为0，接着看第二步。
2. 把结果里每一张表的可见性查一遍，看它是不是在弹窗里、是不是display: none。在DOM里就行，不必强求首屏可见。
3. 点开尺码指南，再数一次。数字变了，说明内容是点击之后才来的，这是最需要改的一类——把它挪进初始HTML，用折叠而不是用异步请求。
4. 如果尺码表是一张图，最低成本的补救不是重做，是把关键数据写进替代文本，像casper那样。彻底一点就是在图旁边补一份可读的表格，图留着给人看。

改的顺序，得先看第三步查出来的是哪一类。如果点完之后DOM里还是空的，那才是最该先动的一档——内容根本没进这一页，加载时机、样式、语义都无从谈起，得先把它搬回来。如果点一下就出来了，把它挪进初始HTML即可，不改样式、不改设计，只改加载时机，是这几步里最便宜的。如果表一直躺在DOM里只是被样式盖着，其实已经及格了，把网格换成真表格是下一档，这一步要动前端组件，但同一套组件全站复用，改一次全站受益。替换图片放最后。

什么时候可以不查？如果你的品类根本没有尺码概念——食品、香氛、订阅制服务——那这一层确实不用管。样本里drinkolipop的8张表全都可见、全都是营养成分表，wusthof的5张表也全可见，是刀具规格。它们没有尺码表，但它们把该表格化的东西表格化了，这就已经比一半的服装站做得好。

常见问题解答

把尺码表从图片改成HTML表格，能带来排名提升吗？

直接的排名提升不要指望。Google已经取消了表格类富媒体结果，写不写table本身不是排名因素。真正的收益有三处：这一页的可读文本变多且更独有；AI助手回答尺码问题时能取到你的数据；读屏用户能听懂。第三条在部分市场还是合规要求。

尺码表放在弹窗里，会不会被搜索引擎当成隐藏内容？

不会被当成作弊，前提是它在初始DOM里、只是被样式收起来。真正有风险的是另一种：内容压根不在HTML里，等用户点击才去请求。那种情况下不是权重折扣的问题，是根本没有内容可评估。

用div加role="table"补语义，和直接用table标签等价吗？

语义上接近，工程上不等价。ARIA角色要求把role="table"、role="row"、role="cell"甚至role="columnheader"成套写全，漏一层就断，而且浏览器不会替你兜底。原生table把这些默认给全了。除非布局上确实用不了表格，否则没必要绕这一圈。

怎么快速判断我站上的尺码表是不是点了才加载？

打开商品页，先不点任何东西，在控制台跑一次表格计数并记下数字，然后点开尺码指南，再跑一次。两个数不同，就是点击触发的。也可以直接看服务器返回的原始HTML里有没有那几个尺码关键词。

集合页和分类页上要不要也放尺码表？

不需要，那一层的信息任务不一样。尺码属于单品级别的属性，放在列表页只会稀释主体内容。列表页该解决的是另一批问题，商品列表页那97条准则里已经排过序。

这次的结论只适用于服装类目吗？

不。样本里家具、床垫、箱包、手表、厨具都出现了同样的形态——凡是需要给出尺寸对照的品类，都有把它做成图或做成网格的倾向。反倒是食品饮料类因为要合规披露营养成分，表格化程度最高。

权威参考资料