json-ld 里到底该写谁:27 个首页,12 个说清了自己是谁

json-ld 里那段实体声明,是引擎认识你的依据。2026-08-17 读了 27 个首页:16 个带了 json-ld,12 个标了组织,2 个标了却一条 sameAs 都没给。

排名与引用4 分钟读完1511 次阅读
json-ld 里到底该写谁:27 个首页,12 个说清了自己是谁

实测 · 2026-08-17 · 30 个站 · 单次快照

样本与口径:与我们做 robots.txt、sitemap 两次调查完全相同的 30 个站。每站首页一次请求,浏览器 User-Agent,2026-08-17。3 个站拒绝了我们,分母是 27。同一次抓取供本批另外四篇用。

让 AI 说清你是谁,靠的是首页 json-ld 里那一段实体声明。27 个首页里 16 个带了 json-ld,其中 14 个把自己标成了某种组织,13 个列了 sameAs 指向自家其他阵地。对已经家喻户晓的大站来说漏一两项无所谓,对刚上线的出海站,这段声明就是引擎认识你的全部依据。

27 个首页声明了什么

有意思的不是「谁有结构化数据」——那个问题我们上一次调查答过了。是那些写了的人,到底说了自己什么。

查的是什么站数占 27 个
有任何 json-ld 块1659%
Organization 或 Corporation1244%
NewsMediaOrganization(子类型)27%
有 sameAs 列表1348%
解析失败的块00%

16 个站零解析失败,这条值得单说。结构化数据会出各种问题,但在这个量级的站上,JSON 写坏不是常见的那一种。

怎么测的

规则在抓取前写死,看到结果之后没改。

  1. 从交付的 HTML 里取出每一个 <script type="application/ld+json"> 块。
  2. 逐块解析,并递归走进 @graphmainEntityitemListElement,让嵌套节点也被计入。
  3. 收集找到的每一个 @type 值,字符串和数组两种写法都认。
  4. 另外单独在 HTML 里找 "sameAs" 这个裸字符串。

最后那条规则故意放得松,它带来的后果下面会说。

实际用到的类型就那么几个

16 个站一共只用出 11 种类型。词汇表很长,首页上用得着的很短。

@type出现次数
Organization11
WebSite11
WebPage6
SoftwareApplication4
ListItem4
BreadcrumbList2
ItemList2
NewsMediaOrganization2
Corporation / WebContent / CollectionPage各 1

Netlify 那一块最密:一个图里六种类型,首页上还挂了 BreadcrumbList。Vercel 是 16 个里最稀的——只有一个 SoftwareApplication,没有组织节点,等于把产品描述清楚了却没说是谁做的。

标了组织,却没给它任何可指的地方

sameAs 是同一个实体在别处的落脚点清单——你自己那些账号和主页。它的作用是让引擎把这一页接到它已经认识的实体上,而不是当成一个新出现的陌生名字。

有两个站声明了 Organization,却一条 sameAs 都没有。

站点声明了sameAs
wired.comOrganization, WebSite, ItemList没有
arstechnica.comOrganization, WebSite, WebPage没有

这两家都是大媒体,实体早就在引擎的知识里,漏掉的实际代价不大。换成一个没人听说过的出海站,同样的漏就是把引擎认识你的唯一依据整段删掉。这也是为什么这条对中文读者的权重和对 Wired 完全不同。

我们自己那条规则放太松了

BBC 就是那个案例。它首页那一块 json-ld 只标了 WebPage,里面没有任何组织节点,我们的 sameAs 检查却命中了——因为我们搜的是原始 HTML,不是解析后的图。那个字符串确实在,只是没有挂在我们看得到的组织上。

我们仍然按既定规则把 BBC 算进那 13 个里。看到结果之后再改规则,调查就变成辩论了。但这个 13 请当上界看。

松的另一头在类型判定上。严格只认 OrganizationCorporation,于是 The Verge 和纽约时报——两家用的是 NewsMediaOrganization,那是 Organization 的子类型——被挡在 12 之外。所以上面那张表把它们单列一行,而不是悄悄并进去。

这次说不了的事

我们不知道有没有引擎读了这些声明,更不知道读了之后做了什么。结构化数据是输入,而输出——模型会不会把你的公司说对——从一次页面抓取里看不出来。谁给你一个这方面的百分比,他测的是别的东西。

另外我们只读了首页。一个站完全可能把 Organization 写在「关于我们」页上而首页什么都没有,这个方法会把它判成裸的。

你自己的 json-ld 该写什么

四条,两条否定的比两条肯定的更要紧,因为它们是这批样本里真出现过的失败。

  • 一个 Organization 节点,带正式名称、logo,以及一个指向你自己控制的那些主页的 sameAs 数组。
  • 名字这个字符串在所有地方保持一模一样——标记里、正文里、title 里。
  • 别声明了 Organization 却不给 sameAs。那是报了个名字,又不给引擎任何核实的办法。
  • 别把 sameAs 指向你并不控制的账号。它是一句关于身份的断言,不是友情链接。

标记本身怎么写,结构化数据怎么加那篇给了四种页型的可粘 JSON-LD。上一次「有多少首页压根没有结构化数据」的普查在多数首页根本没有结构化数据里。把这件事在整站每一页上查完、而不是一页一页手动看,正是 QueryWin 要做的。

常见问题

Corporation 比 Organization 好吗?

这批里只有一个站用了它。Corporation 是子类型,更具体,同样合法。具体在准确的时候是加分,在靠猜的时候是减分。

sameAs 要把所有账号都列上吗?

不用。要列的是你控制的、且承载同一个身份的那些。短而准的清单,好过长而想当然的。

为什么有 11 个站一块 json-ld 都没有?

我们没去问它们。其中几家是开发者工具,首页大量靠前端渲染,而这个方法只看服务器交付的 HTML——所以这 11 个里可能有一些是我们看不到,不是没有。

这段声明能帮我被 AI 引用吗?

本次没测,不下结论。它可验证的作用是:把名字、logo 和一组可核实的主页放在同一个地方,而不是让引擎去猜这三样。

json-ld 里到底该写谁:27 个首页,12 个说清了自己是谁