Front-End-Checklist 实战指南：审计并修复链接 PDF 超过 60 MB 的索引截断风险

导读

本指南基于 Front-End-Checklist 仓库中的 pdf-size 规则文档 及其完整版 references/rule.md，系统讲解如何审计网站中所有被链接的 PDF 文件大小，识别 Googlebot 下载截断导致的"部分索引"或"完全跳过"风险，并通过压缩、HTML 配套页面等方案彻底修复。读完本文，你将掌握一套可直接落地的 PDF 大小审计命令、字节级阈值判定标准、Ghostscript 命令行压缩参数，以及"HTML 为主、PDF 为辅"的索引策略。

该规则属于 SEO/技术类审计项，源数据位于 packages/content/rules/en/seo/pdf-size.mdx，在项目中被归为medium 优先级、intermediate 难度、约 15 分钟即可完成审计的检查项。项目已将其同时发布为可由 Agent 直接执行的技能文件（SKILL.md），适用于审计任何发布可下载 PDF（报告、白皮书、法律文书、手册）的站点。

规则核心：保持被链接的 PDF 小于 60 MB

Google 会索引 PDF，并将其直接展示在搜索结果中。但 PDF 文件过大时，下载过程中可能被截断，导致只有文件前半部分被索引，这就是"部分索引（partial indexing）"。因此，凡是作为可索引内容资源被链接的 PDF，都必须控制在 Googlebot 的下载阈值之内。

规则原文给出的核心结论是：

• Googlebot 在爬取时会对超过15 MB的文件进行截断处理；
• 60 MB是文档化的内容索引实际上限；
• 超过上限的文件会被跳过，或只索引第一个片段。

这意味着：即使 PDF 被大量高权重页面链接，只要文件过大，其中的内容依然可能完全不出现在搜索结果中——文件大小控制与 HTML 配套页面策略、爬虫友好的文档交付，属于同一类"可发现性"工作。

大小阈值速查表

审计前先建立明确的判定标准。规则提供了如下分级参考：

此外，检查指令（check）中规定了更严格的操作阈值：

• 超过10 MB（10,485,760 字节）：标记为需要压缩审查；
• 超过15 MB（15,728,640 字节）：标记为存在部分索引风险；
• 所有 PDF URL 还应验证返回200 状态码，且响应头为正确的Content-Type: application/pdf。

审计方法：用 HEAD 请求检查 Content-Length

规则给出了明确的操作路径：找到站点上所有<a href='*.pdf'>链接，对每个 PDF URL 发起 HEAD 请求，读取Content-Length响应头，按上述字节阈值标记问题文件。

单文件检查可直接使用 curl：

# 通过 HTTP 头检查单个 PDF 的大小 curl -I https://example.com/docs/annual-report.pdf | grep -i content-length # 文件大小字节换算速查 # 1 MB = 1,048,576 bytes # 10 MB = 10,485,760 bytes # 60 MB = 62,914,560 bytes

为什么用 HEAD 而不是 GET？HEAD 请求只返回响应头、不下载文件体，既拿到了精确的Content-Length字节数，又不消耗流量和带宽，适合批量扫描全站 PDF。拿到字节数后，与规则中的三个关键数字比对即可分级：

• 10,485,760（10 MB）→ 压缩审查线
• 15,728,640（15 MB）→ 部分索引风险线
• 62,914,560（60 MB）→ 很可能被完全跳过

在批量审计的场景下，可以把全站 PDF 链接列表交给脚本，逐个发起 HEAD 请求并按上述阈值自动分级输出报告；这也正是本项目将该技能以结构化 prompts（check / fix / explain / codeReview）形式内置进 SKILL.md 的原因——AI Agent 可以按这些指令直接执行完整审计流程。

值得补充的是，Front-End-Checklist 自身在处理链接元数据时，就把.pdf归入非 HTML 扩展名集合（见 apps/web/lib/url-metadata.ts），与.png、.jpg、.zip、.mp4等二进制资源一视同仁，不做 Open Graph 抓取。这说明在实际工程体系中，PDF 始终被当作"需特殊对待的二进制文档"而非普通 HTML 页面来处理——这恰好印证了本规则的前提：PDF 的索引行为与 HTML 完全不同，必须单独审计。

修复方案一：用 Ghostscript 压缩 PDF

对超标的 PDF，首选修复手段是压缩。规则推荐的命令行工具是Ghostscript，可直接在终端完成批量压缩：

gs -sDEVICE=pdfwrite \ -dCompatibilityLevel=1.4 \ -dPDFSETTINGS=/ebook \ -dNOPAUSE \ -dQUIET \ -dBATCH \ -sOutputFile=compressed.pdf \ original.pdf

参数说明：

• -sDEVICE=pdfwrite：指定输出设备为 PDF 写入器，即重新生成一份 PDF；
• -dCompatibilityLevel=1.4：输出 PDF 1.4 兼容级别（如需更高兼容性可调整）；
• -dPDFSETTINGS=/ebook：压缩预设（详见下表）；
• -dNOPAUSE：处理过程中不暂停等待确认，适合批量；
• -dQUIET：抑制非必要输出，只保留错误信息；
• -dBATCH：处理完所有输入文件后自动退出；
• -sOutputFile=compressed.pdf：输出文件名。

