30 个站点里有 22 个让 AI 猜它们是谁

研究中的 30 个首页里有 22 个完全没有声明 Organization、WebSite、Person 或 LocalBusiness 实体。这是样本的 73%，其中还包括几家模型肯定知道名字的公司——因为「知道一个名字」和「被告知哪个域名拥有它」是两个不同的问题。

30 个里有 19 个——63%——既没有实体节点，也没有 sameAs 列表。对这些页面，每个消费方都必须从可见文本推断品牌，而推断恰恰是那种悄悄出错的部分：模型可以完全了解这家公司，却仍然没把它的名字挂到你的域名上。

什么才算声明了一个实体？

一个解析成功的 JSON-LD 块，其中包含 @type 为 Organization、WebSite、Person 或 LocalBusiness。这就是全部规则，值四分。

它刻意做得很浅。扫描器会读取一个成功解析的图中任何位置出现的类型，包括嵌套的，所以文章 author 属性里的一个 Person 节点就能满足它，哪怕页面上任何地方都没有 Organization 节点。证据行会列出匹配到的类型，所以一次通过说的是它看到了什么，而不是断言存在一个品牌实体。

30 个里有多少声明了？

8 个声明了实体类型，9 个带有 sameAs，6 个两者都有，19 个两者都没有。重叠才是值得注意的地方：这两个属性经常被一起加上，而只有其中一个、没有另一个的站点，才是值得看的。

通过和失败的页面分别长什么样？

这个模式不是人们预期的那样。一些得分最高的页面有实体、没有 sameAs；一些得分较低的页面有 sameAs、没有实体。

其中两行很有启发性。Salesforce 在整个样本里得分最高，却没有 sameAs：实体节点在做识别工作，而资料链接从未被加上。Shopify 通过了 sameAs，却没有声明实体，于是那些资料指向一个页面从未命名的东西——一次没有锚点的连接。

模型实际上会拿这些标记做什么？

模型用它把一个字符串解析成唯一一个东西。带有 name、url 和 sameAs 的 Organization，就是那种形状：它说明「这个名字、这个域名、这些资料是同一个实体」。

没有它，一个正在解析你品牌的消费方只能使用页面文本和它已经相信的东西。那并不是什么都没有——一份把公司名写得明明白白的大文档并不是隐形的——但那是推断，而推断有声明所没有的失效模式：认错同名者、缩写名、品牌更名，或者一个知道公司却不知道域名的模型。

这就是为什么两条规则被放在不同维度里计分。实体节点是机器可读性属性：解析器能不能看到一个可以指向的东西。sameAs 列表是信任属性：这个东西有没有指向别处存在的账号。第一个关于这个页面，第二个关于你在世界中的品牌。

这项检查能证明实体是正确的吗？

不能，规则页也这么写。测试的只是存在性：没有任何东西会去抓取 sameAs 里的资料，也没有任何东西会把声明的名字和页面标题作比较。

在针对它做优化之前，值得知道这个限制。一个页面可以靠声明一个 Person 节点通过，而这个节点的名字在可见文案里根本没出现，读到两者的模型会注意到这种不一致。规则是可解析性的下限，不是身份的证书。

能同时通过两条规则的最小标记是什么？

一个 Organization 节点、一个引用它的 WebSite 节点，以及一个 sameAs 数组。把占位符替换掉；不要留着它们。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://your-domain.com/#organization",
      "name": "Your Brand Name",
      "url": "https://your-domain.com",
      "sameAs": [
        "https://github.com/your-account",
        "https://www.linkedin.com/company/your-brand"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://your-domain.com/#website",
      "url": "https://your-domain.com",
      "name": "Your Brand Name",
      "publisher": { "@id": "https://your-domain.com/#organization" }
    }
  ]
}
</script>

那段代码有两个地方是刻意的。@id 的值是真实源站上的片段，所以每个页面都可以引用同一个节点，而不必重复声明品牌。数组也没有被填充：两个真实存在的资料，比六个不存在的更有价值，因为这个属性是一个消费方可以核查的声明。

先做哪一个更值得？

实体节点，因为它被计分两次——一次直接计分，一次作为让 sameAs 有意义的锚点。

1. 把 Organization 节点加到每个页面，或者加到包裹每个页面的布局里。两种都行；一个文件更容易保持准确。
2. 用你实际维护的资料添加 sameAs。一个失效的资料是一个破损的声明，而一个模型可以反驳的声明，比一个缺失的声明代价更高。
3. 验证这个块能解析。语法错误对消费方来说和缺失标记无法区分，而对一个以为自己已经加了的读者来说，比什么都没有更糟。
4. 重跑扫描。证据行会列出匹配到的类型，所以通过是可观察的，而不是假定的。

完整走查的指南是 Schema.org JSON-LD 指南，权重背后的算术在 方法论页面上。