Schema.org 结构化数据（JSON-LD）实操指南：让 AI 与 Google 看懂你的网站
AI 引擎和 Google 不是「读」你的网页，而是「解析」它。一段格式正确的 JSON-LD 结构化数据，等于用机器看得懂的语言直接告诉它们：这是一家什么公司、这篇文章谁写的、这个商品多少钱、这页有哪些常见问答。少了它，AI 只能靠猜；有了它，你被正确识别与引用的概率大幅提高。这篇带你从零把常用类型实现出来、放对位置、验证无误。
结构化数据是什么？为什么用 JSON-LD
结构化数据是一段依照 Schema.org 共同词汇写成的标记，用机器可读的键值告诉搜索引擎与 AI 引擎「这页的内容代表什么」。同样一段「王小明，0912-345-678」，人看得懂这是联系人与电话，但机器需要你明确标出 name 与 telephone 才不会误判。
实现格式有三种（JSON-LD、Microdata、RDFa），但 Google 与当前主流做法都建议用 JSON-LD。原因是它把所有标记集中成一个独立的 <script> 区块，不需要缠进 HTML 标签里，最好维护、最不容易和版式相互破坏，也最容易被 AI 爬虫稳定解析。
JSON-LD 放在页面哪里？
把标记包在 <script type="application/ld+json"> 区块里，放进页面的 <head> 或 <body> 都可以被识别，惯例上放 <head>。一页可以有多个 JSON-LD 区块，也可以用一个 @graph 数组把多个实体包在一起，两种都合法。
关键原则是：结构化数据必须在服务器端就输出，存在于原始 HTML 里。多数 AI 检索爬虫不执行 JavaScript，如果你的 JSON-LD 是前端加载后才用 JS 动态插入，AI 爬虫很可能读到的是没有标记的空壳。用「查看源代码」(View Source) 而非开发者工具的 Elements 面板确认它真的在原始响应里。
Organization 与 LocalBusiness：定义你是谁
这是整站最该优先做的一块，通常放在首页。它定义你的品牌实体，是 AI 回答「这家公司是谁、可不可信」时的核心依据。有实体门店或服务区域的，用更精确的 LocalBusiness（或其子类型如 Restaurant、Store）取代 Organization，并补上地址与营业时间。
- Organization 必备字段：name（品牌名）、url（官网）、logo（标志图片网址）。
- sameAs：放上你的 Facebook、Instagram、LinkedIn、维基百科等官方链接数组。这是把分散的品牌身份「绑成同一个实体」的关键，能大幅降低 AI 认错对象的概率。
- LocalBusiness 额外加：address（用 PostalAddress 结构，拆成街道／城市／邮政编码）、telephone、openingHours、geo（经纬度）、priceRange。
- contactPoint：标出客服电话、email 与服务语言，AI 回答联系类问题时就能找到你。
Article、Product、BreadcrumbList：依页面类型选对 schema
不同页面用不同类型，原则是「这页主要在讲什么，就标什么」。博客与新闻用 Article（或 BlogPosting／NewsArticle）；商品页用 Product；任何有层级的页面都该补 BreadcrumbList。
- Article／BlogPosting：headline、author（用 Person 或 Organization，别只放纯文本）、datePublished、dateModified、image、publisher。作者与日期是 AI 判断内容新鲜度与权威度的重要信号。
- Product：name、image、description、brand、offers（内含 price、priceCurrency、availability）。若有评价再加 aggregateRating 与 review，但分数必须对应页面上真实显示的评论。
- BreadcrumbList：用 itemListElement 依序列出面包屑路径（首页 › 分类 › 本页），帮引擎理解网站结构与这页在站内的定位。
- 选型小诀窍：一页可同时有多个类型（例如一篇商品评测同时有 Article 与 Product），用 @graph 包起来即可。
FAQPage：对 GEO 最直接有用的一招
如果只想先做一个能立刻影响 AI 引用的类型，选 FAQPage。它把「问题—答案」配对成机器可读的格式，刚好对应 AI 引擎「找一段能直接当答案的内容」的提取逻辑，是投入产出比很高的一步。
做法是用 mainEntity 列出多组 Question，每组底下放一个 acceptedAnswer（Answer 类型，text 字段填答案）。铁律：标记里的问答必须是页面上用户真的看得到的内容，不能只存在于 JSON-LD 里。Google 政策明确要求 FAQ 内容要在页面可见，否则属于违规隐藏内容。
怎么验证？三个必跑的检查
写完一定要验证，因为一个拼错的字段名或少一个逗号，整段标记就可能被忽略。验证分两个层次：语法对不对、以及有没有资格触发 Rich Results。
- Schema Markup Validator（validator.schema.org）：检查 Schema.org 语法本身正不正确，适用所有类型，不限于 Google 支持的。
- Google Rich Results Test（search.google.com/test/rich-results）：贴上网址或代码，看 Google 是否认可、能否拿到复合式搜索结果，并列出错误与警告。
- Search Console 的「复合式搜索结果」报告：上线后持续监测实际被 Google 抓到的状态与错误，比一次性测试更能反映真实情况。
- 别忘了用「查看源代码」确认标记真的出现在服务器返回的 HTML，而不是只靠 JS 注入。
最常见的五个错误（尤其第一个会被当 spam）
结构化数据做错比没做更糟，轻则被忽略、重则被判定操纵。以下五个是最常踩的坑。
- 标记与正文不一致：JSON-LD 写了五星评价、页面上根本没有，或 FAQ 答案页面看不到——这会被 Google 视为 spam，可能导致整站结构化数据失去资格。标记必须忠实反映页面实际内容。
- 用错类型或字段：把产品标成 Article、把 author 填成纯字符串而非 Person/Organization、价格没附 priceCurrency 等，都会让引擎无法正确解析。
- 靠 JavaScript 动态注入：AI 爬虫与部分场景下读不到，等于白做。务必在服务器端输出。
- 实体不一致：首页叫「KKpower」、其他页叫「KK Power」、社交链接又对不上，AI 难以把它们绑成同一个品牌。固定一致的 name、url 与 sameAs。
- 过度标记与堆砌：把整页所有东西都硬塞成 schema、或重复声明同一实体，反而增加出错与被判操纵的风险。标重要的、标真实的就好。
常见问题
Q. 结构化数据一定要用 JSON-LD 吗？Microdata 可以吗？
Microdata 与 RDFa 在语法上仍合法，但 Google 与当前主流实务都建议用 JSON-LD。它把标记集中成独立的 <script> 区块，不必缠进 HTML 标签，最好维护、最不容易与版式相互破坏，也最容易被 AI 爬虫稳定解析。新做的网站直接选 JSON-LD 就对了。
Q. 加了结构化数据，Google 就一定会给我 Rich Results（星星、FAQ 展开）吗？
不保证。正确的标记只是「取得资格」，是否实际显示复合式搜索结果由 Google 算法决定，会看内容质量、是否符合政策、查询场景等。但即使没触发可视化的 Rich Results，正确的结构化数据仍能帮助搜索引擎与 AI 引擎理解与引用你的内容，价值不会白费。
Q. FAQPage 标记里的问答，页面上一定要看得到吗？
是，这是硬性规定。Google 政策要求 FAQ 的问与答必须是用户在页面上真实可见的内容；只写在 JSON-LD、页面却看不到，属于违规的隐藏内容，可能让你的结构化数据失去资格甚至影响整站。标记必须忠实对应页面实际呈现。
Q. 结构化数据写错了会不会害到我的网站？
会。最严重的是「标记与正文不一致」（例如假评价、页面看不到的 FAQ），这会被视为操纵，可能导致网站的结构化数据被取消资格。其他常见问题如用错类型、字段拼错、靠 JS 动态注入导致爬虫读不到，多半是「无效但无害」，引擎直接忽略。原则是：宁可标得少而正确，不要标得多而造假。
Q. 我该优先做哪一个 schema 类型？
先做两个。一是首页的 Organization（有门店或服务区域就用 LocalBusiness），定义你的品牌实体与联系信息；二是内容页的 FAQPage，因为它的问答格式最贴近 AI 引擎提取答案的方式，对被引用最直接有效。之后再依页面类型补上 Article、Product 与 BreadcrumbList。
Q. 怎么确认我的结构化数据真的被读到？
三步骤：先用 Schema Markup Validator（validator.schema.org）确认语法正确；再用 Google Rich Results Test 确认 Google 认可并检查能否触发复合式结果；上线后用 Search Console 的复合式搜索结果报告持续监测。最后务必用浏览器「查看源代码」确认 JSON-LD 出现在服务器返回的原始 HTML，而非仅由前端 JavaScript 注入。