企业官网 JSON-LD 全套配置教程：Organization / Service / Article / BreadcrumbList 实战（2026）

一家企业在官网的 Organization Schema 里把 sameAs 字段留空，在 AI 搜索工具看来，这家企业等同于一个「孤立实体」——存在于官网代码里，但无法与百家号、抖音、百度百科等任何可信平台上的信息建立关联。这种配置在中国中小企业官网中占绝大多数，是 AI 问答系统不引用这些品牌的核心原因之一。

JSON-LD（JavaScript Object Notation for Linked Data）是以标准化格式将网站实体信息嵌入页面代码的机器可读标记语言，是 AI 系统在毫秒级时间内理解一家企业「是谁、做什么、服务哪里、是否可信」的核心「说明书」。企业官网至少需要配置 4 类核心 Schema：Organization（品牌实体）、Service（服务项目）、Article（内容文章）与 BreadcrumbList（导航层级）。缺少其中任何一类，AI 系统对这家企业的理解就是局部而非完整的。本文提供四类 Schema 的完整代码示例与全站部署策略。

为什么 JSON-LD 是 AIGEO 的「说明书」

JSON-LD 以机器可直接解析的结构化格式向搜索引擎和 AI 系统声明「这个网站是谁、提供什么服务、服务哪里、可信度来自哪里」，是 AI 系统跳过全文阅读直接获取核心实体信息的技术通道——没有 JSON-LD 的网站，AI 系统只能靠推断，有完整 JSON-LD 的网站，AI 系统可以在 0.2 秒内确认核心信息。

Schema.org 是 JSON-LD 结构化数据的标准规范机构，由 Google、Microsoft、Yahoo 和 Yandex 于 2011 年联合创立，目前已定义约 800 种数据类型。企业官网最高频使用的类型是：Organization（企业实体）、Service（服务产品）、Article 或 BlogPosting（内容文章）、FAQPage（问答内容）、BreadcrumbList（导航层级）。这 5 种类型合理配置后，可覆盖 AI 系统对一家中小企业官网约 90% 的理解需求。

理解 JSON-LD 配置有一条核心原则必须牢记：它是对页面已有内容的结构化声明，不是向 AI「另外告知」信息的工具。JSON-LD 中的信息必须与页面可见内容一致，否则会被 Google 和百度认定为欺骗性标记，后果是富文本摘要资格被取消，严重情况下触发手动审核。关于 AIGEO 整体框架的理解，可参阅AIGEO 落地框架专题；具体服务配置的场景对照，可参见AIGEO 服务对照页面。

Organization Schema：品牌实体的「数字身份证」

Organization Schema 向 AI 系统声明企业的基本身份，其中 sameAs 字段是最常被忽略却最关键的字段——它通过列出企业在多个可信平台的公开主页 URL，帮助 AI 系统核实品牌实体的真实性；没有 sameAs，AI 系统无法验证这家企业的社会信用，引用时会降低可信度权重，优先引用有完整实体档案的竞争者。

必填字段清单（@context、@type、@id、name、url、logo、contactPoint、address、sameAs），其中 @id 是该实体在全网的唯一标识符，推荐格式为「官网主域名 + #organization」，其他页面的 Schema 通过 @id 引用而非重复填写。

以下是适配服务类企业的完整 Organization Schema 代码示例：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.cn/#organization",
  "name": "你的公司品牌名",
  "url": "https://example.cn",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.cn/images/logo.png",
    "width": 300,
    "height": 60
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+86-1xx-xxxx-xxxx",
    "contactType": "customer service",
    "availableLanguage": "Chinese"
  },
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "你的城市",
    "addressRegion": "你的省份",
    "addressCountry": "CN"
  },
  "sameAs": [
    "https://author.baidu.com/home?app_id=你的百家号ID",
    "https://www.douyin.com/user/你的抖音ID",
    "https://www.xiaohongshu.com/user/profile/你的小红书ID",
    "https://baike.baidu.com/item/你的品牌名",
    "https://www.zhihu.com/org/你的知乎机构号"
  ]
}
</script>

关于 sameAs 字段的填写原则：每个 URL 必须是该平台上企业的真实公开主页，可以直接访问，不是首页或频道列表。平台数量建议在 3 至 8 个之间，优先填写以下平台（按权重排序）：百家号、百度百科（需提前创建词条）、知乎机构号（需注册并发布过内容）、抖音官方账号、小红书企业号。

