JSON-LD 结构化数据：校验 0 错误怎么做到

JSON-LD 是写在网页里的一段给机器看的说明，格式是 JSON，词汇来自 schema.org。它干的事很朴素：用机器能确定读懂的写法，把这一页是什么、谁写的、哪家公司发的，明明白白说一遍。

人看页面靠排版，机器看页面只能靠猜。结构化数据就是把该猜的部分直接告诉它。

它跟 SEO 的关键词堆砌是两回事：关键词是在求机器注意你，结构化数据是在帮机器确认你是谁。前者博弈，后者对账。

为什么值得花这个功夫

因为"猜"是会猜错的。

我们给自己做 2026 年 9 月那轮体检时，报告里有一条事先完全没想到的问题：品牌名被占用。

"桃夭夭"是个通用词。网上有一家同名的美容健身机构被投诉强制办卡，一家同名的服饰店被投诉货不对板；更要命的是"成都夭夭科技"——跟我们只差一个字，带着司法风险沉淀在百度百科和中国裁判文书网上。

我们自身直接负面接近零，整体负面率约 10%，但那 10% 基本都是误归因。伤害跟真负面一样。

结构化数据治不了所有误归因，但它能解决其中最关键的一环：让机器有个硬凭证，把"这一家"和"那一家"分开。

三步写好，然后才谈校验

很多人反过来做——先装插件、先看报错，再来想该写什么。顺序反了，错误永远修不完。

第一步：先定实体，而不是先定页面

这一步 90% 的人会跳过，也是最多错误的总根源。

要写的第一段不是 Article，是 Organization——把"我们是谁"钉死。至少六件：

{
  "@type": "Organization",
  "@id": "https://dto.cc/#organization",
  "name": "成都桃夭夭科技有限公司",
  "alternateName": "桃夭夭科技",
  "url": "https://dto.cc/",
  "identifier": {
    "@type": "PropertyValue",
    "name": "统一社会信用代码",
    "value": "91510112MAC848MBX2"
  }
}

这六件里，两件容易被忽略、但价值最高：

identifier 里的统一社会信用代码。 工商登记里唯一、不重复、不由自己编。公司全称可能撞名，信用代码不会。这是实体消歧最硬的一个信号。
@id。 给这个实体起一个固定身份证号，后面每一页都引用它，不重复写一遍公司信息。

为什么信用代码这条对我们格外重要：我们自己就是被同名主体拖累过的。所以我们要求每一篇内容、每一处落款，公司全称和信用代码都保持一致——每次出现，都是在给机器喂同一条实体记录。

第二步：再定这一页是什么类型

常用四种，不多写：

页面类型	用哪个	写在哪
文章、教程、案例	`Article`	所有内容页
带问答的页	`FAQPage`	文末有 FAQ 小节的页
所有页	`BreadcrumbList`	有层级导航的页
网站首页	`Organization` / `WebSite`	只在首页写一次

判断方法很简单：这一页的正文形态是什么，就用什么。 是文章就得像文章，是问答就得像问答。选错了类型，等于给机器递了一张写错名字的名片。

第三步：正文写完，再配结构化数据

顺序是这个：先有正文，再标注正文。

因为有一条硬规矩——结构化数据里说的，页面上必须能看到。 你标了 FAQPage，页面上却没有那几组问答，这叫标记与可见内容不符，校验器未必报错，但机器判你无效。

所以：正文写完再标注，不是标注完再补正文。

校验 0 错误的八条清单

这一节照着我们自己的检查表抄就可以。

1. `@context` 写对

必须是完整的 https://schema.org。写成 http://、或者漏一层写成 schema.org，都可能被判无法解析。

2. 必填字段一个不能少

Article 至少要 headline、datePublished、author、publisher。FAQPage 至少要有 mainEntity，且里面每一项都是完整的 Question + acceptedAnswer。

3. `acceptedAnswer` 不能只写一句话

它必须是 Answer 类型，不能直接填字符串：

"acceptedAnswer": { "@type": "Answer", "text": "这里写答案" }

直接写 "acceptedAnswer": "答案" —— 校验必报错。

4. 日期格式必须是 ISO 8601

2026-09-29 合格。2026年9月29日、09/29/2026 都不合格。

5. `author` 和 `publisher` 别乱填

要么写成完整的 Organization 对象，要么引用第一步定好的 @id。最忌讳填一个"小编"或者干脆空着。

6. 一页只有一个主实体

一页里塞两个 Article，机器不知道该引用哪个。多个区块用 @graph 组织，Article 只留一个。

7. JSON 语法本身别写坏

少一个逗号、多一个尾随逗号、引号用了中文全角——整段直接失效。这块没有"部分正确"，一处坏全段废。

8. 别用脚本后注入

结构化数据要直接写在 HTML 源码里。等页面打开后再用脚本插进去，一部分抓取方式根本读不到。这点跟静态化那篇是同一个道理。

事实块

