结构化数据的价值在两处：帮搜索引擎确认页面类型，帮 AI 判断哪段是问答。做法上不需要全站铺满，三种类型就够：文章用 Article、问答用 FAQPage、机构用 Organization——但必须与可见内容一致。
最小可用组合
- 全站：Organization（公司名、logo、联系方式）
- 文章页：Article 或 BlogPosting（标题、作者、发布时间）
- 问答页：FAQPage（问题与答案成对）
- 内页：BreadcrumbList（层级路径）
四类覆盖了绝大多数场景。
三个常见错误
- 标记了页面上没有的内容。FAQ 标记里的问题和页面上显示的对不上，属于违规。
- 同一页标记多种冲突类型。一页既是 Article 又是 Product，机器无法判断。
- JSON-LD 语法错误。逗号、引号、嵌套层级出错，整块失效，而且不会报错。
第三条可以靠构建时校验解决——本项目每次构建都会解析所有 JSON-LD。
FAQ 标记的边界
问答要在页面上可见，答案长度建议八十到一百五十字。答案太长，标记会被忽略；太短，价值低。
结构化数据对 AI 的作用
它不直接决定被不被引用，但能降低误读概率：机器知道哪段是问题、哪段是答案、哪段是结论。
别做的事
不要为每个页面都加一堆类型，也不要指望标记能提升排名。它解决的是「机器能否准确理解」，不是「能否排上去」。
页面类型怎么选见最易被引用的五类页面。
一段可用的 JSON-LD
{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[
{"@type":"Question","name":"新站多久能被收录？",
"acceptedAnswer":{"@type":"Answer","text":"通常三周到三个月，取决于结构与内容。"}}]}三处容易写错：mainEntity 是数组、acceptedAnswer 是对象、文本里不能有未转义的双引号。
写完在构建时解析一遍，语法错误当场暴露。
维护与复核
结构化数据会随内容变化失效：改了标题、删了问答、换了日期，标记却没跟上。
低成本做法是把校验放进构建流程——每次生成后解析一遍 JSON-LD，语法错误直接报错。语义错误（标记与页面不一致）靠人工，每季度抽查五页。