JSON-LD 是 AI 引用引擎的通过券

关于你的站点和一个 AI 答案引擎，有两个不同的问题，人们常常把它们混为一谈。第一个是引擎能否到达你的页面——这是个抓取问题，答案由 robots.txt 和你的边缘节点决定。第二个是它拿到 HTML 之后，能否判断这个页面是关于什么的——这是个解析问题，答案由结构化数据决定。你可能通过第一个而在第二个上完全失败：爬虫抓到了一个它能读取但无法理解的页面，所以它只能从渲染后的正文去推断这是产品、文章、公司还是 FAQ。一个需要猜测的引擎引用起来没那么自信，往往会引用那个把信息说清楚的竞争对手的页面。

结构化数据——具体来说是 schema.org 的 JSON-LD——就是告诉你如何把信息说清楚的方式。这和十年来驱动 Google 富结果的结构化数据是同一种东西；新的是它现在要同时充当 AI 答案引擎依赖的机器可读语义层，以便形成自信的、可引用的实体。下面来解释它是什么、那个不是"缺少 schema"的失败、哪些类型和字段真正重要，以及如何检查你自己的。

JSON-LD 是什么（以及为什么偏偏是它）

JSON-LD 是你放在页面 HTML 中的一个 <script> 块，用 schema.org 词汇来描述页面的结构化数据：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Structured Data for AI Answer Engines",
  "author": { "@type": "Organization", "name": "Merlonix" },
  "datePublished": "2026-08-24"
}
</script>

就这么简单——一个自包含的 JSON 块，用机器已经认识的词汇声明：这是一个 Article，这是它的标题、作者和发布日期。没有引擎需要从你的 <h1> 和可能解析正确也可能不正确的署名行去推断任何东西。

Schema.org 支持三种语法——JSON-LD、Microdata 和 RDFa——但应该用 JSON-LD。这是 Google 明确推荐的格式，也是 AI 引擎解析最可靠的格式，因为它是一个干净的、独立的 JSON 对象，而不是属性（itemscope、itemprop）散落在你的标记中需要解析器重新组装。Microdata 仍然"算数"，但它绝对更差：解析器需要遍历你的 DOM 来重建实体，而且当你的模板改变时任何一部分都可能损坏。如果你有选择——而且在建新站的时候你确实有选择——就输出 JSON-LD。

失败不是"缺少 Schema"，而是 Schema 太浅

每个人的第一反应是"我有没有结构化数据，有还是没有"。这是简单的 절반，这不是站点失败的地方。真正的失败是一个 schema 块存在但是很薄——技术上是有效的，所以每个"你有没有 JSON-LD？"检查器都给了绿灯，但缺少那些让实体真正可以被引用的字段。

一个没有作者和没有 datePublished 的 Article。一个有 name 但没有 description 的 Product。一个声明了 FAQPage 但没有 mainEntity 的——问题和答案本身。一个 AI 引擎看来，这些都是半成品的实体：它知道这个页面是什么类型的东西，但对它的了解不足以让它有自信地引用它。存在是地板；完整性才区分"引擎注意到你存在"和"引擎引用了你"。

还有一种比浅更糟糕的静默失败模式：格式错误的 JSON-LD 会被完全跳过。尾部逗号、未转义的引号、模板错误插值——这个块是无效的 JSON，所以引擎的解析器丢弃整个块，把你的页面当作没有任何结构化数据。它在你的 HTML 中看起来是存在的。但什么也不算。没有任何东西会暴露错误，因为一个损坏的 JSON-LD 块不是页面错误——它只是被静默忽略了。

重要的类型和字段

你不需要对所有东西都做 schema 标注；你需要的是每个页面用正确的类型，并把引用关键字段填好。对 AI 答案影响最大的类型，以及引擎在每个类型上依赖的字段：

几个对 AI 答案特别有影响力的类型：

Article（及其同类）需要 author 和 datePublished。答案引擎越来越重视时效性和出处——一篇有日期、有署名的文章比一篇没有日期的大段文字更安全地去引用。人们最常省略的两个字段恰恰是最大程度影响你会不会被引用 的两个。

