做收錄排查时，大多數人只盯 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 自身的响應狀態正常，能被抓取、也能被下载。
先判断该不该收，再谈怎么收
- 有搜尋需求吗：有人會用關鍵詞直接搜這個文件，還是只會在站内下载？
- 能被理解吗：去掉周邊頁面，它自身還有没有可讀的文字信息？
- 有獨立價值吗：還是说它只是某個 HTML 頁面的複製品或附件？
三個問题里有两個是否定，通常就没必要花力气去推它進索引，把精力放回頁面本身更划算。
非 HTML 资源的收錄問题，多數不是“蜘蛛不来”，而是资源本身缺少可被理解的信息，或者抓取路径被服務器設定挡住了。先看日誌，再看资源類型，最後才考虑優化。
一個可操作的排查顺序
- 從服務器日誌里筛出图片、PDF 所在的域名或目錄，看搜尋蜘蛛的請求量和返回狀態。
- 如果請求很少，检查内鏈和 sitemap 是否给出了這些 URL。
- 如果請求多但狀態是 403、404、302 到登入頁，先修服務器和權限配置。
- 如果狀態正常却一直没有索引，检查资源本身是否有可提取文本和描述信息。
- 最後再考虑要不要為重要资源补 HTML 落地頁，把内容用文字承接出来。
把這套顺序固定下来，图片和 PDF 類的收錄問题會好排查很多，也不容易和 HTML 頁面的抓取問题互相混淆。