第三方评测背书写进结构化数据，一半属性挂不上去

摘要：想在商品页上声明“某某评测网站评测过这件东西”，能用的属性其实没几个。把十个候选属性拿到schema.org官方词汇表里逐个核对，只有五个挂在Product上是合法的，citation、about、mentions、isBasedOn、itemReviewed全部无效。再往大了数，一千六百多个属性里，对Product合法的只有七十二个。

做户外装备的一个客户问过保哥一件事：他们有款头灯被一个专做装备长测的站写过，评分不低，还配了实测数据。能不能把这条背书写进产品页的JSON-LD，让机器知道有人测过？

这个问题得拆成两半回答，因为两半的结论正好相反。

评测网站压根没写过你，这条标记算什么？

先说没写过的情况。有些人的想法是：反正JSON-LD是给机器看的，页面上又不显示，编一条好评塞进去，机器读到了就算数。

这条路是死的，而且死得很难看。

Google对评价摘要结构化数据的规定里有两条卡得很死。第一条是禁止跨站聚合，英文原文写的是“Don't aggregate reviews or ratings from other websites”，中文版更直接：请勿汇总来自其他网站的评价或评分。第二条是可见性要求，原文是“Make sure the review content you mark up are readily available to users from the marked-up page”，翻成人话就是：你标记了什么，用户在这一页上就得能看到什么。

两条合起来的意思很清楚：标记不是一个可以单独存在的图层，它是页面内容的机器可读副本。页面上没有的东西，标记里也不该有。

只在JSON-LD里写一句好评、页面上找不到任何对应内容，这在Google那里有个专门的名字，叫spammy structured markup。轻的处理是整段标记被忽略，重的是吃一个结构化数据的人工处罚，整站的标记都不再被信任。

更麻烦的是这件事不只是SEO问题。在美国市场，虚构第三方背书涉及虚假广告，那个风险比丢几个富媒体位置大得多。这一层不展开，找法务比找SEO有用。

想说“某某评测过我们”，schema.org里有几个属性能用？

再说评测网站确实写过的情况。这时候标记是可以做的，但先得知道该用哪个属性——这一步比想象中窄得多。

我把schema.org官方词汇表下载下来，离线跑了一遍。词汇表里一共1010个类、1676个属性，每个属性都带着domainIncludes（允许挂在哪些类型上）和rangeIncludes（值可以是什么类型）两项声明。Product的继承链很短，就两层：Product直接继承Thing。

然后我列了十个大家可能会想用的属性，逐个查它们的domainIncludes里有没有Product或Thing。

十个里只有五个能用。这个比例不是巧合。整张词汇表1676个属性里，对Product合法的只有72个，占4.3%；其中59个是domainIncludes里直接写着Product的，另外13个是只写了Thing、因而对任何类型都合法的。

那13个通用属性值得单独记一下，因为它们是唯一一批“挂在哪都不会错”的：additionalType、alternateName、description、disambiguatingDescription、identifier、image、mainEntityOfPage、name、owner、potentialAction、sameAs、subjectOf、url。

你会发现subjectOf就在这份名单里。这就是它能用来关联评测的原因——它不是给Product特批的，它对整个schema.org世界都开放。

citation为什么挂不上Product？

这条值得单独讲，因为它是最容易被误用的一个，而且写错了不会有任何报错。

schema.org对citation属性的定义写得很明白，它的domainIncludes只有一个值：CreativeWork。CreativeWork是文章、网页、书籍、视频这一类“被创作出来的东西”的总称，Product不在这条继承线上——它俩的唯一交点是最顶上的Thing。

所以citation表达的是“本文引用了那篇文献”，主语必须是一篇内容。商品不是内容，商品是被内容谈论的对象。这两件事在schema.org的建模里方向完全相反。

写错的后果不是报错，是静默失效。解析器读到一个domain不匹配的属性，通常的处理是丢掉它，然后接着往下读。你的验证工具一片绿，标记本身却少了一块。JSON-LD的语法校验能抓住尾逗号这类硬错误，但抓不住这种“语法完全正确、语义挂错了地方”的问题。

