结构化数据Schema全清单：Article/FAQ/Product/Breadcrumb的写法
一、JSON-LD 写法总则
Google 推荐 JSON-LD 语法，不要用 Microdata 或 RDFa。写法有三条铁律。
| 规则 | 正确做法 | 错误做法 |
|---|---|---|
| 语法 | <script type=”application/ld+json”> | 用 Microdata 或 RDFa |
| 位置 | head 或 body 末尾 | JS 动态注入后再等渲染 |
| 字段值 | 与页面可见文字逐字一致 | Schema 写”999 美元”，页面写”询价” |
| 多类型 | 用 @type 数组或 mainEntityOfPage 互链 | 同一页面堆六七个不相关类型 |
为什么推荐 JSON-LD：它和 HTML 结构解耦，模板维护时不会因为改 DOM 破坏标记。Microdata 嵌在标签属性里，改一个 class 就可能连带坏掉。
另外两条容易被忽略：一是所有日期字段必须用 ISO 8601 格式，带时区偏移，比如 2026-09-21T09:00:00+08:00，不要写”2026 年 9 月”；二是 URL 字段必须可被 Google 直接抓取，不要写需要登录才能访问的后台链接。这两类问题在 Rich Results Test 里只会出警告，不会报错，容易被忽略。
二、Article：博客与白皮书页
Article 是文章页的基础标记，决定 SERP 上是否出现作者头像、发布时间、缩略图轮播。
| 字段 | 必填 | 示例值 | 说明 |
|---|---|---|---|
| @type | 是 | Article | 新闻用 NewsArticle |
| headline | 是 | 不超过 110 字符 | 和 <title> 一致 |
| author | 是 | {“@type”:”Person”,”name”:”崔立姝”} | 建议同时指向作者页 |
| datePublished | 是 | 2026-09-21T09:00:00+08:00 | ISO 8601 格式 |
| dateModified | 推荐 | 同 datePublished 或更新时间 | 翻新文章时更新 |
| image | 是 | 至少 1200×675 像素 | 影响轮播缩略图 |
| publisher | 推荐 | Organization 关联 | 含 logo 字段 |
场景示例：一篇 B2B 博客加了 Article 但 image 用了 600×300 的小图，Rich Results Test 报”image too small”。换成 1200×675 的封面图后，一周内出现在 SERP 文章轮播里。图片尺寸要求见 媒体资产治理。
author 字段不要只写公司名，要写具体作者名并指向作者页。Google 在知识面板和作者头像轮播里会读这个字段；只写”环形山”三个字，既不构成 Person，也不构成 Organization，标记会被忽略。作者页本身要在站内可访问，并在 SameAs 里挂上领英、GitHub 等外部档案。
三、FAQPage：AI 答案的主要通道
FAQPage 虽然 2023 年后在普通企业博客上不再出 SERP 富媒体，但它仍是 ChatGPT、Gemini、Google AI Overviews 读取问答的主要通道。
| 字段 | 必填 | 说明 |
|---|---|---|
| @type | 是 | FAQPage |
| mainEntity[] | 是 | Question 数组，5 至 6 个 |
| name | 是 | 问题原文，和页面 summary 一致 |
| acceptedAnswer.text | 是 | 答案纯文本，和页面可见答案一致 |
反直觉点：FAQPage 的 SERP 折叠块自 2023 年 8 月起只在权威论坛和政府站展示，普通 B2B 博客加了也不显示。但仍建议写——AI 引擎读 FAQ 的主要通道就是 mainEntity 数组。FAQ 内容方法论见 FAQ 与 People Also Ask。
红线：mainEntity 里的问答必须和页面可见 FAQ 完全一致，不得写页面上不存在的问答。Google 的 FAQ 垃圾标记手动操作就是冲这个来的。
问题和答案的长度也要注意：问题控制在 20 至 40 字，答案控制在 80 至 150 字。问题太短像关键词堆砌，太长超出 SERP 折叠块显示范围；答案太短信息密度不够，AI 不会引用，太长会被截断。
四、Product：B2B 产品页的高收益区
Product 标记决定产品卡、价格、库存状态是否出现在 SERP。B2B 半定制产品要克制。
| 字段 | 必填 | B2B 注意事项 |
|---|---|---|
| name | 是 | 产品型号全称，和 H1 一致 |
| image | 是 | 主图，至少 3 张产品图更稳 |
| description | 推荐 | 和产品页 meta description 一致 |
| brand | 推荐 | {“@type”:”Brand”,”name”:”…”} |
| offers.price | 有明确价格时 | 询价产品不要填 price |
| offers.availability | 推荐 | InStock / PreOrder，不要乱标 |
| aggregateRating | 有真实评价时 | 无真实评价写星级必触发手动操作 |
场景示例二：一个 B2B 设备厂产品页写 offers.price=5000，但页面上只写”询价”。Rich Results Test 报字段不一致警告，两周后 GSC 富媒体报告里该产品页富媒体展示次数归零。把 price 字段删掉、availability 改为 PreOrder 后，展示次数恢复。
价格字段错配是 Product 标记最常见的事故源。B2B 半定制产品页面不公开报价时，不要为了 SERP 卡片硬填价格。
五、BreadcrumbList：全站必上
BreadcrumbList 让 Google 用面包屑替代长 URL 展示在 SERP 上，是全站成本最低的 Schema。
| 字段 | 必填 | 说明 |
|---|---|---|
| @type | 是 | BreadcrumbList |
| itemListElement[] | 是 | 从首页到当前页的完整路径 |
| position | 是 | 从 1 开始递增 |
| name | 是 | 面包屑显示文字 |
| item | 推荐 | 该层级的绝对 URL |
item 字段必须用绝对 URL，不要用相对路径。层级要和页面可见面包屑一致：首页 → 栏目 → 子栏目 → 当前页，不要跳级。当前页本身也要写进 itemListElement，否则 Google 无法确认面包屑指向哪一页。
六、上线前三步验证
| 步骤 | 工具 | 时限 | 通过标准 |
|---|---|---|---|
| 逐 URL 验证 | Rich Results Test | 部署前当天 | 无错误，仅有可接受警告 |
| 上线抽查 | 线上 URL 再跑一次 | 上线当天 | 渲染结果与本地一致 |
| 富媒体报告 | Search Console | 第 7、14、30 天 | 展示次数非零，错误为 0 |
四类 Schema 是 B2B 官网的基线。Organization 和 WebSite 是全站 head 必上的另外两类，完整优先级判断见 结构化数据 Schema。多语言站还要确保 Schema 字段和 多语言数字与表格本地化 一致，货币和单位不能跨语种串味。
最后一个常见事故源是插件自动生成的重复 Schema。WordPress 站点装了 Yoast 或 Rank Math 后，插件会默认输出 Article、Organization 标记，如果你又手写一套 JSON-LD，就会出现 duplicate field 警告。上线前用 Rich Results Test 跑产品页和文章页，看到重复字段就关掉插件对应模块，保留手写那一套。
七、Schema 上线后的月度巡检
Schema 不是写完就不管了。模板改动、产品上下架、价格调整，都会让字段和页面可见内容重新错位。每月花半天做一次巡检，比事故发生后再补救要省力。
| 巡检项 | 检查方法 | 频率 | 通过标准 |
|---|---|---|---|
| GSC 富媒体报告错误 | Search Console 体验报告 | 每月 | 错误类型为 0，警告可接受 |
| 字段与可见文字一致 | 抽样 10 页 Rich Results Test | 每月 | 无字段错配警告 |
| Product 价格同步 | 对比产品页 price 字段与页面报价 | 调价后 | 询价产品不留 price 字段 |
| Breadcrumb 路径 | 抽样二级页对照面包屑 | 改版后 | 层级不跳级，item 为绝对 URL |
| 重复 Schema | 查看页面源码 ld+json 块数量 | 装新插件后 | 无插件与手写重复输出 |
巡检发现问题后不要急着全站改，先在测试环境复现，确认是模板问题还是单页问题。模板问题影响所有页面，改一次模板即可；单页问题多半是内容编辑手滑改错了价格或日期，逐页修正即可。把每月巡检结果记成一页台账，三个月后你会看出哪类错误反复出现，就把它写进内容编辑手册里，从源头减少重复事故。
最后提醒：Schema 是给搜索引擎和 AI 引擎读的，不是给访客看的。字段值必须诚实反映页面真实内容，不要为了蹭富媒体结果而虚标价格、刷评价星级。Google 的垃圾结构化数据手动操作一旦触发，恢复周期以季度计，得不偿失。
多语言站点还要注意 Schema 字段的语言一致性。英文页面的 JSON-LD 字段要用英文填，中文页面用中文填，不要中英混写。货币字段要和该语言页面展示的币种一致，面向欧洲客户的页面不要填美元。日期格式统一用 ISO 8601，不要按本地习惯写”9/21/2026″这种歧义格式。这些细节在 Rich Results Test 里不会报错，但会影响 AI 引擎抽取的准确率。
FAQ 常见问题
Article 的 headline 字段能写长一点吗？
FAQPage 的问答能比页面上多吗？
Product 页面不公开报价，offers 怎么写？
BreadcrumbList 的 item 字段用相对路径行不行？
同一页面能同时挂 Article 和 BreadcrumbList 吗？
Schema 上线后多久能看到富媒体？
写在最后
四类核心 Schema 是 B2B 官网的最小可用集：Article 给博客，FAQPage 给 AI 答案，Product 给产品页，BreadcrumbList 全站铺。写对了不一定有富媒体，写错了一定丢资格。
落地三步：本周用 Rich Results Test 审计 5 个模板页，列出缺失类型；下周把四类 JSON-LD 模板补进 head，字段值和可见文字逐字对齐；第 30 天在 Search Console 富媒体报告确认零错误。
一句可以记住的话：Schema 不是越多越好，是越准越好——字段对得上页面、数字对得上报价、问答对得上 FAQ，富媒体才有可能上门。