结构化数据实测66个站：产品页都写了，类目页只有三分之一

摘要：131个海外品牌站，用真实浏览器把首页、类目页、产品页各抓一遍，66个站三种页面齐全。给人看的那几行分辨率很高——三种页面的标题无一重复，规范网址无一重复。可轮到机器要判断“这一页是什么”，产品页有Product类型的占93.9%，类目页有列表类型的只有33.3%。剩下那44个类目页里，16个页面上唯一的列表是面包屑，12个连一段结构化数据都没有。三种页面全都说清了自己是谁的站，58个严口径样本里只有15个。

先做个小测试。下面三个网址，你不打开页面，只看地址，能判断出各是什么页吗？

bellroy.com/products/category/outlet
babybjorn.com/products/baby-carriers/
untuckit.com/collections/new-arrivals/products/morningside

第一个路径里写着products，其实是个折扣专区的列表页。第二个也写着products，是背带的品类页。第三个路径里写着collections，反倒是一个实实在在的商品详情页。

这三条不是我挑出来为难人的，是这一轮实测里脚本自己撞上的。用网址模式挑页面，70组里挑错了4组——而这恰恰是本文要讲的那件事：网址不是身份声明。它长什么样，取决于当年谁定的路由规则。

人不看网址，看页面。屏幕上摆着一排商品卡片，一眼就知道这是列表页；摆着一个大图加一个加购按钮，那就是详情页。这个判断快到你意识不到自己在判断。

但机器没有这个眼力。它得从字节里找线索。这一轮就是想量清楚：三种页面并排放着，究竟有多少东西能让机器把它们区分开。

三种页面各抓一遍，样本是怎么来的？

样本沿用这一系列一直在跑的131个海外品牌与电商独立站，覆盖服饰、家居、户外、3C、美妆、食品饮料几大类，绝大多数是有独立品牌的中大型站。这个分母要先说清楚：Web Almanac 2024统计过全网只有0.77%的页面带Product结构化数据，那是把所有网页放一起算的；本文的样本全是电商站的商品页，两个数字不矛盾，分母压根不是一回事。

抓取方式是真实浏览器（Chromium），带常见的桌面浏览器身份，每个站按同一套流程走三步：

• 打开首页，等页面渲染完；
• 从首页链接里挑一个类目页，打开；
• 再挑一个商品详情页，打开。

每一页都存两份：服务器直接吐出来的那份HTML，和浏览器执行完脚本之后的那份DOM。两份都解析，取并集——也就是说，只要结构化数据是在渲染后才出现的，也算它有。这一点很重要，不然会把一批用前端框架的站冤枉掉。

131个站里，128个拿到了首页；三种页面全部拿到的有70个。拿不齐的原因基本都是首页链接结构特殊，脚本按路径规则没挑出合适的候选，跟站本身好坏无关。

两份分开存这一步没白做。后面要用到的那几个身份声明，服务端就有和渲染后才有，差着几个百分点：产品页的Product声明服务端有60个站，渲染后61个；类目页的列表声明服务端19个，渲染后22个。差值不大，但方向一致——正文整段要等脚本跑完才出现的空壳页确实存在，只是在结构化数据这一层没那么普遍。有个站还反过来：服务端那份里有Product，渲染完反而没了，多半是前端把整段节点重写掉了。

然后是人工那一步。70组网址我逐条看过一遍，剔掉了4个挑错页面的站，主口径落在66个站。另外单独标出了8个站的“产品页”其实是礼品卡——它是商品，但没有尺寸重量这些属性，很多站不给它发结构化数据，放在一起会稀释结论。严口径的58个站会在后面单独出现一次。

给人看的那几行，三种页面写得一样吗？

先看好消息，而且是相当出乎意料的好消息。

做技术审计的人，脑子里大多有个刻板印象：内页没人管，标题是模板拼的，描述干脆空着。这一轮的数据不支持这个印象。

标题、规范网址、分享标题这三样，三种页面之间没有一个站出现重复。规范网址这一栏还能再挑一次刺——三条互不相同只说明它们指向不同的页，指得对不对是另一回事，首页那一轮量下来有23%的站自己跟自己对不上。页面描述56个可比站里只有2个三条完全一样（flyingtiger和italic）。文字层的分辨率几乎是满的。

顺带说一句，模板做齐了不等于内容做对了。allbirds的类目页有一行完整的描述标签，只是content写成了空字符串——框架发下去了，填值那步没跟上。这类“标签在、值空着”的情况，跟标签压根不在，是两种病。

