Front-End Checklist 实战：把链接 PDF 控制在 60 MB 以内，保住索引与排名

本文基于 Front-End Checklist 仓库中的 SEO 规则pdf-size（关联文档：rule.md、SKILL.md）展开。当站点对外发布年报、白皮书、法律文书、产品手册等可下载 PDF 时，文件体积直接影响 Googlebot 的抓取完整性：超过阈值的大文件会被截断或直接跳过，导致内容无法进入搜索结果。读完本文，你将掌握用 HTTP 头检测 PDF 体积、用 Ghostscript 压缩、以及用 HTML 配套页面保住内容索引的完整实战方案。

一、这条规则在 Front-End Checklist 中的定位

Front-End Checklist 将pdf-size归类为seo / technical类目下的中等优先级规则（priority:medium），难度为intermediate，预估修复时间15 分钟。它的官方定义是一句话：

对照 Googlebot 的 60 MB 截断限制，检查被链接的 PDF 文件大小。

该规则的规范内容同时存在于两处、内容互为印证：

• 技能参考文档：skills/pdf-size/references/rule.md，即本文的主体骨架；
• 规则的 MDX 规范版本：packages/content/rules/en/seo/pdf-size.mdx，包含完整 frontmatter（categories、priority、difficulty、estimatedTime、tldr、prompts、relatedRules、sources）；
• 技能速查卡：skills/pdf-size/SKILL.md，面向审计场景的 Quick Reference。

在仓库的规则数据模型（packages/schemas/src/index.ts）中，每条规则由title、slug、categories、priority、prompts（check / fix / explain / codeReview）、sources（含 authority 与 role）等字段构成。pdf-size的sources标注了 Google Search Central 的《File types indexable by Google》与《File size limits for indexing》两份文档为 primary 权威来源——也就是说，本规则的阈值依据来自 Google 官方的抓取器说明，而非社区猜测。

二、为什么 PDF 体积关乎 SEO 生死

Google 会索引 PDF，并可能直接在搜索结果中展示 PDF 文件。但这条规则的存在，正是源于一个容易被忽略的细节：

PDF 超出 Googlebot 的下载阈值后，会被部分抓取（仅开头一部分进入索引）或完全跳过。

也就是说，即使一个 PDF 被大量高质量页面链接，只要文件过大，其内容仍可能从搜索结果中消失。规则原文（whyItMatters）对此的总结是：

超出 Googlebot 下载阈值的 PDF 会被部分抓取或跳过，即使它们被索引良好的页面链接，内容也可能不会出现在搜索结果中。

这正是为什么文件体积控制属于“可发现性工作”的一部分，与 HTML 配套页面（见第五节）和 crawl-friendly 的文件交付方式同等重要。

除此之外，SKILL.md 的 Explain 还补充了两点工程层面的影响：

• 大文件会拖慢抓取速度、消耗抓取预算（crawl budget），间接影响全站其他页面的抓取频率；
• 保持 PDF 小巧，才能确保其全部内容出现在搜索结果中，而不是只有开头几页。

三、Googlebot 的尺寸限制：从 15 MB 到 60 MB

Google 官方并未公布一个精确的字节上限，但公开文档给出了两个关键数字：

规则原文进一步明确了行为模式：

• 15 MB 以上：抓取可能出现问题；
• 60 MB 左右：内容索引的实际上限；
• 超大文件：被跳过或只索引第一部分。

需要强调的事实边界：这是“Google 未发布精确字节限制”前提下的工程经验值，因此规则将它表述为“documented upper limit”而非精确承诺。

四、尺寸目标：你的 PDF 该有多大

规则给出了一张可直接对照的目标表：

这套分级的意义在于：不要等到 60 MB 才动手。5 MB 以下是理想区间；5–15 MB 虽然可用，但已经建议压缩；一旦进入 15–60 MB，就应当视为“风险区间”，优先考虑压缩或 HTML 配套策略。

五、如何检测：HTTP 头一行命令见分晓

规则的 Code Example 给出了最轻量的检测方式——用curl的-I（HEAD 请求）读取Content-Length响应头，不需要下载整个 PDF：

# 通过 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

字节换算在实际审计时非常有用，因为Content-Length头返回的是字节数：

• 10 MB = 10,485,760 bytes（建议进入压缩评审）
• 15 MB = 15,728,640 bytes（判定为部分索引风险）
• 60 MB = 62,914,560 bytes（判定为大概率被跳过）

SKILL.md 的 Code Review 指令把检测流程固化为可复现的审计步骤：

1. 找出站点上所有<a href>中以.pdf结尾的链接；
2. 对每个 PDF URL 发起 HEAD 请求，读取Content-Length头；
3. 超过 10,485,760 字节（10 MB）：标记为需要压缩评审；
4. 超过 15,728,640 字节（15 MB）：标记为部分索引风险；
5. 同时校验 PDF URL 返回200 状态码，且Content-Type为application/pdf。

