技术手册只放 PDFAI 爬虫绕着走encodingFormat 与 DigitalDocument 的附件改造复盘适用读者设备厂商官网/技术文档负责人B2B 独立站开发与内容运营想让产品手册被生成式引擎优化Generative Engine Optimization, GEO体系正常抓取引用的技术同学。上个月帮一家做工业干燥设备的厂商复盘官网发现一个挺扎心的事实他们家所有技术手册、参数表、安装指南全是 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 只能作为补充格式存在不能单靠它一种打天下。用一张图概括改造前后的内容链路改造后HTML 手册页可抓取正文DigitalDocument 结构化数据PDF 下载链接保留AI 引擎抓取并引用人工读者照常下载改造前跳过二进制解析后丢结构技术手册 PDF下载中心链接AI 爬虫不抓取无法归因引用踩坑过程从日志里发现 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别做成弹窗或需要登录才能看的页面参数表用真正的 HTMLtable别用图片截图更别用 canvas 渲染——表格是 AI 引擎抽取结构化事实的最爱页面标题、H1、H2 写清楚型号和主题比如「HGO-2025 热风循环烘箱技术手册」让引擎不用猜页面讲什么文末保留 PDF 下载链接链接文本写「下载 PDF 版本1.2 MB」同时这一页自身就是完整的不看 PDF 也能获得全部信息。提醒一句手册页别塞进 JS 单页应用里动态渲染。不少 AI 爬虫不执行 JavaScriptSPA 里的内容和 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 页面查到这几个属性是我们这次改造的核心。先看属性各自的含义别搞混属性类型作用常见取值示例encodingFormatText / MIME 类型声明某个资源本身的媒体类型text/html、application/pdfencodingMediaObject指向同一文档的其他格式副本编码对象指向一个MediaObject节点contentUrlURL副本资源的实际下载地址https://example.com/manuals/hgo-2025.pdfdateModifiedDate文档最后修改时间引擎判断新鲜度2026-09-18encoding.contentUrlURL副本的可抓取地址同上须可公开访问两者的关系用一句话讲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 副本的作用参数表机器解析更省事命中率实测高于 PDFtype: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.24Ubuntu 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 副本结构化数据无或错用 ArticleDigitalDocument encodingAI 爬虫可见性基本抓不到正文可抓、副本可探测引用归因无来源可引独立 URL可被引用人工读者体验下载 PDF 打开在线阅读可按需下载 PDF验证怎么确认 AI 引擎真的在用你的结构化数据改造上线不等于生效要有验证动作闭环——不对说人话就是得有办法确认改造真的起作用了。我们分三步验证结构化数据校验用 Schema Markup Validatordevelopers.google.com 提供的富媒体测试工具的继任者跑一遍手册页 URL确认 DigitalDocument 节点解析无错误、无警告抓取探测观察日志里 AI 爬虫是否开始请求contentUrl指向的 CSV 和 PDF 副本以及 HTML 手册页的抓取频次是否上升引用观察在各 AI 搜索里用真实客户会问的问题做检索比如「热风循环烘箱 200 度恒温精度」看回答里是否出现手册页 URL。PDF/CSV 副本官网手册页AI 搜索引擎PDF/CSV 副本官网手册页AI 搜索引擎用户提问时引用手册页 URL抓取 HTML 手册页返回正文 DigitalDocument JSON-LD读取 encodingFormat 与 encoding 列表按 contentUrl 探测 CSV 副本返回结构化参数数据建立文档索引标记 dateModified我们站点上线四周后的实测手册页被抓取频次从接近于零变成稳定周期性回访参数类问题的 AI 回答引用里出现了手册页 URL还带出了两个询盘。样本不大但链路是通的。还没改的厂商建议按这个顺序动手最后给还没动手的厂商一个落地顺序按投入产出排先挑访问量最高的 3-5 份手册做 HTML 化别一口气全站改造每页加上 DigitalDocument JSON-LDencodingFormat和encoding按上文模板写跑一遍结构化数据校验工具确认无误再上线留 PDF 下载链接不动双轨并行老用户的习惯不打断每月复盘一次引用情况把被引用的手册页的写法沉淀——不对是把写法整理成内部模板复制到其他手册上。趋势上做个预判AI 引擎对多格式副本的识别能力会越来越强encoding这类属性的价值会从「锦上添花」变成「基础设施」。但反过来纯 PDF 单轨的内容策略只会越来越边缘化——引擎不会为你的格式习惯让步主动权在内容方这边。你现在官网的手册是什么格式踩过哪些 AI 抓取的坑评论区聊聊。参考与延伸schema.org DigitalDocument 类型定义https://schema.org/DigitalDocumentschema.org encoding 属性https://schema.org/encodingMDN MIME TypesIANA完整列表https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_typesGoogle 结构化数据通用指南https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data关键词GEO、encodingFormat、DigitalDocument、技术手册、AI爬虫、结构化数据、设备手册AI引用、B2B获客/HTTP/Basics_of_HTTP/MIME_typesGoogle 结构化数据通用指南https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data关键词GEO、encodingFormat、DigitalDocument、技术手册、AI爬虫、结构化数据、设备手册AI引用、B2B获客常见问题排查改造上线后我们陆续收到一些同行反馈问题集中在三个方向副本没被抓、副本被 403、以及不确定结构化数据到底有没有生效。下面用 QA 形式逐个拆解每个都给出可落地的排查步骤。Q1为什么 AI 爬虫抓了 HTML 页但没抓 contentUrl 副本现象日志里能看到 AI 爬虫稳定回访 HTML 手册页但contentUrl指向的 PDF/CSV 副本请求数为零。排查步骤确认 JSON-LD 里encoding数组是否真的存在。最常见的原因是只写了encodingFormat忘了写encoding或者把 MIME 字符串直接塞进了encoding。用 Schema Markup Validator 跑一遍看encoding节点是否解析出 MediaObject。确认contentUrl是否在页面可访问范围内。AI 爬虫通常只探测与当前页面同域或同目录层级可达的资源。如果副本放在cdn.example.com而页面在www.example.com部分引擎会跳过跨域探测。确认副本 URL 是否在 robots.txt 或 meta robots 里被屏蔽。检查robots.txt是否误伤了/files/目录以及页面head里有没有noindex或nofollow。确认副本是否返回了正确的 MIME 类型。如果 CSV 返回application/octet-stream引擎会当二进制附件直接丢弃根本不会进入探测队列。配置示例在 Nginx 里显式声明副本目录的 MIME 类型并确认没有全局deny规则location /files/ { types { application/pdf pdf; text/csv csv; } # 确认没有 deny all也没有 auth_basic allow all; }Q2如果 PDF 副本被 403如何快速定位是防盗链还是签名过期现象日志里 AI 爬虫请求contentUrl返回 403但人工浏览器打开正常。排查步骤先看 403 的响应头。用curl -I模拟不带 Referer 的请求对比带 Referer 的请求# 不带 Referer模拟 AI 爬虫curl-I-HUser-Agent: GPTBothttps://example.com/files/hgo-2025-manual.pdf# 带 Referer模拟浏览器curl-I-HReferer: https://example.com/manuals/hgo-2025-hot-air-ovenhttps://example.com/files/hgo-2025-manual.pdf判断依据不带 Referer 返回 403、带 Referer 返回 200 →防盗链问题valid_referers配置过严两种请求都返回 403且 URL 里带?sign或?token→签名过期检查 CDN 签名有效期两种请求都返回 403且 URL 不带签名 → 检查 Nginx 是否有deny规则或 IP 白名单。防盗链修复在副本目录关闭 Referer 校验只对 HTML 页面保留location /files/ { # 副本目录不做防盗链AI 爬虫不带 Referer 也能访问 valid_referers none; }签名过期修复contentUrl必须指向无签名、无 token、永久有效的静态地址。如果 CDN 强制签名改用不带签名的源站地址或把签名有效期设为一年以上并纳入定期巡检。Q3如何判断自己的 JSON-LD 是否被引擎正确解析现象不确定DigitalDocument结构化数据到底有没有被 AI 引擎读到。排查步骤用 Schema Markup Validator 校验粘贴手册页 URL确认DigitalDocument节点解析无错误、无警告encoding数组里的每个 MediaObject 都完整。用 Google Rich Results Test 做二次确认虽然它主要面向富媒体但能暴露 JSON-LD 语法层面的硬伤比如 JSON 注释没删干净导致解析失败。看日志里有没有副本探测请求这是最硬的证据。如果 AI 爬虫开始请求contentUrl指向的 CSV/PDF说明引擎读到了encoding数组如果只有 HTML 页请求、没有副本请求说明结构化数据可能没被解析。用 AI 搜索做引用测试用真实客户会问的问题检索看回答里是否出现手册页 URL。出现即证明整条链路通了。代码示例一个干净的、可被正确解析的 JSON-LD 片段生产环境不要带注释{context:https://schema.org,type:DigitalDocument,name:HGO-2025 热风循环烘箱技术手册,url:https://example.com/manuals/hgo-2025-hot-air-oven,encodingFormat:text/html,encoding:[{type:MediaObject,encodingFormat:application/pdf,contentUrl:https://example.com/files/hgo-2025-manual.pdf,contentSize:1.2 MB,dateModified:2026-09-18}]}快速自查清单JSON-LD 里没有注释JSON 不支持注释会直接解析失败encodingFormat用的是标准 MIME 值不是自造词contentUrl指向的地址无登录、无防盗链、无临时签名副本文件返回的 Content-Type 与encodingFormat一致dateModified与文件实际修改时间一致。FAQ 快速问答问题简短答案改造需要多少开发工作量每份手册约 1-2 人天含 HTML 化与 JSON-LD 配置。没有技术团队的小厂商能否用 CMS 插件实现可以多数 CMS 有 SEO 插件支持注入 JSON-LD。多语言站点的手册页如何处理每语言独立 URLJSON-LD 用inLanguage标注。改造后原有 PDF 的 SEO 权重会丢失吗不会保留 PDF 链接并双轨并行即可延续权重。如何向领导汇报这次改造的 ROI用引用次数、询盘量与抓取频次前后对比数据。