结构化数据 Schema.org 上手指南：让机器直接读懂你的网页

腾信互动 · GEO优化技巧2026-05-08约 16 分钟阅读

GEO结构化数据Schema.orgJSON-LD企业官网

分类：GEO优化技巧｜阅读时长：约 16 分钟

核心结论（先给答案）

结构化数据（Structured Data）是网页里一段专门写给机器看的"标准化说明书"：它用各搜索引擎共同认可的 Schema.org 词汇表，明确告诉爬虫和大模型"这是公司名、这是地址、这是一篇文章的作者和发布时间、这是一组问答"。同样的网页内容，加不加结构化数据，机器理解的准确度差距很大。

对企业 GEO 来说，结构化数据不是为了某个花哨的搜索展示位，而是为了降低大模型识别实体、摘取事实、引用内容的成本。Google 官方明确推荐使用 JSON-LD 格式（写在页面脚本块里，不与可见文字混排），它易维护、出错少，也是目前最主流的做法。

本文给出企业官网最常用的 Organization、WebSite、Service、LocalBusiness、Article/BlogPosting、BreadcrumbList、FAQPage 七类标记的可直接套用示例（所有需要替换的值都已明确标注），以及用 Google 富结果测试、Schema Markup Validator 和搜索控制台验证的完整流程。记住一条底线：标记必须与页面可见内容一致，任何"给机器看假信息"的做法都可能触发人工处置。

一、结构化数据是什么：给网页配一张"机器身份证"

人看网页，靠版式和语义就能分辨标题、地址、电话和作者；机器却没有这种直觉。一段"广州 020-xxxxxxxx"写在页面上，爬虫要猜它是客服电话、传真还是随便写的一串数字；一个人名，机器也要猜他是作者、采访对象还是公司老板。

结构化数据解决的就是这个"猜"的问题。它用一套标准化的字段（类型、属性、取值），把页面上的事实无歧义地声明出来。例如：

@type: Organization 声明"这是一个组织"；
name 字段里的值就是组织的规范名称；
address 字段下挂省、市、街道、邮编；
sameAs 字段列出这个组织在其他平台的官方主页。

这套字段所依据的词汇表叫 Schema.org。它由 Google、微软、雅虎、Yandex 等于 2011 年共同发起，是一个开放的、跨搜索引擎的标准，目前定义了 800 多种类型（从 Organization、Product 到 Event、Recipe）。需要说明的是：Schema.org 词汇表很全，但各家搜索/AI 产品实际消费的只是其中一部分子集；标记即便暂时没有对应的"富结果"展示，也不代表没有价值——它对机器理解页面和实体仍然有用。

在 GEO 语境下，结构化数据至少承担三个作用：

实体确认：把企业名称、地址、联系方式、业务范围与官网 URL 明确绑定，帮助大模型把全网碎片信息归并到同一个实体上；
降低引用成本：问答、文章、服务等结构被显式标注后，大模型更容易直接摘取成段内容；
一致性信号：规范、稳定、与可见内容一致的标记，本身是可信度的组成部分。

二、三种写法，为什么优先用 JSON-LD

Schema.org 数据可以通过三种格式放进网页，Google 对三者都支持，但有明确的推荐顺序。

格式	写法特点	维护难度	适用建议
JSON-LD（推荐）	一段 JSON 脚本块放在 HTML 的 head 或 body 中，数据与可见文字分离，可直接表达嵌套结构	低，改数据不动正文，也可由 CMS/插件统一注入	企业官网默认选择，Google 官方明确推荐
Microdata	在正文 HTML 标签上加 `itemscope`、`itemprop` 等属性，数据与文字交织	较高，改版容易破坏	老站遗留可用，不必专门迁回
RDFa	类似 Microdata，用 HTML5 属性表达关联数据	较高	多见于特定 CMS 模板