FAQPage 是 AI 答案中杠杆效应最高的类型，也是最容易做错的类型。它的全部价值在于 mainEntity——Question/acceptedAnswer 对。一个寻找直接问题直接答案的答案引擎恰好得到了预先格式化好的这些东西。声明了 FAQPage 但不填充 mainEntity 相当于声明了一个空盒子。

Organization 放在你的首页，是所有其他引用都挂靠的实体。name + url（如果你们有的话再加上 logo 和 sameAs 链接）让引擎能够把"Merlonix"解析为一个具体的、规范的东西，而不是一个字符串。

让类型匹配页面——产品页用 Product、帖子用 Article、有真正问答的地方用 FAQPage、首页用 Organization + WebSite——并填好引用关键字段。这就是 90% 的价值。

位置：可抓取、可读、可理解

结构化数据是决定 AI 代理能否使用你站点的三层之一，它们按顺序排列：

爬虫能到达你吗？robots.txt 和你的边缘节点——它们的分歧比你想象的要大，因为 WAF 或"阻止 AI 爬虫"规则可能对一个你的 robots.txt 允许的爬虫返回 403。（为什么阻止 GPTBot 不会让你从 ChatGPT 中消失——答案引擎爬虫和训练爬虫是不同的 user-agent。）

它能找到你重要的页面吗？llms.txt——为代理准备的策展 Markdown 目录。

它能理解抓取到的页面吗？结构化数据——就是这篇文章。

它们是独立的，而且第一个 gates 其余：一个 WAF 正在 403 拦截爬虫的页面上的完美 JSON-LD 块什么都改变不了，因为引擎永远拿不到要解析的 HTML。理解只有在访问真正实现之后才有价值。但三者之中，结构化数据是独立积累最久的——十年来它一直在为富结果服务——所以即使抛开 AI 不谈，它也很少是白费功夫。

如何检查

"有 JSON-LD"是错误的测试。要测试存在、有效和完整：

确认块存在且可解析。查看源代码（或者 curl 页面）找到 application/ld+json。把 JSON 复制到任何 JSON 验证器中——如果它不能解析，引擎正在静默丢弃它，这是你最高优先级的修复。

检查 @type 是否与页面匹配。博客文章应该是 Article/BlogPosting，不是 WebPage。首页应该带有 Organization（通常还有 WebSite）。

检查引用关键字段已填充，根据上面的表格——一篇有 author 和 datePublished 的 Article，一个有真正 mainEntity 的 FAQPage，一个有 description 的 Product。存在但为空是常见的遗漏。

每次模板变更和重新部署后都要重新检查。JSON-LD 是由模板生成的；重构时重命名了一个字段或破坏了 JSON 是不可见的，直到有人读取源代码才发现。这正是那种带着绿灯发布、悄悄侵蚀引用量的回归。

如果你不想手动走完这四步，免费的 AI Agent-Readiness 检查器可以在你的栈外来做这件事：它抓取你的首页，找到你的 JSON-LD，报告它发现了哪些 schema.org @type，单独标记格式损坏的块（因此被跳过）和有效但缺少推荐字段的块，并与前两层一起折叠成 0–100 的分数——你的 robots.txt 是否真的让答案引擎爬虫进来，以及你是否发布了 llms.txt。它告诉你薄弱的层是访问、可读还是理解，这是唯一值得采取行动的方向。无需注册，一次查一个域名。

精简版：可抓取让你被获取；可解析让你被引用——两者之间的差距是一个存在、有效且完整的 JSON-LD 块，不只是存在。每个页面选正确的 @type，填好引擎需要用来形成自信实体的字段（文章上的 author 和 datePublished、FAQ 上的 mainEntity、产品的 description），并确保模板变更永远不会悄悄破坏 JSON。

Merlonix 持续监控这三层，就像监控 SSL、DNS 和域名到期一样：从你的基础设施外部，所以重新部署剥离了你的 JSON-LD、模板重构破坏了块、或者新的 WAF 规则 403 了答案引擎，不会悄悄侵蚀你的 AI 答案可见性——在人们注意到推荐流量下降之前几周才发现。运行免费的 agent-readiness 扫描看看一个域名今天的状况，在那里同时检查它的实时 SSL 和 DNS，并浏览其他免费工具。被答案引擎引用始于被它理解——而被理解是一个你今天下午就能修复的标记问题。