一个实体检验方法：在百度或 Google 中搜索你的品牌名，若在右侧出现「知识面板」（信息框），说明搜索引擎已将你的品牌识别为可信实体。没有知识面板的品牌，在 sameAs 字段补充多平台链接，通常在 3 至 6 个月内会触发知识面板显示。

Service Schema：让 AI 准确理解你的服务版图

Service Schema 向 AI 系统声明企业提供什么服务、服务谁、在哪里服务、大约多少钱——这四个维度直接决定当用户在 AI 问答工具中搜索「某城市 + 某行业 + 某服务」时，你的网站是否进入候选引用范围。areaServed 字段填写的城市与用户搜索城市是否匹配，是本地化 AIGEO 的核心变量。

适用场景说明：凡是提供服务的企业（建站公司、律所、诊所、教培机构、设计工作室、会计事务所等），每一项独立服务都应配置对应的 Service Schema。电商类产品网站使用 Product Schema 而非 Service Schema；SaaS 工具类网站可以同时使用 SoftwareApplication 和 Service。

必填字段：@type（Service）、name（服务名称）、provider（关联到 Organization，使用 @id 引用）、areaServed（服务地区）、priceRange（价格区间）、description（服务描述，建议 80 至 150 字）。

多项服务的配置方式：每项服务独立一个 Service Schema 的 <script> 块，通过 provider 字段的 @id 引用关联到同一个 Organization 对象——不要在每个 Service Schema 中重复复制 Organization 的完整信息，用 @id 引用即可，节约代码体积，也避免信息不一致风险。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "律所官网定制建设",
  "provider": {
    "@id": "https://example.cn/#organization"
  },
  "serviceType": "网站建设",
  "areaServed": [
    "安徽省", "全椒县", "滁州市", "合肥市", "南京市", "全国（远程交付）"
  ],
  "priceRange": "¥5800起",
  "description": "面向律师事务所与法律顾问机构的官网定制建设服务，含执业资质展示、律师团队介绍、成功案例页与在线咨询预约功能，SEO·AIGEO 基础架构开箱即用，源码全交付，通常 2 至 3 周完成交付。",
  "url": "https://example.cn/services/law-firm-website/"
}
</script>

areaServed 字段对本地 SEO 的影响不应低估：2026 年百度对本地服务类搜索的 AI 摘要，在候选来源筛选时将 areaServed 与用户 IP 地理位置的匹配度列为优先判断条件之一。如果你服务全国但主要集中在某几个城市，建议优先把核心城市精确列入，而非只写「全国」——具体城市比泛化地区描述具有更强的地理实体匹配信号。

关于什么是 AIGEO以及 AI 搜索系统如何处理地理实体信号，可参阅云耕智库的 AIGEO 入门专题；关于SEO 友好网站的 10 个技术标准，包含更多与 Service Schema 协同的技术清单。

Article Schema：让智库文章被 AI 识别为可信内容来源

Article Schema 中 datePublished 与 dateModified 字段直接影响 AI 系统对内容时效性的判断——对于 AI 工具、搜索算法、价格数据等快速迭代的领域，缺少时间标注的文章在与有时间戳的同类内容竞争时，AI 系统会优先引用有明确发布日期的版本；这条规则在 2026 年的国内 AI 问答平台中已有清晰体现。

文章 Schema 类型选择逻辑：Article 适用于分析性、教程性的专业内容（绝大多数行业智库文章的首选）；BlogPosting 适用于带有个人视角色彩的博客文章（作者 IP 比机构 IP 更突出的场景）；NewsArticle 适用于时效性新闻报道（行业快讯类页面）。对于专业机构的内容品牌（如「云耕智库」类），推荐使用 Article，与 Organization 建立关联，体现机构背书。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "FAQPage Schema 实战：官网结构化数据配置让 AI 直接引用你的回答",
  "datePublished": "2026-07-20",
  "dateModified": "2026-07-20",
  "author": {
    "@type": "Person",
    "name": "徐勇",
    "url": "https://example.cn/pages/authors/author-name.html"
  },
  "publisher": {
    "@id": "https://example.cn/#organization"
  },
  "image": {
    "@type": "ImageObject",
    "url": "https://example.cn/images/articles/article-cover.webp",
    "width": 1200,
    "height": 630
  },
  "url": "https://example.cn/growthOps/article-slug/index.html",
  "inLanguage": "zh-CN"
}
</script>

