要判断一个自称评测站的网站究竟在做什么，最省时间的做法是打开页面源码，搜索 application/ld+json，把里面声明的 @type、author、publisher、sameAs 和 aggregateRating 逐条拎出来，再跟页面上肉眼可见的东西对照。标记是站长主动写给机器看的声明，可见内容是事实，两者对不上的地方，就是这个站真正暴露出来的东西。
我第一次这么做，是盯着一台还亮着屏幕的笔记本，把一个站首页的源码从上到下滚了三遍。Ctrl+U，Ctrl+F，敲进去 ld+json。三个结果：一个 Organization，一个 WebSite，一个 BreadcrumbList。文章页里才有 Article。当时我想要的答案是"这个站是不是真的在做横评"，源码先给了我另一个答案：它连评测的主体都没有在页面级别的声明里出现过。
从那以后，看一个新站我会先看代码，再看内容。顺序反过来也行，但先看代码快得多。
先数 @type，别急着读正文
JSON-LD 就是放在 script 标签里的 JSON，浏览器打开源码就能看到，不需要装任何东西。我习惯先把一个页面出现的 @type 抄成一行：首页 Organization、WebSite；栏目页 CollectionPage、BreadcrumbList；文章页 Article、FAQPage，偶尔带 Product。
- Article：这是一个内容页，通常会附带 headline、datePublished、dateModified、author。
- FAQPage：页面上有一组问答，正常情况滚动页面就能看到那组问答。
- Product：这是一个商品页，带 name、offers，可能还有 review 或 aggregateRating。
- Organization：站点在声明自己是谁，通常带 name、logo、sameAs。
抄完之后不要继续读代码，回到渲染好的页面上，一样一样找。FAQPage 声明了五组问答，页面上只有两段正文、一个问答都没有——这不是"技术细节没做完"，这是声明和内容之间的公开矛盾。
单个矛盾可能只是模板问题。但如果一个站的文章页清一色挂 Product，结论页挂 Article，首页挂 Organization，这个分布本身就是信息：它告诉你这个站把什么当商品卖，把什么当内容写。
当 type 跟可见内容对不上，我看到的几种形态
- 列表页挂 Article，但页面是一堆条目的罗列，没有作者、没有日期；
- 评测页挂 Product 并带 aggregateRating，整页却只有一个编辑写的结论，没有任何用户评价区；
- 关于页挂 Organization，logo 指向一个空图片路径，sameAs 是个空数组；
- 文章页的 author 是一个通用品牌名，点进去没有作者页，也没有任何个人实体；
- 面包屑标记里有三级路径，页面上只显示"首页 > 文章"。
每一条单独看都能解释成"实现没做全"。把它们摞在一起，你看到的是这个站的默认工作方式：标记是模板批量吐出来的，内容是照着关键词堆的，两边谁也没管谁。
这里要分清一件事。标记和内容不一致，是公开可验证的实现风险，不是罪证。它可能意味着这个站有内容质量问题，也可能只是一个建站插件在自动补默认值。所以我不靠单页下结论，我看同一个类型在十个页面上是不是稳定出现、是不是跟着内容一起变。
author、publisher、sameAs：顺着实体往下走
sameAs 的用途是声明"同一个实体在别处也有公开地址"。一个真在做评测的站，作者 Person 一般会 sameAs 到社交账号或个人主页，Organization 会 sameAs 到官方社交号、维基数据条目、工商或备案信息。如果 sameAs 里全是自己站内的链接，或者十来个作者统统指向同一个首页，那这个站对外部世界的实体连接基本是零。
很多站会用一个 @graph 把几个实体装进同一个 script，再用 @id 互相引用。这时候别只读第一层，顺着 @id 走过去看：Organization 指向的那个 @id，是不是就是文章页 publisher 引用的那个；作者那个 @id，下面有没有真的挂 name 和 url。断掉的 @id 链条，比缺失的属性更能说明这套标记是复制来的。
publisher 值得单独看一眼。有些站 publisher 指向的 Organization，name 跟页头 logo 上的品牌名不一样，说明这套标记是从别处搬过来的，或者站点改过品牌但没改标记。任何一处能对上的小东西，都比关于页上那句"我们坚持独立评测"有用。
review 和 aggregateRating：可以读，不能照着抄
Google 对评价摘要类标记有明确限制：评价必须真实存在于页面上，并且由用户或第三方产生；针对自身组织的自评在 Organization、LocalBusiness 这类类型上不被支持。所以看到别人页面挂着 aggregateRating，正确动作是回到页面上找那句评价在哪，而不是把这段标记复制进自己的模板。
这条规则顺手可以当过滤器用。一个自称评测站、首页文章挂着 aggregateRating，页面上却找不到任何一条对应的用户评价——这个站在"声明与事实一致"这件事上已经先扣分了。注意，这不代表它内容一定差，只代表它的评价标记不能当可信信号来读。如果哪天你想给自己站加评价标记，前提也是页面上真的有那几条评价，否则风险落在你这边。
BreadcrumbList：最容易被忽略的一致性检查
面包屑是最好对照的一处。标记里的 itemListElement 每一项都有 name 和 item（URL），页面上也有一条可见面包屑，两边并排一比，立刻能看出这个站的信息架构是不是真的分层：是"首页 > 分类 > 文章"，还是所有文章都直接挂在首页下面，"分类"只是标记里编出来的一层。
如果一个站的 BreadcrumbList 层级很深，可见面包屑却永远是"首页 > 文章"，那它的栏目页大概率不承载实际内容，只是给搜索引擎看的一层壳。这个判断也可以反过来用在自己站上：标记里的层级和模板渲染出来的层级不一致，是做多语言站时最常见的一类自伤。
我现在怎么记录一个案例
我会开一个纯文本笔记，一个站一段，三行：
- 页面路径加主要 @type；
- 该类型的必需属性，哪些在、哪些缺（比如 Article 缺 author，Product 缺 offers）；
- 与可见内容的对齐情况：一致、部分一致、矛盾，后面跟一句现场描述。
只记公开页面能看到的东西，不抓登录后的内容，不存别人站上的私有数据。这样记到二十个站左右，我自己模板里该带哪些属性、哪些属性必须由人手工填，基本就有答案了。
如果只是想快速看语法有没有写错，可以把 URL 丢进 Google 的 Rich Results Test，它验的是语法和资格，不验真假。真假这件事，只能靠页面和标记对着看。
这套方法看不到什么
静态源码里读不到客户端注入的 JSON-LD。有些站在 JS 运行时才插入标记，Ctrl+U 看到的是空页面，得看渲染后的 DOM。反过来，源码里有一大段标记、渲染后反而被移除的，也值得留个心。
标记齐全也不等于内容可信。一个站可以把 Organization、author、sameAs、Article 全部写对，内容依旧是拼凑的。Schema 只能回答"这个站声明自己是谁、用了哪些类型、跟哪些实体相连"，回答不了"它写的东西对不对"。这是两个判断，别混在一起。
还有一个现实的坑：CMS 插件会自动挂上默认标记，站长自己可能都不知道页面上有 Product。所以看到奇怪的 type，先别下结论说人家在装评测站，多看几个页面，看这个类型是不是跟着内容一起变。稳定出现的类型是意图，随机出现的类型往往是插件。
回到开头那句：判断一个站，别先读它的自我介绍，先读它写给机器看的那段 JSON。声明和内容之间的差值，比任何一句宣传语都诚实。