JSON-LD 的全称是 JavaScript Object Notation for Linked Data（用于关联数据的 JSON）。它长这样：一段 <script type="application/ld+json">…</script>，里面是严格的 JSON。它有几个对非技术读者很重要的特点：

集中管理：一整段声明放在一起，不用在正文各处插属性，市场团队核对内容也方便；
支持嵌套：一个组织下挂地址、联系方式、子页面，层级清晰；
可动态注入：由建站系统、前端脚本或插件生成同样有效，便于规模化部署；
与展示解耦：页面改版换皮肤，只要数据段不动，机器读到的事实就不变。

Google 搜索官方文档的原话建议是：如果条件允许，优先使用 JSON-LD，因为它最容易实施和维护、最不容易出错。下面所有示例都采用 JSON-LD。

三、企业最常用的 7 类标记（含可直接改用的示例）

占位约定：以下所有示例中的"示例""example.com""xx"等都是必须替换的占位值；日期、电话、经纬度请换成真实信息；所有字段值必须与页面上访客能看到的内容一致。多门店、多作者的情况可按同一结构扩展数组。

1. Organization：企业实体的"根声明"

放在首页或"关于我们"页即可，不必每页重复。Google 官方说明 Organization 没有必填属性，但建议尽量提供能帮助理解的字段。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "示例科技有限公司",
  "alternateName": "示例科技",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "description": "一家面向制造业提供数字化咨询与系统实施的公司。",
  "foundingDate": "2015",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "天河区华夏路xx号xx大厦20层",
    "addressLocality": "广州市",
    "addressRegion": "广东省",
    "postalCode": "510620",
    "addressCountry": "CN"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+86-020-00000000",
    "contactType": "customer service",
    "areaServed": "CN",
    "availableLanguage": ["Chinese", "English"]
  },
  "sameAs": [
    "https://weibo.com/example",
    "https://www.zhihu.com/org/example",
    "https://github.com/example"
  ]
}
</script>

要点：name 用工商注册全称，alternateName 放常用简称；sameAs 只放企业自有且可验证的官方主页，它是实体归并的重要线索；logo 用可公开访问的图片地址。

2. WebSite：声明整站身份与站内搜索

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "示例科技官网",
  "url": "https://www.example.com/",
  "inLanguage": "zh-CN",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://www.example.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}
</script>

potentialAction 声明站内搜索的地址规则（只有在你的网站确实有搜索功能、且 URL 规则匹配时才填写，没有就删掉这一段）。

3. Service：把"卖什么服务"讲清楚

服务页用 Service 类型。它帮助机器理解"这家公司提供哪些服务、服务范围在哪里"。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "企业官网 AI 可见度诊断服务",
  "serviceType": "生成式引擎优化咨询",
  "description": "评估企业在主流 AI 答案中的出现情况，并给出官网语义与结构化改进建议。",
  "url": "https://www.example.com/services/geo-audit",
  "provider": {
    "@type": "Organization",
    "name": "示例科技有限公司",
    "url": "https://www.example.com/"
  },
  "areaServed": {
    "@type": "City",
    "name": "广州"
  }
}
</script>

一个页面描述多项服务时，可用数组承载多个 Service；不要把与页面无关的服务名硬塞进来。

4. LocalBusiness：有线下门店/办公地的企业

本地经营主体建议使用 LocalBusiness 或它更具体的子类型（如 ProfessionalService、Store、Restaurant）。Google 官方建议尽量选最贴切的具体子类型。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "name": "示例设计工作室（天河店）",
  "image": "https://www.example.com/images/store.jpg",
  "url": "https://www.example.com/stores/tianhe",
  "telephone": "+86-020-00000000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "体育西路xx号",
    "addressLocality": "广州市",
    "addressRegion": "广东省",
    "postalCode": "510620",
    "addressCountry": "CN"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 23.130000,
    "longitude": 113.320000
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00",
    "closes": "18:00"
  }],
  "priceRange": "￥￥"
}
</script>

