JSON-LD 结构化数据入门：让 AI 与搜索读懂企业信息

做官网的人都遇到过这种情况：页面上写得清清楚楚的公司介绍、产品说明、常见问答，用户看着没问题，但在搜索引擎和 AI 助手里，这些信息要么被理解错，要么干脆没被用上。问题往往不在内容本身，而在内容「有没有以机器看得懂的方式说清楚」。

结构化数据就是解决这件事的。它是一段写在页面里、人看不见但机器能读的标注，用来明确告诉机器「这段内容是什么」。这篇文章面向入门，讲清结构化数据在做什么、为什么常用 JSON-LD、四类最常用的标记怎么写、常见错误有哪些，以及该怎么落地。

一、结构化数据在解决什么问题

结论先给：结构化数据的作用，是把「人看得懂的排版」翻译成「机器读得懂的字段」。

一段普通的 HTML 会告诉浏览器：「这是一个大标题，这是一段文字，这是一个列表」。但它不会告诉机器：「这段文字描述的是一个组织，这个组织的名称是某某公司，它的联系邮箱是什么」。机器只能从上下文里推测，而推测就会出错。

举个例子。页面上有一行字「广州科芃科技有限公司」，紧跟一行「人工智能应用开发」。人一看就明白这是公司名和业务方向。但机器面对同样的文本时，需要判断：这是一家公司的名字，还是某个产品的名字？「人工智能应用开发」是业务范围，还是文章的标签？在没有额外标注的情况下，这些判断都只能靠猜。

更麻烦的是，同一段文字在不同页面里的角色可能完全不同。公司名出现在首页是「站点所属组织」，出现在新闻里是「被提及的对象」，出现在招聘页是「雇主」。机器若分不清这些差别，就可能在组织答案时把信息挂错地方——把产品说成公司，或把文章作者说成公司。

结构化数据通过「键值对」的方式把这种判断前移：名称就是 name，类型就是 Organization，业务描述写进 description。机器不需要猜，直接读取即可。这也是为什么它与生成式引擎关系密切——模型在组织答案时，更愿意采信「字段明确、来源清晰」的信息，而含糊的文本则容易被忽略或误读。

理解了「填表」这层含义，也就能理解为什么结构化数据强调的是「准确」而不是「多」。填错一栏的表，比不填更麻烦；同理，标注与页面实际不符，会让机器对整份数据产生怀疑，连带影响其他本可以采信的信息。

换一个角度理解：结构化数据做的其实是「填表」。如果让一家公司填一张固定格式的表——公司名称、主营业务、联系方式——填出来的信息一定比一篇自由撰写的介绍更整齐、歧义更少。结构化数据就是把这张表搬进网页，让机器用同样的方式读取。区别只在于，这张表主要是给机器看的，而用户在页面上看到的仍然是正常的排版与文字，两者并不冲突。

二、为什么是 JSON-LD

结构化数据有多种标记格式，实践中被广泛推荐的是 JSON-LD。原因有三点。

其一，与页面结构解耦。JSON-LD 是一段独立的脚本，写在页面的 head 或 body 里，不与 HTML 标签交织。这意味着改版页面结构时，标注通常不需要跟着大改，维护成本低。

其二，便于集中维护。因为是独立的一段 JSON，可以由程序根据页面数据动态生成，也可以在模板里统一维护，不容易在改版中被破坏。对于内容量大的站点，这一点尤其重要。

其三，机器解析成本低。JSON 本身是结构化格式，解析起来比从 HTML 标签里抽取属性更直接，也更少歧义。

一个 JSON-LD 块的基本形态是用 application/ld+json 类型的脚本包裹一段 JSON，顶层用 @context 声明使用的词汇表（通常指向公开的词汇表地址），再用 @type 声明这段内容描述的是什么类型。类型决定机器用哪套规则来理解这段数据，因此写对类型是前提。

三、四类最常用的标记

对一家企业的官网来说，下面四类标记覆盖了大部分场景。它们分别回答「你是谁」「这篇是什么」「有什么问答」「在站点哪里」四个问题。

Organization：先说明「你是谁」

这是最基础、也最该优先做的一类。它描述的是「这个站点背后的组织是谁」，通常包括名称、简介、网址、标志、联系方式等。做了它，机器才有把握确认「这个网站属于哪家公司」。

它的价值在实体识别环节最明显：当同一家公司的信息散落在官网、公众号、各类平台时，一段规范的 Organization 标注能帮助机器把这些信息归并到同一个实体名下。

Article：说明「这篇文章是什么」

面向内容页。它描述文章标题、摘要、发布时间、作者等。对「行业动态」这类栏目，标注 Article 能帮助机器判断页面的时效与主题，也便于在需要时准确引用。时间字段尤其重要——涉及行业动态的内容，机器对时效敏感。

FAQPage：把问答直接交给机器

这是对生成式引擎最友好的一类。它把「问题—答案」以成对字段的形式明确标注出来，机器不必从段落里推断哪句是问题、哪句是回答。问答类内容天然适合这种结构，而生成式引擎在组织答案时也偏好这种可直接取用的形态。把常见问题整理成结构化问答，往往比把答案藏在长文里更容易被引用。

BreadcrumbList：交代页面在站点中的位置

它描述页面的层级路径，例如「首页 > 行业动态 > 某篇文章」。这既帮助用户理解自己在哪里，也帮助机器理解页面之间的关系，是站点结构清晰度的一部分。层级越清楚，机器越容易判断页面之间的从属与关联。