再往下走一层，情况就变了。

那机器怎么知道这一页是列表还是详情？

屏幕上那排商品卡片，在字节里是几十个div。机器要判断“这是个列表页”，最直接的依据是页面自己声明：我是一个CollectionPage，里面有一个ItemList，成员是这些商品。schema.org给ItemList的定义很朴素——一组有序的条目，配上itemListElement和numberOfItems两个字段，就够机器把这一页认出来了。

66个站的三种页面，各查一项最该有的身份声明：

产品页93.9%，类目页33.3%。这不是一点差距，是接近三倍。

把礼品卡那8个站也剔掉，只留下有真实商品属性的58个站，差距只会更大：产品页94.8%，类目页29.3%。

再换个角度数。这58个站里，三种页面全都说清了自己是什么的，只有15个（25.9%）；说清两种的34个；只说清一种的8个；一种都没说清的1个。四分之三的站，页面身份这件事上是缺一块的，而缺的那块几乎总是同一块。

为什么产品页做到了94%，类目页只有33%？

这个问题的答案，比“大家偷懒”要有意思得多。

顺便说一句，这两类页面的结构化数据经常不是同一个人在维护。主题输出一套、SEO插件再输出一套，最后在head里撞成一团是很常见的局面，而撞车最多的恰恰是产品页——因为那一层大家都在抢着写。

产品页的结构化数据是有直接回报的。写了Product和offers，搜索结果里就可能带上价格、库存、评分那几行。这个回报十几年来一直存在，一直被工具检测，一直被建站平台写进默认模板。同一批样本里，产品页带offers的比例是92.9%，带评分的57.1%——这些字段的分布，跟Google富媒体结果需要什么，几乎是同一张形状。

类目页没有这个回报。很长一段时间里，把类目页标成CollectionPage，搜索结果不会因此多出任何东西。没有可见回报的事，默认模板就不做；模板不做，绝大多数商家也不会自己补。

这里有个更早的证据可以对照。上一轮量产品页规格的时候发现过一件事：64个有Product结构化数据的产品页，写了价格的64个一个不落，写了规格属性的只有7个。同一批人、同一套模板、同一个页面，差别只在于哪个字段能换来搜索结果里的一行显示。

行业是被富媒体结果牵着走的。牵到哪，就写到哪。这句话在字段层成立，在页面类型层同样成立。

那44个没说清自己是列表的类目页，页面上都写了什么？

“没有ItemList”不等于“没有结构化数据”。把66个站的类目页按有什么分成四类：

中间那两类加起来48.5%，占了将近一半。这些页面不是空白——它们有Organization，有WebSite，有搜索动作声明，有联系方式，甚至有客服电话和邮寄地址。关于“我们是谁”，写得很齐；关于“你现在看的这一页是什么”，一个字没有。

把70个类目页的结构化数据类型统计一遍，排在最前面的是ListItem，出现38次。乍一看挺好，列表项都有了。但再看第三名是BreadcrumbList，32次——ListItem大部分是面包屑的成员项。

也就是说，类目页上出现最多的那种“列表”，描述的是你在网站的哪一层，不是这一页有哪些商品。

再往下，ItemList只有20次，CollectionPage 17次。Organization倒是有34次。

这个排序本身就能说明问题。面包屑在搜索结果里能显示成路径，所以做的人多；ItemList在过去很多年里不显示，所以做的人少。跟上一节是同一个机制。

aloyoga：三种页面发的是同一份声明

有个站值得单独拎出来。aloyoga的首页、类目页、产品页，结构化数据的类型集合完全一样，一个字不差：Organization、WebSite、SearchAction、SoftwareApplication、AggregateRating、Offer。

包括产品页——它的产品页里没有Product。一个卖瑜伽服的站，全站每一页都在庄严声明自己是个软件应用，而且评分不低。

顺着看下去还挺有意思：那个SoftwareApplication加AggregateRating，跟一个服装品牌的商品毫无关系，多半是某个评分类应用注入的模板。第三方脚本往页面里塞东西这件事，只看HTML基本看不出来，等它塞完，你的结构化数据里就多了一段不属于你的类型。整套东西就这么挂在全站每一页上，不管你打开的是首页还是一双鞋。

这是“身份声明”最极端的形态：它给每一页都发了一份“我们是谁”，却没有一页说清“这一页是什么”。全站一致，一致得毫无信息量。

用网址判断页面类型，我自己就判错了4次

说回开头那三条网址。