指标	数值	统计时间	统计口径
AIVO 综合评分	60 分	2026-09	四维等权平均
舆情健康度	80 分	2026-09	自身负面 + 同名/近似主体误归因
整体负面率	约 10%，基本为误归因	2026-09	自建诊断系统 · 舆情分析
8 平台品牌提及率	38%	2026-09-24	15 个典型问题 × 8 平台，共 120 次查询

数据来源：桃夭夭自建诊断系统。统计时间 2026-09。结构化数据的硬标准：用 Google Rich Results Test 或 Schema Markup Validator 跑一遍，错误 0、警告尽量 0。有警告不一定失效，但每一个警告都是机器"没看懂"的地方。

常见问题

Q：装了结构化数据插件，为什么校验还一堆错？

插件只管"有没有这段代码"，不管"填的内容对不对"。八条清单里的错误，多数是内容层面的：日期格式不对、答案没包成 Answer、缺 author。校验器报的是内容问题，不是插件问题。

Q：结构化数据能让排名变好吗？

能，但别指望它单独起作用。它是"确认器"，不是"放大器"。页面上没有实质内容，标得再规范也没东西可引用。

Q：Organization 一定要写统一社会信用代码吗？

不是硬性要求，但强烈建议。公司名可能撞名，信用代码不会。你要是也遇到同名主体混淆，这一条基本是性价比最高的动作。

Q：FAQPage 要写几组问答？

我们自己的标准是 3 到 5 组，用客户的原话提问。写太多没必要，写一组也没意义。关键是这几组问答页面上得真实存在。

Q：每页都要写吗？

内容页都该写 Article。FAQPage 只在有 FAQ 的页写。Organization 只在首页写一次，其余页面用 @id 引用——别每页复制一遍公司信息，那是自找不一致。

什么时候不用做

后台系统、内部工具。 不需要被 AI 收录，标了也没人读。
页面上没有实质内容的站。 结构化数据是给内容做说明的，内容都没有，说明什么。这种情况先补内容，别碰结构化数据。
一页式展示站。 就一屏图和口号，标 Organization 就够，别硬凑 Article。
想靠堆 schema 类型提权重的。 标了十个类型但页面看不出来，属于标记与可见内容不符。这不是优化，是给自己埋雷。

还有一条边界要说清楚：结构化数据解决的是"机器认不认得出你"，解决不了"别人信不信你"。 后者得靠持续写内容、拿真实案例、让第三方愿意提你。这是我们自己在体检里被打到 44 分的那一项，一篇结构化数据救不回来。

结构化数据（JSON-LD）

发布到 dto.cc/docs 时，把下面这段放进页面 <head>。校验器跑一遍，必须 0 错误。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://dto.cc/docs/rebuild/json-ld#article",
      "headline": "JSON-LD 结构化数据：校验 0 错误怎么做到",
      "description": "JSON-LD 是写在网页里的一段给机器看的说明。本文给出三步写法、八条常见错误清单和校验 0 错误的标准。",
      "inLanguage": "zh-CN",
      "datePublished": "2026-09-29",
      "dateModified": "2026-09-29",
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://dto.cc/docs/rebuild/json-ld"
      },
      "author": { "@id": "https://dto.cc/#organization" },
      "publisher": { "@id": "https://dto.cc/#organization" }
    },
    {
      "@type": "FAQPage",
      "@id": "https://dto.cc/docs/rebuild/json-ld#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "JSON-LD 结构化数据校验通过的标准是什么？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "用 Google Rich Results Test 或 Schema Markup Validator 校验，错误必须为 0，警告尽量为 0。校验器不报错不代表一定生效，还需确认标记内容与页面可见内容一致。"
          }
        },
        {
          "@type": "Question",
          "name": "Organization 里为什么要写统一社会信用代码？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "公司名称可能与其他主体撞名，统一社会信用代码在工商登记中唯一且不可自行编造，是 AI 区分同名与近似主体最硬的标识。桃夭夭的信用代码为 91510112MAC848MBX2。"
          }
        },
        {
          "@type": "Question",
          "name": "结构化数据能让搜索排名变好吗？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "结构化数据是确认器不是放大器。它帮助机器准确理解页面，但页面本身没有实质内容时，标注再规范也没有可被引用的材料。"
          }
        }
      ]
    }
  ]
}
</script>

本文涉及的公司自身数据，统计时间 2026-09，口径为 15 个典型问题 × 8 个平台、共 120 次查询。

成都桃夭夭科技有限公司 ｜统一社会信用代码 91510112MAC848MBX2 公司主站 yyyoo.com ｜本站为 GEO 官网建设业务站

为什么值得花这个功夫​

三步写好，然后才谈校验​

第一步：先定实体，而不是先定页面​

第二步：再定这一页是什么类型​

第三步：正文写完，再配结构化数据​

校验 0 错误的八条清单​

1. @context 写对​

2. 必填字段一个不能少​

3. acceptedAnswer 不能只写一句话​

4. 日期格式必须是 ISO 8601​

5. author 和 publisher 别乱填​

6. 一页只有一个主实体​

7. JSON 语法本身别写坏​

8. 别用脚本后注入​

事实块​

常见问题​

什么时候不用做​

相关阅读​

结构化数据（JSON-LD）​