【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载导读本指南基于 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 MBGoogle 会索引 PDF并将其直接展示在搜索结果中。但 PDF 文件过大时下载过程中可能被截断导致只有文件前半部分被索引这就是部分索引partial indexing。因此凡是作为可索引内容资源被链接的 PDF都必须控制在 Googlebot 的下载阈值之内。规则原文给出的核心结论是Googlebot 在爬取时会对超过15 MB的文件进行截断处理60 MB是文档化的内容索引实际上限超过上限的文件会被跳过或只索引第一个片段。这意味着即使 PDF 被大量高权重页面链接只要文件过大其中的内容依然可能完全不出现在搜索结果中——文件大小控制与 HTML 配套页面策略、爬虫友好的文档交付属于同一类可发现性工作。大小阈值速查表审计前先建立明确的判定标准。规则提供了如下分级参考文件大小状态 5 MB理想Ideal5–15 MB可接受Acceptable——建议考虑压缩15–60 MB有部分索引风险At risk of partial indexing 60 MB很可能被 Googlebot 跳过此外检查指令check中规定了更严格的操作阈值超过10 MB10,485,760 字节标记为需要压缩审查超过15 MB15,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 而不是 GETHEAD 请求只返回响应头、不下载文件体既拿到了精确的Content-Length字节数又不消耗流量和带宽适合批量扫描全站 PDF。拿到字节数后与规则中的三个关键数字比对即可分级10,485,76010 MB→ 压缩审查线15,728,64015 MB→ 部分索引风险线62,914,56060 MB→ 很可能被完全跳过在批量审计的场景下可以把全站 PDF 链接列表交给脚本逐个发起 HEAD 请求并按上述阈值自动分级输出报告这也正是本项目将该技能以结构化 promptscheck / 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 -sDEVICEpdfwrite \ -dCompatibilityLevel1.4 \ -dPDFSETTINGS/ebook \ -dNOPAUSE \ -dQUIET \ -dBATCH \ -sOutputFilecompressed.pdf \ original.pdf参数说明-sDEVICEpdfwrite指定输出设备为 PDF 写入器即重新生成一份 PDF-dCompatibilityLevel1.4输出 PDF 1.4 兼容级别如需更高兼容性可调整-dPDFSETTINGS/ebook压缩预设详见下表-dNOPAUSE处理过程中不暂停等待确认适合批量-dQUIET抑制非必要输出只保留错误信息-dBATCH处理完所有输入文件后自动退出-sOutputFilecompressed.pdf输出文件名。-dPDFSETTINGS预设直接影响输出质量与体积的取舍规则给出了完整对照预设对应分辨率适用场景/screen72 dpi纯屏幕阅读体积最小/ebook150 dpi电子书/阅读器性价比均衡默认推荐/printer300 dpi打印质量/prepress300 dpi印刷出版级质量体积最大压缩之外还应主动移除阅读不需要的冗余内容嵌入式高分辨率图片、内嵌字体、多余元数据。这些往往是 PDF 体积膨胀的主要来源。如果站点不是命令行优先也可使用图形化/在线工具Adobe AcrobatFile → Reduce File Size 菜单、Smallpdf、ILovePDF、PDF24。修复方案二HTML 配套页面策略当压缩仍不足以把关键内容降到安全阈值内时规则给出了兜底方案为 PDF 内容创建一个 HTML 落地页作为主要索引版本把 PDF 作为附属下载提供。!-- HTML page for the PDF content -- article h1Annual Report 2024/h1 pKey findings from our 2024 annual report.../p !-- full text content here -- a href/reports/annual-2024.pdf relnofollow Download PDF (8.2 MB) /a /article关键要点HTML 页面被完整索引全文内容进入搜索引擎下载链接使用relnofollow当你不希望 PDF 本身被单独索引时明确告诉爬虫不要追踪这个链接在链接文案中标注文件大小如 8.2 MB既是友好的用户体验也便于爬虫和用户预判下载成本对重要内容而言这个策略通常比单纯压缩更有价值——HTML 页面几乎总是比相同内容的 PDF 获得更高排名。PDF 自身的 SEO 最佳实践即使 PDF 达标也要确保它能被正确、完整地解析。规则给出了四条底线补充元数据在 PDF 属性中设置 Title、Author、Subject保证索引结果的标题与摘要质量禁止加密/密码保护加密 PDF 无法被爬虫读取内容使用描述性文件名annual-report-2024.pdf优于doc123.pdf文件名本身就是索引信号避免无 OCR 的扫描件扫描 PDF 的文本是图片形式无法被索引——必须经 OCR 转成可检索文本。代码审查清单Code Review规则将上述审计固化为可执行的审查要点适合直接写入 CI 或代码审查流程找出所有.pdf扩展名的a href链接对每个 PDF URL 执行 HEAD 请求检查Content-Length响应头超过10,485,760字节10 MB→ 标记为压缩审查对象超过15,728,640字节15 MB→ 标记为部分索引风险对象验证每个 PDF URL 返回 200 状态码验证响应头Content-Type为application/pdf错误 MIME 类型会导致爬虫无法识别文件格式与仓库中的 mime-type 规则 相互印证。关联规则与验证方法规则在 pdf-size.mdx 中声明了四个强关联规则审计时应一并考虑broken-links损坏的 PDF 链接应与超大 PDF 一起检测mime-typePDF 必须以正确的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.mdname、description、prompts 指令与面向人工阅读的references/rule.md完整正文。也就是说本文讲述的阈值、命令、策略与规则源文件 pdf-size.mdx 保持同源一致可以直接作为你站点审计的标准依据。总结成一句话先 HEAD 请求测字节10 MB 压缩、15 MB 警示、60 MB 必改压缩不掉就上 HTML 配套页PDF 只做下载附件——这就是 Front-End-Checklist 给出的 PDF 文件大小完整治理方案。赞分享【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载相关推荐Front-End-Checklist 指南如何审计并修复 robots.txt、noindex 与 canonical 的索引冲突信号Front End Checklist 指南如何审计并修复 robots.txt、noindex 与 canonical 的索引冲突信号 索引可见性IndeFront-End-Checklist 实战修复与移除站外失效链接broken external links完整审计指南Front End Checklist 实战修复与移除站外失效链接broken external links完整审计指南 本文以 skills/brokeFront-End-Checklist 实践指南检测并修复失效的外部链接broken external linksFront End Checklist 实践指南检测并修复失效的外部链接broken external links 外链失效link rot是影响站点创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考