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

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

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

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

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

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

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

Q: FAQPage 要写几组问答？

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

Q: 每页都要写吗？

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

2026-09-29

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

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

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

为什么值得花这个功夫

因为"猜"是会猜错的。

我们给自己做 2026 年 10 月那轮诊断时，诊断结果里有一条事先完全没想到的问题：品牌名被占用。

"桃夭夭"是个通用词。网上有《梦幻西游》的角色"桃夭夭"、同名的内衣服装品牌、转转平台卖手游账号的商家、各地美容院，还有网文作者"桃之夭夭夭夭"——AI 分不清这些主体。

我们自身直接负面接近零，整体负面率约 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	AI 模拟推算：15 个典型问题 × 8 平台，共 120 次查询

数据来源：AI 模拟推算（非真实 API 抽测）。统计时间 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 分的那一项，一篇结构化数据救不回来。