很多站点的抓取問题，最後追到根源並不在頁面文案，而是在图片、CSS、JS 這類静態资源上。它們平时不顯眼，一旦地址失效、体积失控或者被脚本挡住，用戶看到的是空白和错位，抓取端看到的是残缺的頁面和不必要的請求。下面這套自查思路，适合放進日常运维里按季度走一遍。
先分清三類問题
静態资源出問题，通常表現為三種情况，排查方向完全不同：资源缺失（返回 404 或 403）、资源過重（加载慢、超时）、资源不可见（地址存在但抓取端看不到）。先归類再動手，比一上来就压缩图片有效得多。
一、图片地址是否真的存在
先從服務器日誌里筛一遍图片請求，看狀態碼分布。常见的坑有三個：
- 图片被刪除但頁面引用没清理，長期返回 404；
- 运维把图片目錄挪了位置，返回的是自定义错誤頁，狀態碼却是 200，形成典型的软 404；
- 图片走 CDN，回源地址寫错，邊缘节点一直返回 403。
這几種情况都會让抓取端反复請求無效地址。處理方式不复杂：把 404 的引用改掉或者补图，把返回 200 的错誤頁修正為真實狀態碼，把 CDN 回源配置核對一遍。
二、懒加载與占位图
懒加载本身没什么問题，問题在于實現方式。如果图片的真實地址是頁面加载後由脚本寫入 src 属性的，抓取端拿到的初始 HTML 里就只有一個占位图地址，正文配图等于不存在。更稳妥的做法是让图片地址直接寫在 HTML 里，用原生属性控制延迟加载，脚本只作為增强手段。
判断方法很简單：打開頁面源碼搜尋图片地址，如果搜不到真實地址，只在脚本里看到它，就值得警惕。
三、资源体积與响應式
首頁一次加载几十張大图，單張几百 KB，用戶流量和服務器带宽都被消耗，抓取端同样要為這些资源付出時間。可以按下面的顺序處理：
- 统一压缩图片，優先用 WebP 等現代格式，保留原图备份；
- 按展示尺寸輸出多套图，用 srcset 让浏览器選擇合适的版本；
- 首屏之外的图片再考虑延迟加载，首屏關键图不要延迟；
- 给图片补上有意义的 alt 文本，既照顾可訪問性，也让图片内容有基本的文字說明。
四、静態资源域名與 robots 規則
不少站点把图片、CSS、JS 放在單獨的静態域名上。如果這個域名的 robots.txt 里寫了整站 Disallow，或者根本没配置，抓取端就無法获取样式和图片，頁面渲染出来的样子會和用戶看到的差距很大。自查时確認三点：静態域名可正常訪問、robots 規則没有整站屏蔽、DNS 與證书狀態正常。
五、CSS 與 JS 屏蔽的副作用
有些站点為了节省资源，直接在 robots.txt 里屏蔽 CSS 和 JS 目錄。這會让抓取端难以判断頁面是否正常渲染，也可能把正文里由脚本生成的内容一並漏掉。如果确實要屏蔽，先確認頁面在不加载脚本时仍能展示主要内容。
一份可执行的检查清單
- 拉取最近一周的服務器日誌，統計图片與静態资源的 4xx、5xx 比例；
- 随机抽查十篇内容頁，查看源碼中图片真實地址是否存在；
- 检查 CDN 缓存命中率與回源狀態碼，確認没有返回错誤頁；
- 核對静態资源域名是否被 robots 規則誤伤；
- 抽查移動端首屏加载体积，记錄優化前後的變化；
- 把發現的問题记錄成條目，下次复查时逐條對照。
把检查做成例行工作
静態资源的問题很少一次性爆發，更多是随着頁面迭代慢慢积累。建议把它固定成月度或季度的例行检查，和日誌轮轉、站点地图更新放在一起做。检查结果不要求立刻见效，重点是別让無效地址和無意义的請求長期占用抓取與带宽。