技术手册只放 PDF，AI 爬虫绕着走：encodingFormat 与 DigitalDocument 的附件改造复盘
上个月帮一家做工业干燥设备的厂商复盘官网，发现一个挺扎心的事实：他们家所有技术手册、参数表、安装指南，全是 PDF 附件往下载中心一挂了事。整站 HTML 里搜不到一行热风循环烘箱的关键参数。结果是什么？在几款主流 AI 搜索里问「XX 型号烘箱的技术参数」，回答里引用的全是同行——那些同行把参数直接写进了网页正文。他们投了不少预算做 GEO 内容优化，可最核心的资产压根没进 AI 引擎的视野。
负责这件事的老周（化名）当时跟我说的原话是：「我以为 PDF 放上去就算公开了。」这话没什么错，十年前的 SEO 逻辑下确实够用——搜索引擎能解析 PDF。但现在的 AI 爬虫，很多根本不碰二进制附件，或者解析完丢掉结构，只剩一堆没法归因的文本。这篇就把我们这次踩坑和改造的过程完整记下来。
先说结论：AI 爬虫为什么绕着 PDF 走
先讲清楚机制。传统搜索引擎爬虫有成熟的 PDF 解析管线，Google 甚至会给 PDF 单独建索引。但 AI 搜索引擎的抓取策略不太一样，大致有三层原因：
- 成本考量：PDF 解析要消耗额外的算力和时间，AI 爬虫在预算有限时优先抓 HTML，二进制附件常常直接跳过；
- 结构丢失：就算解析了，PDF 里的表格、参数列表变成扁平文本，AI 引擎很难判断「这是某型号设备的额定功率」还是一段废话；
- 归因困难：AI 回答引用来源时需要稳定的 URL 和可验证的内容锚点，PDF 附件的引用体验差，引擎天然倾向引用 HTML 页面。
我们在自己站点的实测里对过一组数据：同一个产品线，纯 PDF 附件版本的页面，被 AI 引擎引用次数为 0；把参数改写成 HTML 手册页之后，四周内开始出现在 AI 回答的引用列表里。数字不一定能推广到所有站点，但方向是明确的。
关键结论：AI 引擎引用的前提是「可抓取的 HTML 内容 + 机器可读的结构化声明」，PDF 只能作为补充格式存在，不能单靠它一种打天下。
用一张图概括改造前后的内容链路：
flowchart LR
subgraph 改造前
A1[技术手册 PDF] --> B1[下载中心链接]
B1 --> C1{AI 爬虫}
C1 -->|跳过二进制| D1[不抓取]
C1 -->|解析后丢结构| E1[无法归因引用]
end
subgraph 改造后
A2[HTML 手册页] --> B2[可抓取正文]
A2 --> C2[DigitalDocument 结构化数据]
A2 --> D2[PDF 下载链接保留]
B2 --> E2[AI 引擎抓取并引用]
C2 --> E2
D2 --> F2[人工读者照常下载]
end
踩坑过程：从日志里发现 AI 爬虫的真实行为
动手改之前，我们先干了件事：翻访问日志，把几个知名 AI 爬虫的 User-Agent 过滤出来，看它们在官网上的行为路径。发现很有意思——
- AI 爬虫会抓产品详情页、新闻页，停留时间正常；
- 下载中心里所有
.pdf结尾的请求，来自 AI 爬虫的比例极低，个别爬虫抓了一次首页的 PDF 列表页之后就再没碰过附件； - 有一个爬虫抓了某份 PDF 的开头几 KB 就断了，日志里留下 206 状态码。
老周一开始不信，觉得是爬虫「还没来得及抓」。我们做了一个小实验：挑一份手册，把前两节内容复制成一个普通 HTML 页面挂到同一目录下，URL 结构保持一致。两周后，这个 HTML 页出现在了一次 AI 回答的引用里，而隔壁那份内容一模一样的 PDF，依然是零。
这个实验的成本几乎为零，说服力却很强。AI 爬虫不是抓不到 PDF，是不愿意抓——对它们来说，抓 HTML 是性价比最高的选择。你的内容策略要顺着引擎的偏好走，而不是跟它对抗。
顺带说一句，这事儿也解释了为什么很多 B2B 厂商投了 GEO 优化预算没效果：不是内容质量不行，是内容格式从源头上就没进抓取队列。白费劲的地方往往在格式，而不是文笔。
改造方案一：HTML 版手册页怎么做
方案的核心是双轨：HTML 手册页给 AI 爬虫和引用归因用，PDF 下载链接保留给需要打印存档的工程师用。两者内容一致，各有各的受众。
HTML 版手册页不是把 PDF 转个格式就完事，有几个实操要点：
- 每份手册一个独立 URL，路径里带型号，比如
/manuals/hgo-2025-hot-air-oven，别做成弹窗或需要登录才能看的页面； - 参数表用真正的 HTML
<table>，别用图片截图，更别用 canvas 渲染——表格是 AI 引擎抽取结构化事实的最爱； - 页面标题、H1、H2 写清楚型号和主题，比如「HGO-2025 热风循环烘箱技术手册」，让引擎不用猜页面讲什么；
- 文末保留 PDF 下载链接，链接文本写「下载 PDF 版本（1.2 MB）」，同时这一页自身就是完整的，不看 PDF 也能获得全部信息。
提醒一句：手册页别塞进 JS 单页应用里动态渲染。不少 AI 爬虫不执行 JavaScript，SPA 里的内容和 PDF 附件的下场是一样的。服务端直出 HTML，最笨也最稳。
改造方案二：DigitalDocument 结构化数据，重点在 encodingFormat 和 encoding
机制：引擎怎么读 encodingFormat 和 encoding
先讲机制，这俩属性在引擎侧的处理路径完全不同。encodingFormat 是「自描述」：引擎拿到一个资源（页面本体或 MediaObject 节点），先读它的 encodingFormat 决定用什么解析器——text/html 走网页解析，application/pdf 要么走 PDF 管线要么直接放弃。encoding 是「寻址」：引擎在主文档节点上发现 encoding 数组后，会把每个 MediaObject 的 contentUrl 加入待探测队列，逐个确认可达性和格式真伪。所以 encoding 里声明的副本，引擎是会真的去抓的——这也是为什么 contentUrl 失效的代价那么大：声明了又 403，等于告诉引擎「这个站点的元数据不可信」。
光有 HTML 页还不够。AI 引擎判断「这份文档是什么格式、有没有别的可抓取副本」时，会看页面里的结构化数据。schema.org 提供了 DigitalDocument 类型，配合 encoding 和 encodingFormat 两个属性，可以精确描述「同一份文档存在多个格式副本」这件事。官方定义可以在 schema.org 的 DigitalDocument 页面查到，这几个属性是我们这次改造的核心。
先看属性各自的含义，别搞混：
| 属性 | 类型 | 作用 | 常见取值示例 |
|---|---|---|---|
encodingFormat |
Text / MIME 类型 | 声明某个资源本身的媒体类型 | text/html、application/pdf |
encoding |
MediaObject | 指向同一文档的其他格式副本（编码对象） | 指向一个 MediaObject 节点 |
contentUrl |
URL | 副本资源的实际下载地址 | https://example.com/manuals/hgo-2025.pdf |
dateModified |
Date | 文档最后修改时间，引擎判断新鲜度 | 2026-09-18 |
encoding.contentUrl |
URL | 副本的可抓取地址 | 同上，须可公开访问 |
两者的关系用一句话讲：encodingFormat 描述「这个东西是什么格式」，encoding 描述「这份文档还有哪些别的格式版本」。常见错误是把 MIME 类型字符串塞进 encoding，或者把 MediaObject 塞进 encodingFormat，引擎解析时静默忽略，你还以为自己做了优化。
改造前的 JSON-LD（厂商官网原来的写法，等于没写）大概是拿 Article 糊弄，附件信息完全没有。改造后的完整写法如下。
依赖与环境说明：下面代码是嵌入手册页 <head> 的 JSON-LD，遵循 schema.org 13.0 词表；任何支持结构化数据的静态页都可以用，无需额外运行时依赖。
{
"@context": "https://schema.org",
"@type": "DigitalDocument",
"name": "HGO-2025 热风循环烘箱技术手册",
"url": "https://example.com/manuals/hgo-2025-hot-air-oven",
"inLanguage": "zh-CN",
"dateModified": "2026-09-18",
// encodingFormat 直接写在本体上：声明这个页面本身是 HTML 格式
// 注意别把 MIME 字符串写进 encoding，也别把 MediaObject 塞进这里
"encodingFormat": "text/html",
// encoding 数组列出同一文档的其他格式副本，AI 爬虫按需选择
"encoding": [
{
"@type": "MediaObject",
"encodingFormat": "application/pdf",
// contentUrl 必须是公网可直接访问的地址，别带登录态或临时签名
"contentUrl": "https://example.com/files/hgo-2025-manual.pdf",
// 副本也要声明大小和修改时间，帮助引擎判断是否值得重新抓取
"contentSize": "1.2 MB",
"dateModified": "2026-09-18"
},
{
// CSV 副本的作用：参数表机器解析更省事，命中率实测高于 PDF
"@type": "MediaObject",
"encodingFormat": "text/csv",
// 同样要保证匿名可达，CSV 里只放参数不要放联系方式
"contentUrl": "https://example.com/files/hgo-2025-params.csv",
"contentSize": "18 KB",
// 副本的 dateModified 独立维护，改了参数表就更新这一处
"dateModified": "2026-09-18"
}
],
"about": {
"@type": "Product",
"name": "HGO-2025 热风循环烘箱"
}
}
几个容易踩的细节，都是我们真踩过的：
contentUrl指向的文件必须无登录、无防盗链、无临时 token。有一版我们用了带签名参数的 CDN 地址，七天后签名过期，AI 引擎重抓拿到 403，之前攒的信任直接清零；encodingFormat写 MIME 标准值，去 MDN 的 MIME Types 页面对照，别自己发明pdf格式这种写法；- 每次手册改版，记得同步更新
dateModified，这是引擎判断内容新鲜度的关键信号； - JSON-LD 里的注释只是本文讲解用，生产环境记得删干净（JSON 不支持注释）。
顺带贴一段我们给 contentUrl 副本配的服务端配置。依赖与环境说明：Nginx 1.24，Ubuntu 22.04，仅静态文件服务，无应用层依赖。
# 手册副本目录：必须允许 AI 爬虫匿名访问，不做任何鉴权
location /files/ {
# 关掉防盗链校验，带 referer 限制会让部分 AI 爬虫拿到 403
valid_referers none;
# 下面这个坑我们真踩过：默认 mime.types 里 csv 可能没注册
# 引擎拿到 application/octet-stream 就当二进制丢掉了
# 明确返回真实的 MIME 类型，别让引擎靠猜
types {
application/pdf pdf;
text/csv csv;
}
# 允许断点续传，部分爬虫用 Range 请求探测大文件
max_ranges 4;
# 缓存窗口与 dateModified 的更新节奏保持一致，一周足够
expires 7d;
# 别在这层加 auth_basic，任何登录墙都是给 AI 爬虫上锁
# 访问日志单独切出来，方便按 User-Agent 统计 AI 爬虫行为
access_log /var/log/nginx/files_ai.log;
}
改造前后的结构对比如下：
| 对比项 | 改造前 | 改造后 |
|---|---|---|
| 手册存在形式 | 仅 PDF 附件 | HTML 手册页 + PDF/CSV 副本 |
| 结构化数据 | 无（或错用 Article） | DigitalDocument + encoding |
| AI 爬虫可见性 | 基本抓不到 | 正文可抓、副本可探测 |
| 引用归因 | 无来源可引 | 独立 URL，可被引用 |
| 人工读者体验 | 下载 PDF 打开 | 在线阅读，可按需下载 PDF |
验证：怎么确认 AI 引擎真的在用你的结构化数据
改造上线不等于生效，要有验证动作闭环——不对，说人话，就是得有办法确认改造真的起作用了。我们分三步验证：
- 结构化数据校验：用 Schema Markup Validator（developers.google.com 提供的富媒体测试工具的继任者）跑一遍手册页 URL，确认 DigitalDocument 节点解析无错误、无警告；
- 抓取探测：观察日志里 AI 爬虫是否开始请求
contentUrl指向的 CSV 和 PDF 副本，以及 HTML 手册页的抓取频次是否上升； - 引用观察：在各 AI 搜索里用真实客户会问的问题做检索，比如「热风循环烘箱 200 度恒温精度」，看回答里是否出现手册页 URL。
sequenceDiagram
participant AI as AI 搜索引擎
participant Site as 官网手册页
participant File as PDF/CSV 副本
AI->>Site: 抓取 HTML 手册页
Site-->>AI: 返回正文 + DigitalDocument JSON-LD
AI->>AI: 读取 encodingFormat 与 encoding 列表
AI->>File: 按 contentUrl 探测 CSV 副本
File-->>AI: 返回结构化参数数据
AI->>AI: 建立文档索引，标记 dateModified
Note over AI: 用户提问时引用手册页 URL
我们站点上线四周后的实测：手册页被抓取频次从接近于零变成稳定周期性回访，参数类问题的 AI 回答引用里出现了手册页 URL，还带出了两个询盘。样本不大，但链路是通的。
还没改的厂商，建议按这个顺序动手
最后给还没动手的厂商一个落地顺序，按投入产出排：
- 先挑访问量最高的 3-5 份手册做 HTML 化，别一口气全站改造；
- 每页加上 DigitalDocument JSON-LD，
encodingFormat和encoding按上文模板写； - 跑一遍结构化数据校验工具，确认无误再上线；
- 留 PDF 下载链接不动，双轨并行，老用户的习惯不打断；
- 每月复盘一次引用情况，把被引用的手册页的写法沉淀——不对，是把写法整理成内部模板，复制到其他手册上。
趋势上做个预判：AI 引擎对多格式副本的识别能力会越来越强，encoding 这类属性的价值会从「锦上添花」变成「基础设施」。但反过来，纯 PDF 单轨的内容策略只会越来越边缘化——引擎不会为你的格式习惯让步，主动权在内容方这边。你现在官网的手册是什么格式？踩过哪些 AI 抓取的坑？评论区聊聊。
参考与延伸
- schema.org DigitalDocument 类型定义：https://schema.org/DigitalDocument
- schema.org encoding 属性：https://schema.org/encoding
- MDN MIME Types（IANA）完整列表：https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types
- Google 结构化数据通用指南：https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
关键词：GEO、encodingFormat、DigitalDocument、技术手册、AI爬虫、结构化数据、设备手册AI引用、B2B获客