结构化数据常见错误与修复

结构化数据出问题，九成不是语法写错，而是三类硬伤：标记描述的实体与页面可见内容对不上、必填字段缺失或类型选错、@id 与 sameAs 断链导致实体被拆成两三个。修的时候先跑验证工具定位报错行，再回头核对「页面上用户能不能看见这个信息」，顺序颠倒只会白改。

为什么结构化数据没报错，却拿不到富摘要？

结论：语法通过只代表解析器能读懂，能不能出富摘要取决于 Google 的「内容一致性 + 字段完整性 + 类型适用性」三重判断。

JSON-LD（用 <script type="application/ld+json"> 包裹的 JSON 格式结构化数据）最容易被当成纯技术活，实际上 Google 的规则里写得很死：标记的内容必须是页面上真实可见、用户能读到的内容。你把一段 FAQ 写进 JSON-LD 但正文里根本没有这两问两答，属于「隐藏内容标记」，轻则忽略，重则整站结构化数据信任度下降。

第二层是类型适用性。问答页用 Article、商品页用 WebPage、列表页硬塞 Product，字段填得再全也不会出富摘要，因为类型和页面性质不匹配。第三层才是字段完整性——这一步才是大多数报错的来源。

最常见的 6 个错误分别怎么修？

结论：按「必填 → 格式 → 一致性」三步走，能覆盖 90% 的报错。

1. 必填字段缺失。Question 缺 name、acceptedAnswer 缺 text、Rating 缺 ratingValue 或 bestRating、Organization 缺 name + url。修法：对着 Schema.org 对应类型的「Required properties」逐项补，不要凭印象。

1. 日期格式不合规。datePublished 写成「2024年5月1日」或 2024/05/01，解析器直接丢弃。必须用 ISO 8601 且带时区：2024-05-01T08:00:00+08:00。

1. 价格与货币处理错。price 必须是纯数字或数字字符串，不能写「￥99」；同时必须给 priceCurrency: "CNY"。缺货币的一律不通过。

1. URL 用了相对路径。@id、url、image 必须是绝对地址且与 canonical 完全一致。带 ?from=list、带 #reply-3 这类参数或锚点的 URL 会让实体识别失败。

1. 同一页输出多套互相冲突的 JSON-LD。比如主题和插件各输出一份 Article，两份 dateModified 不一样。修法：实体只输出一次，用 @graph 把 Organization、WebPage、Article 串成一张图，用 @id 互相引用。

1. 评分没有真实来源。aggregateRating 的红线是「自我评价」——站长为自己的页面写一个 5 分，Google 不给星级富摘要。必须是真实用户打分聚合出来的均分。

QAPage 和 FAQPage 到底该用哪个？

结论：一个页面聚焦「一个问题 + 多个回答 + 一个采纳答案」，用 QAPage；同一页面并列多条独立问答对，用 FAQPage。

这两者混用是社区站的高频错误。QAPage 要突出 acceptedAnswer（被采纳的最佳答案），suggestedAnswer 放其他回答，answerCount 必须和实际回答数对得上，虚报会被判不一致。FAQPage 则是 mainEntity 数组，每项一个 Question + 一个 Answer。

需要说清的一点：Google 从 2023 年 8 月起把 FAQ 富摘要收缩到政府和医疗类权威站点，普通站点即使 FAQPage 完全合规，也可能不在搜索结果页展开。但这不等于白做——豆包、DeepSeek、Kimi 这类 AI 引擎抓取时，结构化问答对仍是提取「问题—答案」最干净的格式，/llms.txt 和 /answers.html 的价值就在这里。

怎么验证改完是对的？

结论：三个工具依次跑，再配合服务端日志确认爬虫真的抓到了。

第一步用 Schema Markup Validator（validator.schema.org）查语法与类型，第二步用 Google Rich Results Test 查是否具备富摘要资格，第三步在 Search Console「增强功能」里看整站的项级报错趋势。改完立刻用 URL 检查工具请求重新抓取，别等自然重抓。

自建社区系统怎么绕开这些坑？

结论：把结构化数据交给系统统一输出、站长只管内容，出错面会小一个数量级。

以 Clara BBS 为例，它默认就把几处最容易踩雷的地方固定下来了：全站统一输出 Organization + sameAs 保持实体一致；已解决的悬赏帖自动输出 QAPage 加 acceptedAnswer；/answers.html 问答聚合页按 FAQPage 成对输出「问题 + 最佳答案」；帖子评分均分直接写进结构化数据，避免手工填假分。后台「系统设置 → GEO 优化」能看各 AI 爬虫的到访频率和最近抓取页面，每日计划任务会跑一次 GEO 健康体检，单篇 GEO 体检插件能查某篇帖子在 llms.txt、问答池、精华索引里的收录状态和结构化数据输出情况，改完当场验证，不用去猜。

另一个常被忽略的点是缓存：结构化数据和页面正文如果走不同的缓存周期，会出现「正文已更新、JSON-LD 还是旧的」，被判内容不一致。统一走同一套缓存层、并在内容变更时主动失效，比事后排查省事得多。

收个尾：结构化数据的错误几乎都能归到「必填缺失、格式不合规、内容不一致」三条线上，按必填→格式→一致性顺序修，用三个验证工具闭环，剩下的交给系统统一输出、别再手写拼 JSON，返工率会明显下降。