四、最小可用写法

下面给出四种标记的最小可用形态。示例中的字段做了简化，实际使用时按需增减，但字段名与类型要保持规范。

组织信息：

``json { "@context": "https://schema.org", "@type": "Organization", "name": "公司全称", "url": "https://example.com/", "description": "一句话说明公司是做什么的", "contactPoint": { "@type": "ContactPoint", "contactType": "customer service", "email": "contact@example.com" } } ``

文章信息：

``json { "@context": "https://schema.org", "@type": "Article", "headline": "文章标题", "description": "文章摘要", "datePublished": "2026-09-12", "author": { "@type": "Organization", "name": "公司全称" } } ``

问答信息：

``json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "问题内容", "acceptedAnswer": { "@type": "Answer", "text": "回答内容" } } ] } ``

面包屑信息：

``json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "首页", "item": "https://example.com/" }, { "@type": "ListItem", "position": 2, "name": "行业动态", "item": "https://example.com/insights.html" } ] } ``

要点是：字段真实反映页面内容，datePublished 与实际发布时间一致，item 用绝对 URL，position 从 1 递增。示例中的公司与域名都是占位内容，替换为真实信息时务必与官网口径保持一致。

五、结构化数据对 GEO 意味着什么

结论先给：结构化数据不会直接带来「被引用」，但它显著降低机器理解你的成本，从而间接提高被正确使用的概率。

在生成式引擎的链路里，机器要先「读懂」内容，才能决定用不用。标注清晰的内容，在「读懂」这一步更省力：机器不必在一段段自然语言里做归属判断。尤其当多个来源都在讲同一家公司时，谁的字段更明确、口径更一致，谁的信息就更容易被采信。

需要避免一种误解：把结构化数据当成「一次就能提升可见度」的手段。它更像是一个前提条件——做了不一定立刻见效，不做则常常持续吃亏。它和可抓取、口径统一、内容质量属于同一组基础工作，彼此配合才有意义。关于它与整体方法的关系，可以参考 GEO 生成式引擎优化服务 的说明。

六、常见错误

结构化数据「写了」不等于「写对」。下面几类错误很常见。

• 标注与可见内容不一致。页面没写的内容却标进了结构化数据，机器核对后会降低信任。原则是「标注不能多于页面实际展示的内容」。
• 类型用错。把公司信息标成 Person，或把文章标成 Product，会让机器产生错误理解，比不标更糟。
• 日期格式混乱。datePublished 等时间字段应使用清晰的日期格式，不要用含糊表述。
• 一个页面塞太多类型。把大量无关类型堆在同一页面，反而稀释了重点，机器难以判断主次。
• 用相对链接。item、url 等字段应使用完整地址，避免机器无法解析。
• 改版后标注丢失。模板更新或迁移时未同步维护，导致结构化数据突然消失，而团队往往过很久才发现。
• 同一信息多处定义且互相矛盾。例如页面里标了 A 公司，站点级标注里写的是 B 公司，机器会陷入混乱。

这些问题大多不涉及技术难度，而在于「有没有把标注当成内容的一部分来对待」。把结构化数据的维护写进发布流程，比事后逐页排查省力得多。

排查这些错误时，一个实用的做法是「假设自己是机器」：只看结构化数据这一段，能不能准确说出这家公司叫什么、做什么、这个页面讲什么、发布时间是什么。如果连人都判断不清，机器更不可能判断清楚。这个简单的自检，往往比逐条对照规范更快发现问题。

七、怎么验证与落地

结构化数据可以从三个层面验证。

1. 格式层面：用通用工具校验这段 JSON 语法是否正确，是否存在括号、逗号或拼写错误。
2. 规范层面：核对使用的类型与字段名是否符合公开词汇表的定义，避免自造字段。
3. 一致性层面：把标注内容与页面可见内容逐项比对，确认二者一致；把公司名称、描述与官网其他位置及口径表比对，确认统一。

落地时的建议是分三步：先做 Organization，把「你是谁」讲清楚；再给内容页做 Article，把时效与主题交代清楚；接着对有问答的页面补 FAQPage；BreadcrumbList 随站点结构一并处理。顺序上先解决「身份」，再解决「内容」，最后是「结构」，这样每一步都能独立验证。

页面渲染与标注如何在工程层面对齐，可参考 技术能力 与 工程与质量保障 的说明。结构化数据必须能被爬虫读到——如果页面本身是 JS 渲染的空壳，标注做得再规范也无从发挥，这两个环节要一起检查。

八、小结

结构化数据是把企业信息「翻译」给机器的一层标注。它不神秘，也不需要大改架构：一段 JSON-LD 就能让机器明确知道页面在说什么。对官网来说，优先级最高的通常是 Organization 与 Article，问答类页面再补 FAQPage，层级清晰后再加 BreadcrumbList。

真正决定效果的，不是标注写得多复杂，而是它是否准确、是否与页面一致、是否在改版中被保住。把它当成内容的一部分来维护，而不是一次性交付的配置，才能长期见效。验证也不是一次性动作：每次改版、每次新增页面类型，都应把结构化数据一并检查，纳入发布前的检查项。实施中的常见问题见 常见问题，需要进一步沟通可走 联系我们。

本文由广州科芃科技有限公司技术团队整理。我们把结构化数据视为站点基础工程的一环，与可抓取、口径统一一并处理，而不是单独当成一项「优化技巧」。