那citation该挂在哪？挂在WebPage节点上。WebPage是CreativeWork的子类，完全合法。这就带出了正确的分工：

• Product上写subjectOf，表达“这件商品是那篇评测的对象”；
• WebPage上写citation，表达“本页引用了那篇外部文献”。

两个可以同时写，也可以只写subjectOf。它们描述的是同一件事的两个侧面：一个是商品与评测的关系，一个是页面与文献的关系。

subjectOf该怎么写才不出错？

schema.org对subjectOf属性的定义里，rangeIncludes写的是CreativeWork和Event两种。Review的继承链是Review到CreativeWork再到Thing，所以把一个Review节点放进subjectOf里，类型是对得上的。

下面这段是可以直接改的骨架：

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://你的域名/产品页/#webpage",
      "url": "https://你的域名/产品页/",
      "citation": { "@id": "评测原文URL#review" }
    },
    {
      "@type": "Product",
      "@id": "https://你的域名/产品页/#product",
      "name": "产品名",
      "brand": { "@type": "Brand", "name": "品牌名" },
      "subjectOf": {
        "@type": "Review",
        "@id": "评测原文URL#review",
        "url": "评测原文URL",
        "headline": "评测文章的标题",
        "datePublished": "2026-03-14",
        "itemReviewed": { "@id": "https://你的域名/产品页/#product" },
        "author": {
          "@type": "Organization",
          "name": "评测网站的名称",
          "url": "评测网站首页"
        },
        "publisher": {
          "@type": "Organization",
          "name": "评测网站的名称"
        }
      }
    }
  ]
}

有几个地方需要说明。

author必须写成Organization，不能写成Person，除非那篇评测确实署了个人名。author的rangeIncludes只有Organization和Person两种，写成一个裸字符串虽然很多解析器容忍，但那样机器就没法把它和评测方这个实体对上号了。

Review节点里的itemReviewed反过来指回Product的 @id，这一笔很多人会省掉。它的作用是把关系闭合：Product说“我是那篇评测的对象”，Review说“我评的就是它”。单向声明和双向闭合在图结构里是两回事，后者才构成一条真正的边。itemReviewed的rangeIncludes是Thing，所以指向Product完全合法。

评测原文的URL必须是真实存在、能打开的那一个。如果拿不出真实链接，这套标记就别上——挂一个假的 @id上去，是负资产不是资产。

还有一个属性值得知道：positiveNotes和negativeNotes。它俩的domainIncludes是Product和Review两个，也就是说编辑型评测的优点缺点可以直接挂上去。这两个属性在中文资料里几乎没人提，保哥也是这次核词汇表才注意到。

别拿sameAs代替subjectOf

sameAs的语义是“指向能唯一确认这个实体身份的页面”，典型的值是维基百科条目、官方社交主页、Wikidata条目。它回答的是“这个东西是谁”，不是“谁谈论过这个东西”。

把一篇评测文章塞进sameAs，等于告诉机器“那篇评测就是我这件商品本身”。这是身份层面的错误声明，比不写更糟。

这条评分能不能并进aggregateRating？

不能。这是本文里唯一一条该当成红线的规矩。

aggregateRating的语义是“页面上展示的全部评价的汇总”。把一个第三方媒体给的分数并进自家用户评分里算平均，同时踩中了前面那两条：既是跨站聚合，又是页面上看不到对应内容。

正确做法是让它们各走各的：自家用户评论走aggregateRating加review数组，第三方评测走subjectOf。两条线不交叉，机器读到的是两类不同来源的证据，反而比混算更清晰。

顺带说一句aggregateRating本身的硬要求：ratingValue是必填的，ratingCount和reviewCount至少要有一个。这两条经常被CMS插件写漏，评论系统那一侧的配置另有一篇讲得比较细。

写了能拿到星标吗？

大概率不能，但原因和你想的不一样。

先澄清一个流传很广的说法：2019年Google收紧自我评价的时候，限制的范围其实很窄。官方原文是这么写的：“If the entity that's being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature”。