-dPDFSETTINGS预设直接影响输出质量与体积的取舍，规则给出了完整对照：

压缩之外，还应主动移除阅读不需要的冗余内容：嵌入式高分辨率图片、内嵌字体、多余元数据。这些往往是 PDF 体积膨胀的主要来源。

如果站点不是命令行优先，也可使用图形化/在线工具：Adobe Acrobat（File → Reduce File Size 菜单）、Smallpdf、ILovePDF、PDF24。

修复方案二：HTML 配套页面策略

当压缩仍不足以把关键内容降到安全阈值内时，规则给出了兜底方案：为 PDF 内容创建一个 HTML 落地页作为主要索引版本，把 PDF 作为附属下载提供。

<!-- HTML page for the PDF content --> <article> <h1>Annual Report 2024</h1> <p>Key findings from our 2024 annual report...</p> <!-- full text content here --> <a href="/reports/annual-2024.pdf" rel="nofollow"> Download PDF (8.2 MB) </a> </article>

关键要点：

• HTML 页面被完整索引，全文内容进入搜索引擎；
• 下载链接使用rel="nofollow"：当你不希望 PDF 本身被单独索引时，明确告诉爬虫不要追踪这个链接；
• 在链接文案中标注文件大小（如 "8.2 MB"），既是友好的用户体验，也便于爬虫和用户预判下载成本；
• 对重要内容而言，这个策略通常比单纯压缩更有价值——HTML 页面几乎总是比相同内容的 PDF 获得更高排名。

PDF 自身的 SEO 最佳实践

即使 PDF 达标，也要确保它能被正确、完整地解析。规则给出了四条底线：

1. 补充元数据：在 PDF 属性中设置 Title、Author、Subject，保证索引结果的标题与摘要质量；
2. 禁止加密/密码保护：加密 PDF 无法被爬虫读取内容；
3. 使用描述性文件名：annual-report-2024.pdf优于doc123.pdf，文件名本身就是索引信号；
4. 避免无 OCR 的扫描件：扫描 PDF 的文本是图片形式，无法被索引——必须经 OCR 转成可检索文本。

代码审查清单（Code Review）

规则将上述审计固化为可执行的审查要点，适合直接写入 CI 或代码审查流程：

1. 找出所有.pdf扩展名的<a href>链接；
2. 对每个 PDF URL 执行 HEAD 请求，检查Content-Length响应头；
3. 超过10,485,760字节（10 MB）→ 标记为压缩审查对象；
4. 超过15,728,640字节（15 MB）→ 标记为部分索引风险对象；
5. 验证每个 PDF URL 返回 200 状态码；
6. 验证响应头Content-Type为application/pdf（错误 MIME 类型会导致爬虫无法识别文件格式，与仓库中的 mime-type 规则 相互印证）。

关联规则与验证方法

规则在 pdf-size.mdx 中声明了四个强关联规则，审计时应一并考虑：

• broken-links：损坏的 PDF 链接应与超大 PDF 一起检测；
• mime-type：PDF 必须以正确的Content-Type: application/pdf提供；
• html-size与dead-end-pages：同属seo/technical区域，常一起评审。

部署修复后的验证分为两层：

自动化检查

• 检查渲染后的 HTML 与 HTTP 响应头，确认预期的元数据或可爬取信号存在；
• 用 Google Search Console（或等效工具）测试受影响的 URL；
• 部署后对代表性页面集合重新爬取。

人工检查

• 确认修改没有引入与 canonical-url、robots、结构化数据互相冲突的信号。

例外情况说明

规则也明确了三类不应机械套用的场景：

• 必要的工具页或合规页面可以有意保持精简，不应按排名导向内容的编辑深度标准评判；
• AI 辅助起草本身不是问题，应标记的是无依据的主张、缺失人工编辑审查或低原创输出；
• 当页面同时存在信任信号问题与抓取/索引问题时，应先让页面具备排名资格，再改善内容质量信号。

规则在项目中的生成与使用方式

值得说明的是，你读到的这份 pdf-size 技能并非手工维护的孤立文档，而是由 scripts/generate/generate-skills.ts 从规则 MDX 的 frontmatter 自动生成的：每一条规则会被转换为skills/{category}/{slug}/目录，内含面向 Agent 的SKILL.md（name、description、prompts 指令）与面向人工阅读的references/rule.md（完整正文）。也就是说，本文讲述的阈值、命令、策略，与规则源文件 pdf-size.mdx 保持同源一致，可以直接作为你站点审计的标准依据。

总结成一句话：先 HEAD 请求测字节，10 MB 压缩、15 MB 警示、60 MB 必改；压缩不掉就上 HTML 配套页，PDF 只做下载附件——这就是 Front-End-Checklist 给出的 PDF 文件大小完整治理方案。