dateModified 的维护原则：每次对文章进行实质性内容更新时（修正数据、补充新案例、更新截图），同步修改这个日期。仅修正错别字或格式不计为「实质更新」。这个字段告诉 AI 系统「这篇文章的信息在当前日期仍然有效」，是提升内容被时效性引用概率成本最低的操作，一分钟内完成。

author 字段与 E-E-A-T 的关系：Google 和越来越多的 AI 系统在判断内容可信度时会核验作者身份，通过 @type: Person 关联到可访问的作者页（包含真实履历、联系方式、已发表文章列表），比匿名发布或只写公司名的内容具有约 15% 至 25% 更高的可信度权重——这是「E-E-A-T（Experience, Expertise, Authoritativeness, Trustworthiness）」在技术层的直接体现。

BreadcrumbList Schema：导航结构的 AIGEO 信号

BreadcrumbList Schema 通过声明当前页面在网站层级中的位置，帮助 AI 系统理解这篇内容属于哪个主题领域，强化网站在该细分领域的「主题权威」信号——这对建立「AI 认为你是某领域专家」的权威度有间接但持续的累积效应，且 BreadcrumbList 是 4 类 Schema 中配置成本最低（约 10 分钟）、维护频率最低的类型。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "首页",
      "item": "https://example.cn"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "云耕智库",
      "item": "https://example.cn/blog/index.html"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "FAQPage Schema 实战",
      "item": "https://example.cn/growthOps/faqpage-schema-guide/index.html"
    }
  ]
}
</script>

BreadcrumbList 在搜索结果页（SERP）中触发「面包屑路径」展示，让用户一眼看出页面在网站中的位置，多项实验数据显示这可使有机点击率提升约 3% 至 5%。更重要的间接效果是：当网站的多篇文章通过 BreadcrumbList 都声明「属于同一个上级目录」时，搜索引擎会更清晰地识别网站的主题集群结构，这对 Hub-Spoke 内容模型的权重传递有显著的技术加速作用。

全站 Schema 部署策略与验证清单

全站 JSON-LD 部署的核心原则是「按页面功能配置对应 Schema，不要把所有类型堆在首页」——首页放 Organization 和 WebSite，服务页放 Service，文章页放 Article 和 BreadcrumbList，FAQ 汇总页放 FAQPage，每个 Schema 只声明当前页面的功能，这既提高解析效率，也避免不同页面的同类 Schema 信息相互冲突。

以下是推荐的全站 Schema 部署映射表：

页面类型	推荐 Schema 类型	核心配置重点
首页	Organization + WebSite + FAQPage（精选 5 条）	sameAs 字段必须完整，WebSite 含 SearchAction
服务页	Service + BreadcrumbList	areaServed 精确到目标城市，priceRange 不可省略
文章/智库页	Article（或 BlogPosting）+ BreadcrumbList + FAQPage（可选）	dateModified 随内容更新同步修改
FAQ 汇总页	FAQPage（30 至 50 条核心问答）	问答按主题分组，每组控制在 10 至 15 条
关于/团队页	Organization（补充信息）+ Person（创始人/作者）	补充 Organization 的 foundingDate 与 numberOfEmployees
案例页	Article + BreadcrumbList	可补充 Review Schema（需真实客户授权）

同一页面包含多个 JSON-LD 块时，技术上建议各类型分成独立的 <script type="application/ld+json"> 标签，彼此平级，不嵌套。这样做的好处是：任何一个 Schema 块出现语法错误时，不影响其他 Schema 的正常解析；验证工具的测试结果也更清晰，能精准定位哪个类型有问题。

「中小企业 JSON-LD 配置最常见的错误，不是写错字段，而是把 Organization Schema 的 sameAs 字段留空——这等于告诉 AI 系统'这家企业没有任何第三方可核实的存在'。在 AI 问答系统的实体验证逻辑中，多平台实体一致性是信任基础，不是可选的加分项。」

— 徐勇，云享耕科技创始人 · 技术与数字化运营负责人，基于 30+ 个网站 AIGEO 配置项目的归纳判断

