做收录排查时，大多数人只盯 HTML 页面：能不能抓到、正文有没有渲染、canonical 指得对不对。但一个站点里，图片、PDF、附件、音视频这些非 HTML 资源往往占不小的量，它们的抓取和索引路径跟普通页面并不相同。把两套逻辑混在一起看，很容易得出“内容没被收录”的错误结论。

抓取、解析、索引：非 HTML 资源少了一环

搜索引擎处理任何 URL 都要经过“发现—抓取—解析—决定是否进索引”。差别主要在解析这一步：HTML 会被渲染，提取出正文、内链、结构化数据，信息足够支撑一个独立页面；而图片、PDF、压缩包走的是各自的解析方式，能提取出来的东西少很多。

• 图片：理解主要来自所在页面的上下文、alt、周边文字和图片 sitemap，一张孤立的图很难有独立语义。
• PDF：正文通常可以被提取，也常能进索引，但标题层级、内链、可点击导航都很弱。
• 音视频：没有结构化数据的情况下，机器几乎读不懂内容，多数只作为页面资源存在。
• 压缩包、表格、安装包：一般只被当作下载文件，很少单独出现在搜索结果里。

图片收录常见的几个卡点

URL 被 CDN 或防盗链挡住

页面能被抓到，不代表图片也能。图片常托管在独立域名或对象存储上，如果那里有防盗链、签名过期、对搜索蜘蛛返回 403，抓取到的就只是一个空引用。先用日志确认图片域名下有没有来自搜索蜘蛛的请求，比在页面上反复改 alt 更有效。

懒加载把 src 换成了占位图

为了首屏速度，很多站点把真实图片地址写在 data-src 里，src 先给一张占位图。如果触发加载需要滚动或点击，抓取时可能只看到占位图。这类情况优先让首屏图片直接用真实 src，或用 noscript 保留一份可读地址。

图片 sitemap 里放的却是缩略图

有些图片 sitemap 由程序自动生成，抓的是列表页缩略图，尺寸小、内容与正文主图不一致。这不会直接导致什么问题，但会让索引里留下的版本跟用户实际看到的不是同一张。

PDF 收录：不是不能收，是信息太少

PDF 被收录是很常见的事，问题在于它常常“进去得容易，表现得很差”：

• 文件本身没有描述性标题，索引里出现的是文件名或扫描件首行。
• 正文是扫描图片，没有可提取文本，等同于一张大图。
• 站点用脚本强制下载，或对 PDF 请求返回 noindex、强制登录，抓取直接止步。
• 同一份文档有多个版本分散在不同 URL，彼此没有归一关系。

如果这些文档对业务重要，比较务实的做法是：给每份 PDF 配一个 HTML 落地页，把核心内容用文字写出来，PDF 作为附件链接在页面里；同时确认 PDF 自身的响应状态正常，能被抓取、也能被下载。

先判断该不该收，再谈怎么收

1. 有搜索需求吗：有人会用关键词直接搜这个文件，还是只会在站内下载？
2. 能被理解吗：去掉周边页面，它自身还有没有可读的文字信息？
3. 有独立价值吗：还是说它只是某个 HTML 页面的复制品或附件？

三个问题里有两个是否定，通常就没必要花力气去推它进索引，把精力放回页面本身更划算。

非 HTML 资源的收录问题，多数不是“蜘蛛不来”，而是资源本身缺少可被理解的信息，或者抓取路径被服务器设置挡住了。先看日志，再看资源类型，最后才考虑优化。

一个可操作的排查顺序

1. 从服务器日志里筛出图片、PDF 所在的域名或目录，看搜索蜘蛛的请求量和返回状态。
2. 如果请求很少，检查内链和 sitemap 是否给出了这些 URL。
3. 如果请求多但状态是 403、404、302 到登录页，先修服务器和权限配置。
4. 如果状态正常却一直没有索引，检查资源本身是否有可提取文本和描述信息。
5. 最后再考虑要不要为重要资源补 HTML 落地页，把内容用文字承接出来。

把这套顺序固定下来，图片和 PDF 类的收录问题会好排查很多，也不容易和 HTML 页面的抓取问题互相混淆。