NAP 一致性（Name 名称、Address 地址、Phone 电话在官网与第三方平台保持统一）在本地实体建设中尤其关键，标记里的值要和地图、行业目录、企业信息平台上的完全一致。

5. Article / BlogPosting：让文章带上作者与时间

新闻、博客、洞察文章用 Article 家族：普通文章用 Article，博客用 BlogPosting，新闻稿用 NewsArticle。不要为普通博客文章标成 NewsArticle。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "结构化数据 Schema.org 上手指南",
  "description": "用机器能读懂的方式声明企业、服务与文章信息。",
  "image": "https://www.example.com/images/cover-schema.jpg",
  "datePublished": "2026-05-08",
  "dateModified": "2026-05-08",
  "author": {
    "@type": "Person",
    "name": "张三",
    "url": "https://www.example.com/authors/zhangsan"
  },
  "publisher": {
    "@type": "Organization",
    "name": "示例科技有限公司",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.example.com/images/logo.png"
    }
  }
}
</script>

作者是多人时用数组，每位作者一个对象，不要把多个名字拼进同一个 name。dateModified 每次实质更新时同步修改，这有助于机器判断内容新鲜度。

6. BreadcrumbList：显式声明页面层级

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "首页", "item": "https://www.example.com/" },
    { "@type": "ListItem", "position": 2, "name": "服务", "item": "https://www.example.com/services/" },
    { "@type": "ListItem", "position": 3, "name": "AI 可见度诊断" }
  ]
}
</script>

面包屑标记要与页面上实际展示、实际可点击的导航一致；最后一级通常是当前页，可只写 name 不带 item。

7. FAQPage：问答内容的显式标注

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "结构化数据加了多久能看到效果？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "结构化数据帮助机器更准确地理解页面，本身不承诺排名变化；效果受抓取周期与内容质量影响，通常需要数周以上持续观察。"
      }
    },
    {
      "@type": "Question",
      "name": "同一页可以放多段 JSON-LD 吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "可以。既可以拆成多段脚本，也可以用 @graph 合并成一段，但每个实体的字段都必须与页面可见内容一致。"
      }
    }
  ]
}
</script>

政策变化务必注意：Google 自 2023 年 8 月起已将 FAQ 富结果（搜索结果里的折叠问答）限制为政府与健康类权威网站；自 2026 年 5 月 7 日起，Google 搜索已不再展示 FAQ 富结果，相关报告与测试支持随后陆续移除（据 Google 搜索官方更新日志）。但这不等于 FAQPage 标记失去意义：它仍是 Schema.org 的有效类型，其他搜索引擎和 AI 系统会解析其中明确的问答关系。所以判断标准是——页面上真有问答内容才标，为了蹭展示位而造假问答则不要做。

GEO 洞察 · 配图

四、一页放多个类型：用 @graph 合并，别互相打架

真实页面往往需要同时声明多个实体，例如一篇文章页同时有 BlogPosting、BreadcrumbList，全站页头还有 Organization。两种处理都合法：

多段脚本：页面里放多个独立 <script type="application/ld+json"> 块，彼此独立，最简单；
@graph 合并：用一个 @graph 数组把多个实体放进同一段，并可用 @id 给每个实体固定编号、用字段互相引用（如文章的 publisher 指向 Organization 的 @id），适合中大型站点做规范化管理。

非技术团队掌握三个放置原则即可：①不重复矛盾——同一事实不要在两段标记里写成不同值；②主次分明——页面主要内容对应的类型必须有（如服务页不能只有 Organization 没有 Service）；③全站与页面级分开——Organization/WebSite 这类全站级声明放首页或全站模板，文章/产品/门店标记放对应详情页。

五、上线前怎么验证：两个官方工具 + 一个监控面板

Google 官方文档推荐"两步验证"工作流，再加一个长期监控工具：

