faqpage json-ld 必须严格符合 google 规范：根类型为 "@type": "faqpage"，仅两层结构（faqpage → mainentity → question 数组），每项含 name 和非空 acceptedanswer.text（纯文本），所有问答须聚合成单个 json-ld 块置于 head 中。
FAQPage JSON-LD 必须严格满足 Google 的结构化数据规范
Google 只在满足全部要求时才展示问答富摘要，不达标会直接忽略标记。最常见失败原因是 @type 值写错或层级嵌套错误——必须是 "@type": "FAQPage"（注意大小写和引号），且根对象不能是 WebPage 或其他类型包裹。
关键结构只有两层：FAQPage → mainEntity → 数组，每个数组项是 Question 对象，含 name（问题文本）和 acceptedAnswer（Answer 对象，含 text）。漏掉 mainEntity 或把 acceptedAnswer 写成字符串都会导致解析失败。
-
name和acceptedAnswer.text必须是纯文本（不能含 HTML 标签，即使转义也不行） - 每个
Question的acceptedAnswer必须存在且非空，不能为null或空字符串 - 整个 JSON-LD 脚本建议放在
中，避免因 DOM 渲染顺序导致解析延迟
多个 FAQ 条目要扁平展开，别用循环模板生成重复 @context
常见错误是用 JS 模板批量拼接时，给每条 FAQ 都加一遍 @context 和 @type，结果生成了多个独立的 JSON-LD 块。Google 只认一个合法的 FAQPage 实体，多块会互相冲突或仅取第一块。
正确做法是把所有问答聚合成单个 mainEntity 数组：
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "如何重置密码？",
"acceptedAnswer": {
"@type": "Answer",
"text": "进入登录页点击‘忘记密码’，按邮件提示操作即可。"
}
},
{
"@type": "Question",
"name": "支持哪些支付方式？",
"acceptedAnswer": {
"@type": "Answer",
"text": "支持支付宝、微信支付和银联在线。"
}
}
]
}
- 动态页面中，确保后端或构建时一次性输出完整数组，而非前端 for 循环多次
document.write - 如果 FAQ 来自 CMS，导出时检查是否有多余的包装字段（如外层
data或items），必须扁平到mainEntity
测试时用 Google Rich Results Test 工具，但注意它不模拟真实索引延迟
工具能即时反馈语法错误和字段缺失，但通过不代表上线就出富摘要。Google 实际索引需数小时到数天，且受页面权威性、FAQ 内容质量、用户搜索意图匹配度影响。
- 提交后检查 Search Console 的「增强功能」报告，看
FAQ类型是否有「有效但未显示」状态——这说明结构正确，但 Google 认为当前不适用 - 避免 FAQ 内容与页面主体无关（例如电商商品页堆砌通用客服问题），Google 会判定为低价值标记而降权
- 同一页面不要同时部署
FAQPage和QAPage，后者用于用户提问场景，混用可能触发冲突
移动端适配和内容更新容易被忽略
FAQ 富摘要在移动搜索结果中优先级更高，但很多人只在桌面端验证。如果页面响应式失效，JSON-LD 虽然存在，但 Google 可能因页面体验分低而抑制富摘要展示。
- 每次更新 FAQ 文本后，必须同步更新 JSON-LD 中的
name和text字段——缓存旧 JSON-LD 是最隐蔽的失效原因 - 避免用 JS 动态注入 JSON-LD（尤其依赖
DOMContentLoaded），Googlebot 渲染可能跳过执行 - 如果 FAQ 区域被 CSS
display: none或visibility: hidden隐藏，不影响 JSON-LD 解析，但长期隐藏正文与标记不一致可能被视作误导
真正卡住的点往往不是语法，而是标记内容和页面实际可见内容的同步节奏，以及 Google 对该页面是否“值得展示富摘要”的综合判断。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