这一点与仓库的抓取器实现是同一套工程思路：多页爬虫 packages/crawler/src/index.ts 在抓取页面时正是依赖content-type头判断资源类型（text/html/application/xhtml+xml之外一律视为非 HTML），并在发现页面链接后递归遍历——审计 PDF 时对响应头（Content-Length、Content-Type、状态码）的依赖与之完全一致。同时，Content-Type: application/pdf的正确性由关联规则 mime-type 负责检查。

六、压缩 PDF：Ghostscript 一行命令

对于检出的大文件，规则推荐优先使用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：输出文件名；
• 末尾original.pdf为输入文件。

-dPDFSETTINGS的预设档位决定压缩力度（规则原文给出 dpi 参考值）：

除命令行外，规则也列出在线/图形化工具：Adobe Acrobat（File → Reduce File Size）、Smallpdf、ILovePDF、PDF24。

压缩的工程要点（来自 SKILL.md 的 Fix 指令）：移除阅读非必需的高分辨率嵌入图片、字体与元数据。体积大头通常不是文字，而是内嵌的位图图像与冗余字体子集。

七、压缩还不够？上 HTML 配套页面策略

当压缩无法把关键内容压进安全区间时，规则要求为重要内容创建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 页面会被完整索引，不受 60 MB 截断影响；
• 如果不需要 PDF 本身被单独索引，可在链接上加rel="nofollow"，避免把权重分给无法完整索引的二进制文件；
• 在下载链接旁标注体积（Download PDF (8.2 MB)）是提升用户体验的加分项，也符合 quality 规则对内容质量信号的要求。

规则原文特别以Warning 语气强调了 HTML 与 PDF 的优先级：

HTML 页面在相同内容的排名上几乎总是胜过 PDF。如果 PDF 中含有你想要排名的关键内容，应当把 HTML 版本作为主页面，将 PDF 作为补充下载提供。

这与 SKILL.md Fix 指令中的“HTML 作为主要可索引版本”完全一致。

八、PDF 自身的 SEO 最佳实践

在文件体积之外，规则还列出了 4 条 PDF 本身的 SEO 卫生要求：

1. 补齐元数据：在 PDF 属性中填写 Title、Author、Subject；
2. 禁止加密：确保 PDF 未设置密码保护或加密（加密文件无法被抓取内容）；
3. 描述性文件名：使用annual-report-2024.pdf而非doc123.pdf；
4. 避免无 OCR 的扫描件：扫描图片型 PDF 的文字是图像，无法被索引。

最后一条对“报告类 PDF”尤其致命——很多年报是把纸质件扫描后直接发布，从搜索引擎角度看等同于一张不可读的大图。

九、异常情况（Exceptions）

规则明确了几类豁免场景，避免把规则教条化：

• 必要的工具页/合规页可以刻意保持简短，不应按排名导向内容的编辑深度标准来评判；
• AI 辅助起草本身不是失败，应标记的是：未经支持的断言、缺失人工编辑评审、低原创性输出；
• 当页面同时存在信任信号问题与抓取/索引问题时，应先让页面具备排名资格，再改进内容质量信号。

这三条与仓库中 editorial-policy、trust-signals 等规则的评审口径一脉相承，体现的是“可索引 → 可排名 → 高质量”的优先级排序。

十、验证：上线后如何确认修复生效

规则提供了自动化与人工两套验证清单：

自动化检查（Automated Checks）：

• 检查渲染后的 HTML 与 HTTP 响应头，确认预期的元数据或可抓取信号存在（即Content-Length落在目标区间、Content-Type为application/pdf、状态码 200）；
• 用 Google Search Console 或等价工具测试受影响的 URL；
• 部署后对代表性页面集合重新抓取，确认新体积生效。

人工检查（Manual Checks）：

• 确认本次改动没有引入冲突的 canonical-url、robots 或结构化数据信号。

这提示我们：PDF 体积修复往往不是孤立动作——压缩会改变 URL 指向同一份文件，而新增 HTML 配套页则可能带来 canonical、robots 与结构化数据层面的连带影响，需要按 html-size 与 mime-type 等关联规则统一复查。

十一、关联规则与仓库延伸阅读

规则的relatedRules字段明确了同组检查项，在仓库中的对应文件为：

• broken-links：与大 PDF 一起检查失效 PDF 链接；
• mime-type：PDF 必须以application/pdf的 Content-Type 交付；
• html-size：与pdf-size同属 seo/technical 区域，常一起评审；
• dead-end-pages：同为 seo/technical 区域，常一起评审。

想在自己的审计流程中落地这套规则，可以：

1. 直接复用 SKILL.md 的 Check 指令作为审计 prompt；
2. 参考 rule.md 的完整实施细节；
3. 结合多页爬虫 packages/crawler/src/index.ts 做全站扫描——先找出所有.pdf链接，再逐一 HEAD 请求核对Content-Length、状态码与Content-Type；
4. 规则内容由 packages/rules 打包分发给外部消费者，规则 schema 由 packages/schemas/src/index.ts 约束校验。

一句话总结：PDF 也是网页资产，但它有 15 MB 风险线、60 MB 生死线——用 HEAD 请求体检、用 Ghostscript 减肥、用 HTML 页做备份，三件套做完，你的大文件内容才算真正进了搜索的视野。