翻过来就是一句话：只针对LocalBusiness和Organization这两类，Product不在里面。

所以从政策上讲，商品页的星标资格并没有被那次调整拿掉。

但现实是另一回事。电商的星级评价现在很大程度上走Merchant Center的商品评价数据源，页面上的JSON-LD未必能触发展示。你写了标记不等于会出星，这中间隔着Google自己的展示逻辑，那部分不由你控制。

更关键的是，subjectOf这条根本就不是富媒体属性。它不产生任何搜索结果里的视觉变化。如果你做这件事的动机是拿星标，那从一开始就走错方向了。

排名会因此变好吗？

不会。结构化数据不是排名因素，它影响的是展现资格，这一点Google说了很多年。

做完这套标记，你在搜索结果里的位置不会动。这话说得可能有点扫兴，但把预期摆正比什么都重要。保哥见过一个团队花两周给全站产品页补评测关联，两个月后拿着排名曲线来问为什么没变——那两周的力气本身没白费，只是他们盯错了指标。

它真正可能有价值的地方在别处。

AI那边到底看不看JSON-LD？

这个问题现在有实测答案了，而且答案不太好听。

searchVIU在2025年10月做的一组对照测试，设计了八个场景，分别在ChatGPT、Claude、Perplexity、Gemini和Google AI Mode上跑。测试的核心是：把同一条信息分别只放在可见HTML里、只放在JSON-LD里、只放在Microdata或RDFa里，看这些系统实时抓取一个页面时，各自能取到多少。

能取到的那几个，信息全都同时出现在可见HTML里。只放在结构化数据里的，几乎一条都没取到。

这个结果和很多人的直觉相反，但它其实很好理解：这些系统实时抓一个页面时，走的是接近浏览器的读取路径，读的是渲染后的文本。JSON-LD是给索引管线准备的，不在那条路径上。

所以结论要分开说：结构化数据的作用发生在索引层和知识图谱层，不发生在实时抓取层。它间接影响的是Google AI Mode、Copilot这类深度依赖自家图谱的产品；至于ChatGPT和Perplexity那种现抓现读的场景，你得靠可见文本。Schema对AI搜索到底有没有用这个话题站内单独写过一篇，可以对着看。

那这套标记的价值到底在哪

讲到这里，价值的边界其实已经很清楚了。

你在自己页面上写的一切，本质上是单向声明。机器对单向声明天然打折，因为声明的成本太低——谁都可以说自己被权威媒体评测过。

真正让这条背书成立的，是评测网站那一侧：那篇文章存在、能被抓取、写了你的产品名。这是可以被交叉验证的一手证据。你的标记只是把这条证据指出来，让机器不用靠猜。

所以优先级应该是这样排的：

1. 先想办法拿到真实的第三方评测或提及，这一步占了这件事九成的价值；
2. 页面上如实引用，放一段原文片段、评测日期，加一条指向原文的外链；
3. 最后补schema，把这条关系写成机器可读的形式。

顺序反过来做——只补schema、前两步不做——性价比接近零。实体之间的关系怎么审是更大的一个话题，评测关联只是其中一条边。

页面上要先有真东西

虽然subjectOf不是富媒体属性、不受评价摘要那套显示规则约束，但页面上如果完全看不到这次评测的任何痕迹，标记的可信度和实际效果都接近零。

最低限度要做的：一段引用原文的片段、评测方的名字、评测日期、一条指向原文的链接。这四样东西同时也是给用户看的——一个真被权威媒体测过的品牌，本来就该把这件事写在页面上，不是吗。

这里有个小陷阱：不少团队会把评测引用做成一张图片，好看是好看，机器什么也读不到。既然前面已经说清楚了实时抓取只认可见文本，那这段引用就必须是真正的文字。

一次把评测关联这件事做完

把上面的东西压成一份可以照着做的顺序。

第一步，确认那篇评测真的存在，把URL记下来，用无痕窗口打开一次确认能访问。这一步听起来多余，但被引用的评测文章下线、改版换URL是常事。