脚本挑页面用的是路径规则：路径里有 /products/、/p/、/item/ 的当详情页，有 /collections/、/category/、/shop/ 的当列表页。这是所有爬虫、所有审计工具、所有做站内分析的人都在用的办法。

70组里错了4组：

• bellroy的 /products/category/outlet，路径里有products，实际是折扣列表页；
• babybjorn的 /products/baby-carriers/，同样是列表页；
• lookfantastic的 /c/info/delivery/，路径里有 /c/，实际是配送说明页；
• madewell的 /c/inspo/，是内容专题页。

错误率5.7%。听着不高，但请注意，这是一个人拿着70条网址逐条看过之后才发现的。如果没有这一步，产品页那一栏的数字会被两个类目页拉低，我会得出一个偏低的结论，而且完全不知道自己错在哪。

顺带一提，那8个礼品卡也是这么发现的——脚本挑中的“产品页”是礼品卡，8个里只有7个有Product声明，比正常商品页低。这个数太小不足以下结论，但足以说明分层的必要。

这件事本身就是本文的论据。连人带脚本，靠网址判断页面类型都会错；AI爬虫扫过来的时候，它凭什么判对？

做审计时按页面模板抽样是对的，几万行网址落到代码上其实只有几十个模板。但模板的边界在哪，得由页面自己说，不能靠网址猜。

除了结构化数据，还有别的线索能用吗？

结构化数据不是唯一一条线索。页面上还有两样东西经常被当成页面类型的依据：社交分享标签里的类型字段，和H1。这两样都便宜，都好写，问题是它们靠不靠得住。

社交分享那一层，能不能顺便把身份补上？

og:type这个字段，本来就是干这个的：网页类型。它比结构化数据简单得多，一行搞定，Open Graph协议原文里给的标准取值也就那么几个。

66个站的实际填法：

• 首页：website 49个，没写20个；
• 类目页：website 38个，product.group 13个，没写18个；
• 产品页：product 46个，website 8个，没写16个。

有意思的是最后那一列：三种页面的og:type完全一样的站有22个，占31.4%——首页写website，类目页写website，产品页还是website。这个字段等于没填。

类目页那13个product.group值得注意，它不是Open Graph的标准取值，是电商站自己扩的。这至少说明有人认真想过“这一页是什么”这件事。

不过话说回来，og:type的读者主要是社交平台的抓取器，搜索引擎和AI爬虫基本不拿它当页面类型的依据。它可以顺手写对，但指望它承担身份声明，不现实。真正管用的还是结构化数据。这两层怎么分工，首页那六个自我介绍字段各归各的读者那篇已经拆过一遍。

三种页面的H1，是不是也各是各的？

H1是另一条常被当成页面身份的线索。理论上它该回答“这一页讲什么”，跟页面类型天然相关。

66个站的渲染后DOM，按三种页面数H1个数：

• 三种页面都恰好一个H1的，20个站，30.3%；
• 首页一个H1都没有的，15个站；
• 至少有一页H1超过一个的，30个站；
• 最夸张的是beistravel的类目页，25个H1——每张商品卡片的标题都用了H1。

三种页面H1个数完全一样的只有21个站。也就是说，同一个站的三种页面，H1的用法本来就不统一，拿它当页面类型的判据是靠不住的。

这跟之前量过的另一件事是配套的：屏幕上最大那行字，四成多的电商首页里根本不是H1。标题标签在实际站点上早就不承担“这一页是什么”的职责了，它更多是个排版遗留。指望机器从H1推断页面类型，跟指望它从网址推断，性质是一样的。

换个建站平台，这件事会自动解决吗？

把66个站按建站平台分组，能看出默认值起了多大作用。平台判定是单独跑的一轮：抓首页源码，找cdn.shopify.com、myshopify.com、Shopify.theme、shopify-section、window.Shopify这几个确凿特征，命中才算。

三种页面齐全的样本里，Shopify站50个，非Shopify站11个，还有几个因为限流没判出来。11这个数太小，下面的对比只能当方向，不能当结论。

方向很清楚：站在一个成熟平台的默认值上，产品页这块基本白送。96%这个数不是50个商家各自努力的结果，是主题模板里本来就写好的。

但类目页那一栏，Shopify也只有40%。默认模板把有回报的那件事做了，没回报的那件事同样没做。

这就是默认值这件事一直以来的形状：它替你做的那部分，做得比你自己做还好；它没替你做的那部分，你多半也不知道它没做。上一轮量AI代理能不能用你的站时，也撞上过同一堵墙——四个动作83个站只有1个全通，通得最多的两项恰好是平台自己实现的搜索和加购。

