企业网站 GEO 技术实践，用 JSON-LD 写清公司与服务的关系

一家企业可能有公司介绍页、多个服务页，以及不同语言的版本。给每张页面添加结构化数据时，需要先确定页面在描述哪家公司、哪项服务，随后把它们之间的关系表达清楚。

查 Schema.org 的 provider 定义，可以看到它专门描述服务提供者。这让企业服务页有了一个明确的实现起点。页面用 WebPage 描述，具体服务用 Service 描述，公司用 Organization 描述，服务再指向提供它的公司。Schema.org provider 定义

这类实现有助于机器读取明确的业务关系。Google 也要求结构化数据与读者能看见的内容一致。工程上可以减少名称混用和字段冲突，至于 AI 回答是否引用网站，仍需单独观察。Google 结构化数据通用规范

先核对页面上的业务事实

动手写 JSON-LD 前，先打开待修改的服务页，确认公司名称和服务名称。接着查看正文有没有解释服务内容，以及这家公司在服务中承担什么角色。企业自营服务可以把公司写为提供者；如果页面介绍第三方服务，provider 应当指向实际提供者，不能只因为网页归自己所有就填写自己。Schema.org 对 provider 角色的说明

服务说明应当来自页面已经公开的业务内容。若正文尚未写清服务对象和适用场景，先补页面。结构化字段无法替代读者需要的说明，也不应隐藏页面没有公开的承诺。

下面使用 example.com 和“示例公司”演示结构。公司、网址和服务说明均为教学占位内容，使用时需要全部替换并核对。

用一份图连接公司、页面和服务

JSON-LD 的 @id 可以给一个节点指定标识，其他节点通过这个标识引用它；@graph 可以组织多个节点。企业网站可以据此维护稳定的公司标识，再为具体服务和页面分别设置标识。W3C JSON-LD 1.1 标准

下面是一张服务页的基础示例。它说明关系的写法，不代表满足某种 Google 富媒体搜索结果的全部要求。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "示例公司",
      "url": "https://example.com/"
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/services/ai-visibility/#webpage",
      "url": "https://example.com/services/ai-visibility/",
      "name": "企业网站 AI 可见性分析",
      "mainEntity": {
        "@id": "https://example.com/services/ai-visibility/#service"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/ai-visibility/#service",
      "name": "企业网站 AI 可见性分析",
      "url": "https://example.com/services/ai-visibility/",
      "description": "分析企业官网的业务表达与 AI 搜索呈现，提供具体页面的修改建议。",
      "provider": {
        "@id": "https://example.com/#organization"
      }
    }
  ]
}
</script>

这里的 mainEntity 指向页面主要描述的服务，provider 指向服务提供者。publisher 说明页面由哪家公司发布。三个节点各有自己的类型和标识，页面与服务共享网址也不会让它们成为同一个对象。Schema.org mainEntity、publisher、Service

#organization、#webpage 和 #service 是本示例选择的标识命名方式，不需要为每个片段新建一个网页。公司标识应当在描述同一家公司的页面中保持一致。每张页面有自己的页面标识，服务标识则跟随实际服务身份维护，不要把所有服务页都指向同一个通用 Service 节点。

公司名称、服务介绍和 JSON-LD 最好由同一份业务数据生成。例如服务介绍更改后，页面可见正文和 description 同时更新。这样能减少后台改了文案、模板里的旧字段仍然留着的情况。

根据真实资料补充字段

基础关系稳定之后，再决定是否添加更多字段。

sameAs 的定义强调实体身份。如果一篇媒体报道只是提到公司，或者一个页面属于合作伙伴，就不能仅凭存在链接把它当成同一实体的身份页面。公司真实的官方资料页、对应的知识库条目可以逐个核对，缺少可确认的页面时直接省略。Schema.org sameAs 定义

areaServed 可以使用地点、行政区域等对象，也可以使用文本。这里应当填写服务真实覆盖的地域。页面只有中文版本，并不自动意味着服务范围覆盖整个中国；是否覆盖某个地区要从业务事实核实。Schema.org areaServed 定义

字段多并不自动更好。对企业服务页而言，先把提供者和服务内容写准，再补有依据的地域和身份资料，更容易长期维护。

验证语法、页面一致性和搜索展示

开发阶段可以把完整示例复制到 Schema.org Validator，检查类型和字段。发布到测试页面后再按网址检查，确认页面实际输出了预期的 JSON-LD，避免只验证了编辑器里的一份代码。

同时打开页面正文，逐项核对名称、服务说明和地域范围。还要检查 CMS 插件、主题和自定义代码是否同时输出结构化数据。如果它们对同一个公司使用不同名称或过期联系方式，应当统一数据来源后复查。

Google 的 Rich Results Test 用于检查它支持的富媒体搜索结果。Schema.org 的词汇范围更大，所以词汇用法正确、Google 支持某种展示、搜索结果实际出现这种展示，是需要分别确认的事情。一个基础 Service 节点不能直接当成 Google 会展示服务卡片的证明。Google 结构化数据入门与支持范围

对于 GEO，还应保留实际 AI 回答的观察记录。Google 明确说明，AI Overviews 和 AI Mode 不要求专用的 Schema.org 标记。因此，验收这次技术修改时，可以确认公司与服务关系已正确输出、正文与字段一致；引用变化则通过后续实际回答核实。Google AI 功能的技术要求

以后增加新服务页时，复用同一个公司标识，为新服务建立对应节点，并核对页面的主要对象。业务团队修改服务内容后，把结构化字段一起更新。这项维护可以进入网站日常发布检查，让公开正文和机器可读资料持续表达同一项业务。

服务正文怎样回答客户的业务问题，可以结合企业服务页写作指南一起检查。

主要参考资料

• W3C JSON-LD 1.1 标准
• Schema.org Service 类型
• Google 结构化数据通用规范

资料核对日期为 2026 年 10 月 8 日。