验证工具与执行步骤（配置完成后按序执行）：

1. Google Rich Results Test（search.google.com/test/rich-results）：检测所有 Schema 类型是否被正确解析，「错误」必须修复，「警告」可选修复。
2. Schema.org Validator（validator.schema.org）：验证字段是否符合 Schema.org 规范，可发现 Google 测试工具不报告的字段问题。
3. 百度结构化数据测试（ziyuan.baidu.com → 结构化数据测试）：单独验证百度的解析结果，因为百度与 Google 对部分字段的处理存在差异。
4. 手动搜索品牌词（2 至 4 周后）：观察是否出现知识面板、富文本摘要、面包屑路径等展示效果，记录基线数据。

完成四类 Schema 的初次配置通常需要约 4 至 8 小时，之后维护成本极低——Service Schema 在服务价格变动时更新 priceRange，Article Schema 在文章内容更新时改 dateModified，Organization Schema 在新平台账号开通时追加 sameAs 链接。这是一次性投入、长期收益的技术基础设施工程。

常见问题

Q：同一页面可以放多个 JSON-LD 块吗？

A：可以，Google 和百度均支持同一页面包含多个 <script type="application/ld+json"> 标签。技术上建议各 Schema 类型分成独立标签，各自完整、平级并列，不要嵌套在同一个 JSON 对象内。独立标签的好处是：某个 Schema 块语法出错时，不影响其他类型的正常解析；验证工具的报错定位也更准确。

Q：JSON-LD 配置错误会被搜索引擎惩罚吗？

A：格式错误（JSON 语法有误）通常只导致该 Schema 被忽略，不会主动触发排名惩罚。但内容不一致（JSON-LD 声明内容与页面实际文字不同）可能被认定为「欺骗性标记」，导致富文本摘要资格取消，严重情况下触发手动审核。前者用验证工具能发现，后者需要人工定期核查。这两类问题性质不同，修复优先级也不同：内容不一致风险比语法错误更高。

Q：我的网站用 WordPress，怎么配置 JSON-LD？

A：WordPress 用 Rank Math SEO 插件（推荐，免费版已支持 Organization、Article 与 BreadcrumbList 的可视化配置界面）或 Yoast SEO Premium 版，均无需手写代码。Service Schema 目前没有通用插件直接支持，建议在服务页模板的 <head> 区域手动嵌入 <script type="application/ld+json"> 块，或委托开发人员在子主题中统一处理。

Q：Schema 字段缺失会导致被 AI 忽略吗？

A：分情况。必填字段（如 Organization 的 name 和 url）缺失会使整个 Schema 块无效，等同于未配置。可选字段（如 sameAs、priceRange）缺失不会使 Schema 失效，但会降低 AI 对该实体的理解完整度和信任度——特别是 sameAs 缺失，直接影响 AI 系统对品牌真实性的验证能力。建议遵循 Schema.org 官方文档的 required 标注：必填字段 100% 填写，推荐字段尽量填写，不要因为「没有这个数据」就跳过整个字段组。

JSON-LD 全套配置不是一蹴而就的工作，而是与网站内容同步生长的持续过程。Organization Schema 配置的 sameAs 字段，背后对应的是百家号的内容更新、知乎机构号的问答积累、百度百科词条的建立——这些线下动作是 AI 系统判断品牌可信度的外部信号，无法仅靠 JSON-LD 代码本身完成。Schema 是内部宣称，sameAs 是外部核实，两者缺一不可。

一个实用的自检方式：在豆包或 Kimi 中直接搜索「[你的品牌名]是什么公司」或「[你的城市] + [你的服务类型] + 推荐」，观察 AI 的回答是否提及你的品牌、信息是否准确。这不是严格的技术测试，但它模拟了你的目标客户在 AI 时代的真实搜索行为——能通过这个场景拿到引用，JSON-LD 配置就发挥了它应有的作用。

本文首发于云享耕科技

参考文献

Schema.org. Organization 规范 (2026).

Schema.org. Service 规范 (2026).

Google Developers. 结构化数据标记类型支持列表 (2026).

Aggarwal et al. GEO: Generative Engine Optimization. Princeton NLP Group (2023).

百度搜索资源平台. 结构化数据文档 (2026).