很多站長做收錄检查时，只看 HTML 頁面，忽略了图片、PDF、Office 文档、音视频文件這些资源。它們同样可能出現在搜尋结果里，而且判定逻辑和普通網頁並不完全一样。了解這些差异，能帮你判断哪些文件值得被收錄、哪些應该拦在索引之外。
索引里的内容不只有網頁
搜尋引擎的處理流程大致是：發現 URL、抓取内容、解析並理解、决定是否入库。這個流程對 HTML 之外的资源同样适用，只是“解析”這一步的难度不同。HTML 有明确的结构标簽，而一張图片、一個 PDF，需要額外的信息才能判断它讲的是什么。
這也是為什么同一份文件，放在 A 站能被索引，放在 B 站却長期没有反應——差別往往不在文件本身，而在它周围的上下文和站点整体质量。
图片：靠“周围环境”来理解
搜尋引擎並不能直接“看懂”一張图里的全部含义，它主要依赖几類信号：
- alt 属性：描述图片内容的简短文字，寫得具体比堆關鍵詞更有用。
- 文件名：product-1234.jpg 和 黑色羽绒服-正面.jpg 传達的信息完全不同。
- 上下文文字：图片所在段落的文字、图注、所在小标题，都會參與判断。
- 周邊連結：图片被哪類頁面引用，引用頁的主题是什么。
如果图片是頁面主体，比如商品图、菜谱步骤图，最好让它在正文里有明确的對應說明；如果只是為了装饰的图标、分割线，一般不需要专门做图片收錄優化，放進图片 sitemap 反而會增加無效抓取。
图片 sitemap 该放什么
图片 sitemap 适合放那些有獨立價值的图片，比如商品主图、教程配图、图库條目。把頁面上几十張缩略图全塞進去，對站点没有實际帮助，只會让抓取工具把時間花在重复资源上。
PDF 和文档：先解决“能不能讀”
PDF、Word、Excel、PPT 這些文件，被索引的前提是搜尋引擎能從中提取出文本。掃描件、图片拼成的 PDF，正文實际上是一堆像素，提取不出内容，自然很难获得好的收錄结果。
- 確認文件里存在可划選的文字。
- 文件属性里的“标题”“作者”字段尽量填完整。
- 文件体积不要過大，几百 MB 的文档會让抓取和解析都變得吃力。
- 给文件起一個可讀的文件名，URL 里的编碼尽量可讀。
另外，PDF 的收錄表現通常不如同内容的 HTML 頁面：HTML 能用标题、段落、内鏈把信息组织清楚，PDF 相對“死”。如果一份内容對业務重要，做成 HTML 頁面往往比只放一個 PDF 更合适。
响應头也會影响判断
文件所在服務器的响應头，如果 Content-Type 設定错誤，或者對范围請求返回異常狀態，都可能让抓取工具放弃處理。批量上传的附件，值得抽查几個看响應头是否正常。
视频：索引的往往是頁面，不是文件本身
视频文件一般很少作為獨立结果出現，更多是承载它的頁面获得展示。所以重点通常放在视频所在頁面的标题、描述、时長、封面，以及頁面结构是否能被正常抓取和解析上。
哪些文件不该被收錄
不是所有能被訪問的文件都應该進索引。常见的几類：
- 内部使用的表格、报價單、會议纪要，誤传到公開目錄。
- 同一份文件的多個副本，散落在不同目錄、不同版本号下。
- 临时導出文件、測試样例、舊版本备份。
處理方式要分清：如果文件還需要内部訪問，用 robots.txt 禁止抓取更稳妥；如果文件本身不该公開，應该直接從服務器刪除，而不是只做禁抓——文件只要還能被訪問，就存在被传播的可能。
索引控制解决的是“要不要被搜到”，不等于“要不要被看到”。涉及敏感内容的文件，刪除是第一選擇。
排查时的几個习惯
- 用 site: 语法加文件類型（如 filetype:pdf）抽查，看有多少非 HTML 资源被收錄。
- 翻服務器日誌，观察抓取工具是否在大量請求图片、附件。
- 检查图床或 CDN 域名是否被單獨索引，是否和主站形成重复。
- 给重要的文档類资源补上規范的 HTML 版本，別让 PDF 成為唯一入口。
總结一句：非 HTML 内容的收錄，本质上還是“有没有用、能不能被理解、值不值得分配一次抓取”。把上下文补清楚，把不该公開的清理掉，比反复追問某個文件為什么没被收錄更有效。