很多站点的抓取问题，最后追到根源并不在页面文案，而是在图片、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 规则误伤；
- 抽查移动端首屏加载体积，记录优化前后的变化；
- 把发现的问题记录成条目，下次复查时逐条对照。
把检查做成例行工作
静态资源的问题很少一次性爆发，更多是随着页面迭代慢慢积累。建议把它固定成月度或季度的例行检查，和日志轮转、站点地图更新放在一起做。检查结果不要求立刻见效，重点是别让无效地址和无意义的请求长期占用抓取与带宽。