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

实测 · 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 块 | 16 | 59% |
| Organization 或 Corporation | 12 | 44% |
| NewsMediaOrganization(子类型) | 2 | 7% |
| 有 sameAs 列表 | 13 | 48% |
| 解析失败的块 | 0 | 0% |
16 个站零解析失败,这条值得单说。结构化数据会出各种问题,但在这个量级的站上,JSON 写坏不是常见的那一种。
怎么测的
规则在抓取前写死,看到结果之后没改。
- 从交付的 HTML 里取出每一个
<script type="application/ld+json">块。 - 逐块解析,并递归走进
@graph、mainEntity、itemListElement,让嵌套节点也被计入。 - 收集找到的每一个
@type值,字符串和数组两种写法都认。 - 另外单独在 HTML 里找
"sameAs"这个裸字符串。
最后那条规则故意放得松,它带来的后果下面会说。
实际用到的类型就那么几个
16 个站一共只用出 11 种类型。词汇表很长,首页上用得着的很短。
| @type | 出现次数 |
|---|---|
| Organization | 11 |
| WebSite | 11 |
| WebPage | 6 |
| SoftwareApplication | 4 |
| ListItem | 4 |
| BreadcrumbList | 2 |
| ItemList | 2 |
| NewsMediaOrganization | 2 |
| Corporation / WebContent / CollectionPage | 各 1 |
Netlify 那一块最密:一个图里六种类型,首页上还挂了 BreadcrumbList。Vercel 是 16 个里最稀的——只有一个 SoftwareApplication,没有组织节点,等于把产品描述清楚了却没说是谁做的。
标了组织,却没给它任何可指的地方
sameAs 是同一个实体在别处的落脚点清单——你自己那些账号和主页。它的作用是让引擎把这一页接到它已经认识的实体上,而不是当成一个新出现的陌生名字。
有两个站声明了 Organization,却一条 sameAs 都没有。
| 站点 | 声明了 | sameAs |
|---|---|---|
| wired.com | Organization, WebSite, ItemList | 没有 |
| arstechnica.com | Organization, WebSite, WebPage | 没有 |
这两家都是大媒体,实体早就在引擎的知识里,漏掉的实际代价不大。换成一个没人听说过的出海站,同样的漏就是把引擎认识你的唯一依据整段删掉。这也是为什么这条对中文读者的权重和对 Wired 完全不同。
我们自己那条规则放太松了
BBC 就是那个案例。它首页那一块 json-ld 只标了 WebPage,里面没有任何组织节点,我们的 sameAs 检查却命中了——因为我们搜的是原始 HTML,不是解析后的图。那个字符串确实在,只是没有挂在我们看得到的组织上。
我们仍然按既定规则把 BBC 算进那 13 个里。看到结果之后再改规则,调查就变成辩论了。但这个 13 请当上界看。
松的另一头在类型判定上。严格只认 Organization 和 Corporation,于是 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 和一组可核实的主页放在同一个地方,而不是让引擎去猜这三样。