这件事对AI购物代理意味着什么？

放在几年前，类目页没有ItemList，代价基本为零。搜索引擎有的是办法认出一个列表页——链接密度、卡片重复结构、分页参数，随便哪一条都够用。

现在多了一类读者。AI代理替用户逛店，第一步要判断的就是“我现在在哪一层”：这是个可以往下钻的列表，还是一个可以下单的详情？判断错了，后面全错。

而它的输入条件比搜索引擎苛刻得多。搜索引擎可以对一个域名抓几十万页慢慢学结构，代理往往只有当前这一页，甚至只有这一页的一部分。机器优先的架构要解决的就是这类问题——把人靠眼睛得到的信息，明确写进字节里。

这类判断做不对，后果不止是少一次曝光。给独立站打一份智能体就绪度分的时候会发现，页面类型识别是那张表最靠前的一行，因为它错了后面每一项都白测；代理替用户逛店时品牌是没被看见还是被淘汰，很多时候就卡在这一步。

更现实的一点：类目页恰恰是电商站最有价值的那类页面。它对应的是“男士跑鞋”“无线充电器”这种有搜索量、有商业意图的词。集合页在AI购物场景里才是主战场这个判断，跟这一轮的数据是对得上的：主战场上有三分之二的页面没有向机器报过身份。

但也别把ItemList想成灵丹妙药

得说句公道话。没有ItemList，页面不会被降权，也不会不被收录。搜索引擎照样能理解你的类目页，这一点Google的文档里说得很清楚：结构化数据是让你有资格获得某些展示形式，不是排名因素。

它的价值在于确定性。有声明，机器不用猜；没声明，机器靠推断，推断就有概率错。三分之二的类目页现在把这件事交给了概率。当读者只有搜索引擎时，这个概率足够高；当读者变成一个只看一页就要做决定的代理时，就不一定了。

类目页的列表声明，怎么写才算数？

先说最容易踩的一个坑：ItemList里的每一项，得给出商品自己的网址。

Google关于轮播富媒体结果的文档对这一点有明确要求——列表里的每个ListItem要用url指向对应的详情页，而不是把商品的全部信息塞在列表页里。写成后者，通常拿不到轮播展示，白写。

一个能用的最小结构长这样：

{
  "@context": "https://schema.org",
  "@type": "CollectionPage",
  "name": "男士跑鞋",
  "url": "https://example.com/collections/mens-running",
  "mainEntity": {
    "@type": "ItemList",
    "numberOfItems": 24,
    "itemListElement": [
      { "@type": "ListItem", "position": 1,
        "url": "https://example.com/products/cloud-6" },
      { "@type": "ListItem", "position": 2,
        "url": "https://example.com/products/cloudrunner-2" }
    ]
  }
}

几个实操上的注意点：

• position要跟页面上的实际顺序一致。翻到第二页时position应该从25开始，不是从1重新数。这条最常被忽略，因为分页模板往往是另一个人写的。
• numberOfItems填当前页的商品数还是整个类目的总数，两种写法都有人用。填当前页更保险，跟页面内容对得上。
• 筛选之后的页面要不要发列表声明，看你的规范网址怎么定。用户连点五个筛选之后自己都忘了选过什么，机器更是如此。如果筛选页指向未筛选的类目页，那就别在筛选页上另发一份列表，会自相矛盾。电商重复内容的成因地图里这一类占了不小比重。
• 别和面包屑混为一谈。面包屑那份文档说得很清楚，BreadcrumbList描述的是层级位置；商品列表用ItemList，两个都发，各管各的。
• 手写容易漏字段，可以先用结构化数据生成器把13种常见类型的骨架拉出来再改。
• 发之前过一遍语法。一个尾逗号就能让整页结构化数据失效，这种错误肉眼很难看出来。

怎么查自己站上这三层身份？

不用买工具，三步能查完，比泡一杯咖啡的时间长不了多少。

第一步，选样本。每种页面模板挑一个代表页就够了：首页、一个主类目页、一个筛选后的类目页、一个普通商品页、一个变体商品页、一个礼品卡或虚拟商品页。六个网址，覆盖大部分情况。

第二步，看服务端给的那份。在页面上右键查看源代码（注意不是开发者工具里的Elements面板，那是渲染后的），搜application/ld+json，把每一段的@type记下来。这一步能分清哪些声明是服务端就有的，哪些要等脚本跑完才出现——对AI爬虫来说这个区别很关键，渲染这件事上真正会丢东西的地方跟大家担心的不太一样。

