3.4 让 AI 读得懂：结构化数据与 llms.txt 实操

内容、骨架、信任都齐了，最后一公里是技术：用机器的语言，把你页面上的关键要素再翻译一遍。这一节讲三件事——结构化数据、llms.txt、语义化 HTML，都是一次配置长期受益的活儿。

一、JSON-LD 结构化数据：给页面贴机器可读的标签

结构化数据是放在网页里的一段标注代码，用 Schema.org 的词表描述页面的要素——这是哪类内容、作者是谁、更新时间是什么。主流做法是 JSON-LD 格式：一段以 script 标签包裹的 JSON 代码。

以 FAQPage 类型为例，最小示例如下：

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "GEO 优化需要多长时间见效？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "GEO 优化依赖 AI 产品对页面的抓取与更新节奏，通常以周和月为观察周期，建议持续发布可引用内容并耐心监测。"
      }
    },
    {
      "@type": "Question",
      "name": "中小企业做 GEO 需要专人负责吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不需要专职人员。由现有内容或运营人员按可引用标准撰写内容、维护信任信号即可，工作量集中在起步配置阶段。"
      }
    }
  ]
}

放置位置：这段代码可以放在页面的 head 区域或 body 区域，具体以各搜索引擎的官方文档为准。两种位置都被主流爬虫识别，选一种全站统一即可。

常用类型：内容页用 Article 类型（标注标题、作者、日期），FAQ 页用 FAQPage，组织信息用 Organization（标注品牌名、官网、联系方式）——恰好对应 3.3 的信任四件套，机器读到的和页面展示的互相印证。三类常用类型的分工如下：

实操提醒：标注必须与页面真实内容一致，页面上没有的问答、虚构的日期不要写进标注里，错误标注反而损害可信度。

二、llms.txt：给 AI 一张站点导览图

llms.txt 是一个新兴的站点指引文件约定：放在网站根目录，向 AI 说明这个站点是什么、结构如何、重点内容在哪。类比一下，它之于 AI，就像导览图之于第一次进博物馆的游客。

需要说明的是：各 AI 产品对 llms.txt 的支持程度不一，属于约定先行、采用跟进的状态。但它的成本几乎为零——一个文本文件，几十分钟写完，挂上没有任何损失，值得现在就做。

最小示例：

# 万象云档

> 面向中小企业的内容管理与知识库工具，帮助团队沉淀和复用业务知识。

## 重点页面

- [产品功能](https://example.com/features)：核心功能与适用场景说明
- [使用教程](https://example.com/guides)：从注册到上手的完整步骤
- [常见问题](https://example.com/faq)：高频问题与官方解答
- [更新日志](https://example.com/changelog)：版本与功能更新记录

写法要点：开头一句说清你是谁，简介块用一句话概括定位，重点页面列出 5～10 个最值得被引用的页面，链接指向真实存在的地址。

三、语义化 HTML：别让结构藏在样式里

最后是内容的载体本身。语义化 HTML 的基本要求只有两条，但很多站点都做错了：

• 一个页面一个 h1：h1 是页面主题，一个页面只能有一个，全靠 CSS 把字号调小的多个 h1 是常见错误。
• 标题层级不跳级：h1 到 h2 到 h3 逐级使用，不要从 h1 直接跳到 h4。层级是机器理解内容结构的骨架，跳级等于把目录页码打乱。

先在浏览器里按 tab 或用开发者工具检查标题层级是否规整，五分钟就能发现问题。

技术动作速查表

收尾：技术三件套一次配好

这一节的三件事没有一件是持续的体力活：JSON-LD 建好各页面类型的模板，llms.txt 写一次，语义化 HTML 在模板层面修一次。技术三件套一次配好，长期受益——它们安静地躺在页面里，替你向每一台来访的机器自我介绍。

至此，本篇四节走完：标准、骨架、信任、技术。下一篇我们进入第四篇，讲如何追踪 AI 到底有没有引用你。