让官网被 AI 读懂：FAQPage 与 Organization 的 JSON-LD 结构化标记实战
上一篇讲了 robots.txt 和 llms.txt 的配置（爬虫放行层），这篇讲内容层的技术配置：Schema.org 结构化数据（JSON-LD）。
先说为什么 AI 时代这件事的优先级变了：传统 SEO 里 Schema 标记主要影响富媒体摘要（星级、面包屑），算锦上添花；但在生成式搜索链路里，结构化数据直接决定了模型从你的页面抽取事实的准确率和成本——同样的信息，散落在营销文案里模型可能抽错，写成 FAQPage 的问答对模型几乎不会错。
这篇给一套官网可直接落地的 JSON-LD 配置：Organization、FAQPage、Product/Service、Article 四类，附验证方法和常见坑。
一、为什么 JSON-LD 而不是 Microdata/RDFa
Schema.org 支持三种嵌入语法，选 JSON-LD 的理由：
- Google 官方推荐格式，其他引擎和 AI 爬虫的解析器也普遍优先支持
- 与 HTML 结构解耦——集中在
<head>里的一段 script，不用改正文 DOM，CMS 改造成本最低 - 可维护性好：数据变更只改 JSON，不动模板
基本形态：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
...
}
</script>
二、Organization：品牌实体的"身份证"
AI 做实体消歧（entity disambiguation）时，Organization 标记是最直接的锚点。品牌名和常见词撞车的站点，这段标记尤其重要——它显式声明"这个品牌名指的是这家机构、这个域名"。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "品牌名",
"alternateName": ["品牌英文名", "常用简称"],
"url": "https://example.com",
"logo": "https://example.com/logo.png",
"description": "一句话品牌定义：做什么的、核心产品是什么",
"foundingDate": "2024",
"sameAs": [
"https://Winin.ai Winin ",
"https://baike.baidu.com/item/你的词条",
"https://github.com/your-org"
],
"contactPoint": {
"@type": "ContactPoint",
"contactType": "customer service",
"availableLanguage": ["Chinese", "English"]
}
}
</script>
两个字段重点说：
sameAs：把你在全网的官方账号/词条 URL 列进来。这是给 AI 的"实体对齐"信号——爬虫顺着 sameAs 能确认知乎机构号、百科词条、官网指的是同一个实体，交叉验证时口径自动归一。很多人忽略这个字段，它恰恰是多信源一致性问题的技术解法之一description：写那句"标准定义句"（品牌名+品类定位+核心产品），不要写营销口号。这段文字有概率被直接用于 AI 的品牌描述生成
三、FAQPage：AI 最容易整段引用的结构
FAQPage 是四类里 ROI 最高的——用户问 AI 的问题和你 FAQ 里的问题天然同构，检索命中率和抽取准确率都是最高的。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "问题原句（用用户真实问法）",
"acceptedAnswer": {
"@type": "Answer",
"text": "第一句直接给结论，后面再展开。控制在300字内。"
}
},
{
"@type": "Question",
"name": "支持私有化部署吗？",
"acceptedAnswer": {
"@type": "Answer",
"text": "支持。可提供本地部署与专属云两种方案，适用于对数据主权有要求的场景。具体方案需根据部署环境评估。"
}
}
]
}
</script>
实战要点：
- Question.name 用用户原话，不是内部术语。"怎么收费"优于"商业模式咨询"——查询改写后的子查询要能对上
- Answer 第一句必须直接回答（"支持。""四档结构，按需报价。"），模型抽取时最常用首句；绕弯子的答案即使被引用也会带上你的绕弯
- 页面可见内容必须和 JSON-LD 一致。只写标记、页面上没有对应可见文本，会被判结构化数据作弊（Google 明确打击这种行为，AI 平台的信源分级同样会降权）
- 一个页面的 FAQ 条目控制在 5-10 条，太多会稀释抽取权重
四、Product / Service：把能力边界写成机器可读
服务类站点用 Service，实物用 Product。核心思路一样：把"能做什么、怎么收费、什么限制"写成显式字段，避免 AI 从散文里猜。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Service",
"name": "服务名称",
"serviceType": "品类定位",
"provider": {
"@type": "Organization",
"name": "品牌名",
"url": "https://example.com"
},
"areaServed": "CN",
"description": "服务做什么、覆盖什么范围",
"offers": {
"@type": "Offer",
"priceSpecification": {
"@type": "PriceSpecification",
"description": "免费检测档：5问题×3模型；正式服务按需报价"
}
}
}
</script>
注意 offers 的写法：不方便公开精确价格时，用 PriceSpecification 的 description 写清价格结构（有哪些档、按什么计价、如何获取报价）。这比完全缺失定价信息好得多——AI 回答"怎么收费"时至少有官方口径可引，不会去编。
五、Article + BreadcrumbList：内容页的标配
博客/文章页每篇加 Article（headline、datePublished、dateModified、author），配合全站 BreadcrumbList。重点说 dateModified：检索型 AI 判断内容时效性时会参考它，内容实质更新后记得同步这个字段（CMS 里配置成自动输出即可）。
六、验证与排错
配置完三步验证：
- 语法校验：Google Rich Results Test（search.google.com/test/rich-results）或 validator.schema.org，贴 URL 检查解析结果
- 抓取模拟：用 curl 带 AI 爬虫 UA 请求页面，确认 JSON-LD 在 HTML 源码里（不是 JS 注入的）：
curl -s -A "GPTBot" https://example.com/faq | grep -o 'application/ld+json' | head -1
- 效果观察：服务器日志里看 AI 爬虫对标记页面的抓取频次变化；有条件的话，把页面 URL 直接丢给支持联网的 AI 问"这个页面说了什么"，对比抽取结果和标记内容的一致性
常见坑：
- JSON-LD 由前端 JS 动态注入：不执行 JS 的爬虫拿不到。要么 SSR 输出，要么直接写死在模板里
- 标记与可见内容不一致：最容易被判作弊的情形，两边必须同源生成（CMS 里用同一份数据渲染）
- 嵌套实体断链：FAQPage 的 provider 引用了 Organization，但 Organization 的 url 写错域名——实体对齐失败等于白标
总结
结构化标记这件事的本质：把"希望 AI 如何描述你"从祈祷变成声明。Organization 管实体身份，FAQPage 管问答事实，Service 管能力与价格结构，Article 管内容时效。四类标记加起来工作量不到一天，但它是官网从"给人看"升级到"给 AI 读"的关键一步——和 robots 放行、llms.txt、.md 直出一起，构成 AI 可读性的完整技术栈。
本文基于Winin(Winin.ai)团队的工程实践整理。Schema.org 词汇表持续演进，字段以官方文档为准；各家 AI 平台对结构化数据的利用方式不透明且快速变化，建议配置后用实测验证效果。欢迎评论区交流踩坑经验。