第三步，填一张表。六行，每行三列：这一页是什么类型、它声明了什么类型、两者对不对得上。

填完之后，大概率会出现本文那个形状：产品页那行是满的，类目页那行是空的。

保哥给客户做这一步的时候有个习惯，先不看代码，先问一句“你们类目页是谁做的”。答案通常是“主题自带的”。那基本就能猜到结果了——主题自带的那部分做得挺好，主题没带的那部分一片空白。

补起来其实不难。类目页模板里加一段JSON-LD，商品循环里顺手把url收集进itemListElement，多数主题不到二十行代码。难的是先知道它缺着。

如果你用的是Shopify，这件事还要看你手上有什么工具。平台内置、通用工具与专属应用是三层，能改模板的和只能改字段的，处理这件事的成本差好几倍。商品标识符那一层也顺手对一下，GTIN这类字段在几大平台上的写法各不相同。

回报的账，该重算了

你的三种页面，给人看的那部分各说各的，分辨率很高；给机器看的那部分，只有产品页说清了自己是什么。

不是因为没人在乎类目页，是因为过去很多年里，把类目页说清楚这件事没有回报。现在多了一类只看一页就要做决定的读者，回报的账要重新算了。

常见问题解答

类目页加了ItemList，排名会变好吗

不会直接变好，别指望改完下周看排名。结构化数据决定的是展示资格，比如能不能进商品轮播，不是排名信号。它真正省掉的是机器的推断成本：有声明，这一页是什么当场就定了；没声明，机器靠链接密度和卡片重复度去推，推得对不对看运气。要看效果，盯的应该是Search Console里富媒体结果那几张报表有没有新条目冒出来，而不是盯关键词排名。生效周期通常按周算，取决于重新抓取的频率。

我的类目页有面包屑结构化数据，算不算已经声明了页面类型

不算。面包屑说的是这一页在网站层级里的位置，不是这一页的内容是什么。实测里16个站的类目页正好卡在这个状态——有BreadcrumbList，没有ItemList，占24.2%。两者是互补的：面包屑帮机器理解站点结构，列表声明帮机器理解当前页内容，都发一份才完整，各占各的位置，不冲突。

用JavaScript渲染出来的结构化数据，搜索引擎和AI爬虫认吗

搜索引擎认，因为它会执行脚本再解析；很多AI爬虫不认，因为它们大多只取服务端返回的那份HTML。这一轮的统计取的是两份的并集，所以数字对渲染型的站是宽容的。如果你的读者里有AI爬虫，建议把身份声明这类关键信息放进服务端输出，不要等脚本跑完才注入。查法很简单：右键查看源代码，能搜到就在服务端，搜不到就不在。

产品变体很多的商品页，该发Product还是ProductGroup

有多个变体、每个变体有独立价格或独立网址的，用ProductGroup包住，把各变体作为hasVariant里的Product，字段清单见Google的商品结构化数据文档。实测样本里产品页出现ProductGroup的有33个站，跟Product几乎是并行使用的关系。只有一个规格的普通商品，直接发Product就行，不必强行套ProductGroup。

变体到底该合成一页还是拆成多页，同一商品几十个网址是合还是拆那篇给过一套判断顺序：先定网址再定结构化数据，顺序反了会反复返工。关键是别让变体各自发一份互相冲突的声明。

礼品卡、服务类商品这种页面要不要发Product

要发，但属性可以少。实测里8个礼品卡页面有7个发了Product，只是没有尺寸重量这些字段。对机器来说，重要的是“这一页是一个可购买的东西”这个判断，属性齐不齐是第二位的。反过来，如果礼品卡页面什么都不发，代理很可能把它当成一个普通内容页，直接跳过。

类目页翻到第二页第三页，列表声明要不要跟着改

要。ListItem的position应该反映真实位置，第二页从25开始就写25，不要每页都从1数起。另外每一页的列表成员当然也不同，得跟着分页一起生成。分页模板和类目模板经常不是同一个人维护，这是这条最容易掉链子的地方。改完之后随便翻两页对一下position，一分钟能验完。

只有一个类目页没有列表声明，值不值得为它改模板

改模板的收益从来不在一个页面。类目页是模板产物，一个站几十上百个类目页共用同一份模板，改一次全站生效。实测里22个有列表声明的站，几乎都是模板层统一发的，不是一页一页手工加的。所以问题不该是“这一页值不值得”，而是“这个模板值不值得”，后者的答案通常是值得。

权威参考资料