工具	验证什么	输入方式	什么时候用
Google 富结果测试（Rich Results Test）	页面标记能生成哪些 Google 富结果，报错与警告	公开 URL 或直接粘贴代码	想确认 Google 侧资格、预览效果时；支持 JS 渲染后的标记
Schema Markup Validator（validator.schema.org）	对照完整 Schema.org 词表检查语法、类型、属性、数据类型	URL 或代码片段	开发阶段、上线前自查全部类型（含 Google 不消费的类型）
Google Search Console（搜索控制台）	已验证站点的标记覆盖率、有效性、长期报错趋势	站点授权后自动统计	上线后持续监控，修复后可申请重新验证

具体操作步骤：

先贴代码验证：代码上线前，把 JSON-LD 片段粘进 Schema Markup Validator，确认无语法错误、属性名无拼写错误、嵌套结构完整；
再测富结果资格：贴进富结果测试，查看识别出的类型、报错（Error）与警告（Warning）。报错必须修，警告逐条判断是否适用；
上线后测真实 URL：两个工具都用线上 URL 再跑一遍，确认代码已随页面发布（动态注入的标记要确认渲染完成后仍可被提取）；
搜索控制台长期盯：在"网页索引/各类增强报告"里观察有效页面数、无效项变化；改版后重点复查；
留档：保存每次测试通过的截图或结果，便于改版回归对照。

两个常见的"假通过"要提醒：一是工具只验证语法与资格，不保证一定出现富结果（Google 官方明确说明富结果不保证展示）；二是 JSON-LD 标准不支持代码注释，测试工具可能忽略注释，但上线版本应删掉所有 // 或 /* */ 注释。

六、常见错误与注意事项

标记与可见内容不一致（风险最高）：页面写的是广州，标记写深圳；正文没有的服务、评价、价格却出现在 JSON-LD 里。Google 的结构化数据通用指南明确要求标记必须反映页面主要内容，误导性标记可能导致人工处置。
伪造评价与评分：AggregateRating 里编一个高分、Review 里写不存在的顾客，是重点打击对象。评价标记只适用于页面真实展示、且可核验的评价体系。
复制模板不替换占位值：把网上示例里的"example.com""张三"直接发布，等于给机器发错名片；电话、经纬度、日期尤其要逐项核对。
JSON 语法错误：最后一个字段后多逗号、漏引号、中文标点混入，整段都会失效。务必先过校验工具。
类型选择不当：博客标成 NewsArticle、普通公司标成 LocalBusiness（没有实体门店/服务地点时）、服务型企业硬套 Product。优先用最贴切的类型与子类型。
堆砌无关实体：在页面里塞满与内容无关的 Organization、Person、关键词，属于对结构化数据的滥用。
认为"标记=排名承诺"：结构化数据是理解与呈现的辅助层，不替代内容本身的专业性与可信度（E-E-A-T），更不存在"加了必上"。
忽视移动端与抓取可达性：标记所在页面若被 robots 协议拦截、需要登录、依赖未完成的 JS 渲染，机器可能读不到；先保证页面可公开访问。
多端不一致：PC 站与移动站、带 www 与不带 www 的页面标记值不统一，建议规范主域并配合 canonical 标签。

常见疑问（FAQ）

问：我们不是技术公司，市场团队自己能加结构化数据吗？
答：可以参与。内容层（公司全称、地址、电话、服务描述、问答文案）本来就应由业务与市场团队提供并核对；技术团队或建站服务商负责按模板嵌入。本文的示例可直接作为需求附件交给技术同事，落地后用两个免费官方工具自助验证。

问：网站是用建站 SaaS 或模板搭的，怎么加 JSON-LD？
答：多数主流建站系统与 CMS 都支持两种路径：一是后台自带的"结构化数据/Schema"设置项，按表单填写即可；二是在"自定义代码/页眉脚本"位置粘贴 JSON-LD。若是纯模板站且没有任何自定义入口，则需要在选型或升级时把"是否支持结构化数据"列为必要条件。