第二步，页面上补可见内容：引用片段、评测方名称、日期、外链。

第三步，写标记。Product上挂subjectOf，Review节点里带上itemReviewed、author、url、datePublished，评测方给了分数才写reviewRating，没给分就整块删掉，留headline加author加url就够了。

第四步，验证。这一步很多人用错工具：这套标记在富媒体结果测试里不会有任何反馈，因为它本来就不触发富媒体结果。要验结构正确性得用schema.org官方的结构化数据验证器，它检查的是词汇本身对不对，跟能不能出富媒体没关系。两个工具都跑一遍最稳。

第五步，如果你想自己核一遍某个属性到底能不能挂在某个类型上，不用查文档，直接下词汇表。schema.org给开发者提供的词汇表下载里有完整的JSON-LD版本，一点五兆左右，用几行代码就能查domainIncludes：

import json
g = json.load(open('schemaorg-current-https.jsonld', encoding='utf-8'))['@graph']
props = {n['@id']: n for n in g if 'rdf:Property' in (
    n.get('@type') if isinstance(n.get('@type'), list) else [n.get('@type')])}

def domain_of(p):
    v = props['schema:' + p].get('schema:domainIncludes')
    v = v if isinstance(v, list) else [v]
    return [x['@id'] for x in v]

print(domain_of('citation'))    # ['schema:CreativeWork']
print(domain_of('subjectOf'))   # ['schema:Thing']

这段代码是本文那张属性表的来源，跑一次不到一秒。比在论坛上问“这个属性能不能这么写”快得多，也可靠得多。

常见问题解答

评测网站没写过我们的产品，能不能先把标记写上？

不能。Google的评价摘要规则里有两条硬要求：禁止汇总来自其他网站的评价或评分，以及标记的评价内容必须在这一页上让用户看得到。页面上没有对应内容、只在JSON-LD里写一条好评，属于典型的欺骗性标记，轻则整段标记被忽略，重则吃结构化数据的人工处罚。在美国市场还牵扯虚假背书的合规风险。

citation和subjectOf有什么区别，该用哪个？

差别在于它们能挂在什么类型上。查schema.org官方词汇表，citation的domainIncludes只有CreativeWork，挂在Product上是无效属性；subjectOf的domainIncludes是Thing，任何类型都能用。正确分工是Product上写subjectOf表示这件商品是那篇评测的对象，WebPage节点上写citation表示本页引用了那篇文献，两个可以同时写。

能把第三方评测的分数并进aggregateRating吗？

不能，这是最常见的违规写法之一。aggregateRating的语义是页面上展示的全部评价的汇总，把一个第三方媒体分数和自家用户评分混算，既是跨站聚合又是页面上看不到对应内容，两条规则一起踩。正确做法是让两条线各走各的：用户评论走aggregateRating，第三方评测走subjectOf。

写了subjectOf能不能拿到搜索结果里的星标？

不能，它根本不是富媒体属性，不产生任何搜索结果里的视觉变化。顺带澄清一个流传很广的说法：2019年Google收紧自我评价时，限制只针对LocalBusiness和Organization两类，Product并不在其中。但电商的星级评价现在很大程度上走Merchant Center的商品评价数据源，页面上的JSON-LD未必能触发展示。

AI到底读不读JSON-LD？

实时抓取一个页面的时候基本不读。searchVIU在2025年10月的对照测试里设计了八个场景，Gemini取到4个、ChatGPT取到3个、Claude一个都没取到，而且纯粹只放在结构化数据里的场景全部失败。能被取到的信息全都同时出现在可见HTML里。结构化数据真正起作用的地方在索引层和知识图谱层，不在实时抓取层。

怎么确认某个属性能不能挂在某个类型上？

下载schema.org官方词汇表的JSON-LD版本，查那个属性的domainIncludes里有没有你的类型或者它的某个祖先类。比如Product的继承链只有Product到Thing两层，所以domainIncludes里写着Thing的属性对它都合法。整张词汇表1676个属性里，对Product合法的只有72个。

权威参考资料