为什么要从日志入手
后台的抓取统计通常只给出汇总数字，比如某个时间段有多少次抓取、多少条 URL 被处理。它很难回答一个具体问题：某个目标 URL 到底有没有被搜索蜘蛛发现过。服务器日志记录的是每一次真实请求，能看到 UA、请求的路径、返回的状态码和发生时间，因此在排查 URL 发现问题时更直接。
需要先明确一点：日志只能证明“请求发生过”，不能证明“已经被收录”。发现、抓取、收录是三件不同的事，日志主要覆盖前两件。
先确认日志里哪些请求是搜索蜘蛛
第一步是筛出搜索蜘蛛的请求，通常按 User-Agent 过滤，比如包含 Googlebot、Bingbot、Baiduspider 等标识。但要注意：
- UA 可以被伪造，只看 UA 容易把普通爬虫或采集程序当成搜索蜘蛛；
- 更稳妥的做法是结合 IP 反查（反向 DNS 或官方 IP 段列表）交叉验证；
- 部分蜘蛛会使用移动端或图片、视频专用 UA，过滤规则别写得太窄。
如果站点前面有 CDN 或反向代理，日志里的来源 IP 可能是节点 IP，这时要去 CDN 的日志或回源日志里看，否则容易得出错误结论。
要看的关键字段
1. 请求路径
先看入口页的路径有没有被请求。入口页是蜘蛛发现新链接的主要来源，如果入口页长期没有抓取记录，后面的目标 URL 自然也难以被发现。
2. 状态码
状态码能反映蜘蛛看到的是什么：
- 200：正常返回，但不代表内容就是我们希望它看到的那一版，缓存或中间层可能返回了旧内容；
- 301 / 302：说明发生了跳转，要顺着看最终落在哪个地址；
- 403 / 401：可能被防火墙、频率限制或权限校验拦住了；
- 404 / 410：链接目标已经不存在，蜘蛛自然不会继续深入；
- 5xx：服务端错误，短时间大量出现会让抓取节奏变慢。
3. Referer
Referer 可以帮助判断蜘蛛是从哪个页面跳到目标 URL 的。如果目标 URL 的请求 Referer 是入口页，说明链接被发现并跟进了；如果 Referer 为空，可能是通过 sitemap 或其他渠道进入的。
4. 请求时间
把入口页被抓的时间和目标 URL 首次被抓的时间放在一起看，能大致判断发现链路是否顺畅。若入口页频繁被抓，目标 URL 却始终没有请求记录，问题多半出在链接结构或链接可达性上。
“发现”和“抓取”是两个阶段
蜘蛛先发现 URL，把它放进待抓取队列，之后才可能真正请求。队列有优先级和容量限制，所以出现下面两种情况都算正常：
- 入口页已抓取，目标 URL 暂时没有请求记录，可能只是还在排队；
- 目标 URL 被抓取过一次，但之后很久没有再次抓取，可能和更新频率、站点权重有关。
发现不等于抓取，抓取也不等于收录。日志能确认的是前两步，收录结果仍要以搜索平台的站长工具为准。
常见的几种误判
把 CDN 缓存命中当成蜘蛛抓取
如果 CDN 直接返回缓存内容，回源日志里可能看不到这条请求，于是误以为蜘蛛没来。反过来，如果 CDN 缓存了旧版入口页，蜘蛛看到的链接列表可能和当前页面不一致。
日志被采样或轮转
高流量站点常开启日志采样，或者日志只保留最近几天。按采样后的日志统计“有没有被抓过”，结论会偏保守。
把验证页当成正常页面
有些站点对可疑请求返回 200，但内容是验证码或拦截提示。状态码看着正常，实际蜘蛛并没有拿到链接。
只看总量不看具体 URL
抓取总量上升不代表目标 URL 一定被抓。排查时要落到具体路径，而不是停留在趋势图上。
一个简单的排查顺序
- 确认日志来源可靠，排除 CDN、代理、采样的干扰；
- 筛出搜索蜘蛛请求，验证 UA 与 IP；
- 查入口页请求记录与状态码；
- 查目标 URL 请求记录、状态码与 Referer；
- 对比时间线，判断是发现环节慢，还是抓取配额或优先级的问题；
- 必要时同步看 sitemap 的抓取情况，互相印证。
日志分析的价值在于把模糊的“感觉没被抓”变成可核对的事实。它不能直接提升抓取，但能让排查少走弯路。