问：加了结构化数据，为什么搜索结果里没看到变化？
答：原因可能有多个：该类型本就没有对应的富结果展示；标记刚上线尚未被重新抓取；页面资格或内容质量不满足展示条件；或是该展示已被官方调整（如 FAQ 富结果 2026 年已下线）。请以"机器是否准确理解"而非"是否多了花哨样式"来衡量它的价值。

问：JSON-LD、Microdata、RDFa 要三种都加吗？
答：不需要，也不建议重复。同一事实选一种格式表达即可，企业新站统一用 JSON-LD。多种格式并存且数值不一致，反而制造矛盾信号。

问：英文资料里的 Schema 属性，中文站直接用英文字段名可以吗？
答：可以。字段名（如 name、address）是 Schema.org 标准的一部分，全球通用且不要翻译；需要中文的是字段取值（公司名、地址、服务描述等），并可用 inLanguage 标明 zh-CN。

七、从这一页开始：先做"实体声明"，再谈内容引用

对绝大多数企业官网，结构化数据的落地可以分三步走：第一步，在首页/关于我们补上 Organization 与 WebSite，完成最基础的实体声明；第二步，给服务页、门店页、文章页分别加上 Service、LocalBusiness、BlogPosting 与 BreadcrumbList；第三步，建立"更新—验证—监控"的习惯，每次改版都过一遍官方测试工具，并在搜索控制台跟踪。这套动作不复杂，却是让机器"直接读懂你"的最低成本入口。

如果你的官网搭建时间较早、模板不支持结构化数据，或你不确定当前页面的标记是否正确、是否与全网实体信息一致，可以先把问题交给专业团队评估。广州腾信互动网络有限公司长期聚焦生成式引擎优化（GEO），提供面向 AI 抓取与引用逻辑的企业官网搭建，以及针对已有官网的 GEO 语义优化升级（含结构化数据体系设计与校验）。想先弄清"机器眼里的我们准不准、全不全"，可以从一次 AI 可见度诊断开始。

参考资料

Schema.org 官方词汇表（2011 年由 Google、微软、雅虎、Yandex 等共同发起）：https://schema.org/
Google Search Central, Introduction to Structured Data Markup in Google Search（推荐 JSON-LD，三种受支持格式）：https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
Google Search Central, Organization Structured Data（首页/关于我们部署建议、子类型选择）：https://developers.google.com/search/docs/appearance/structured-data/organization
Google Search Central, Article (Article, NewsArticle, BlogPosting) Structured Data：https://developers.google.com/search/docs/appearance/structured-data/article
Google Search Central, FAQPage Structured Data 及官方更新日志（2023 年 8 月限制富结果资格；2026 年 5 月 7 日起停止展示 FAQ 富结果）：https://developers.google.com/search/docs/appearance/structured-data/faqpage
Google 富结果测试 Rich Results Test：https://search.google.com/test/rich-results
Schema Markup Validator（Schema.org 社区官方校验工具，2021 年接替旧版 Structured Data Testing Tool 的通用校验职能）：https://validator.schema.org/
Google Search Central, General Structured Data Guidelines / Spam Policies（标记须与可见内容一致、误导性标记可能触发人工处置）：https://developers.google.com/search/docs/appearance/structured-data/sd-policies

合规说明：文中代码示例均为示意，占位值需替换为真实信息；未使用绝对化或承诺性表述，结构化数据不保证特定排名或展示结果。

AI 可见度诊断

如果你的官网在 AI 回答里缺失、信息过时或被竞品压制，可以从一次 AI 可见度诊断开始。广州腾信互动网络有限公司提供企业官网搭建与存量官网 GEO 语义优化升级服务，覆盖内容矩阵、结构化数据、多平台分发与 AI 引用监测，服务网络覆盖 32 个行业、51 个城市。详情可访问官网 aigeo.gztxtop.cn，或拨打电话 19128291342 咨询。