报表里的“已发现，尚未抓取”“已抓取，尚未编入索引”看起来只差一步，实际卡住的位置完全不同。服务器日志是少数能把这几步拆开的原始材料：它记录蜘蛛什么时候来过、请求了哪个地址、返回了什么状态码，而不是搜索引擎汇总之后的结论。日志不能直接告诉你页面会不会被收录，但能帮你判断问题出在发现、抓取，还是后面的处理环节。
日志能回答的三个问题
- 这个 URL 有没有被发现：日志里从未出现过，通常意味着入口不足，而不是内容质量不够。
- 发现之后有没有真的请求：只有一次试探性的请求，和持续多轮的抓取，含义并不一样。
- 那次请求算不算一次有效抓取：返回 200 且内容是最终页面，才算把页面交了出去。
先确认请求是不是真的蜘蛛
User-Agent 字段任何人都可以伪造，只按 UA 字符串筛选，容易把爬虫和仿冒请求混在一起。常用做法是：
- 对可疑的高频请求做反向 DNS 查询，确认域名归属；
- 比对搜索引擎公布的 IP 段，IPv4 与 IPv6 分开看；
- 注意 CDN、WAF、负载均衡可能只保留一份日志，源站未必能看到全部请求。
几种常见情况怎么读
反复抓老页面，新页面几乎不出现
这通常说明新的 URL 还没有找到可靠入口。可以顺着内链、列表页、sitemap 的顺序回查：新页面是否至少有一条来自站点内部、能被普通爬取的链接。日志里没有任何记录时，先补入口，比反复提交更有效。
新页面有请求，但状态码不对
如果日志里能看到新页面的请求，返回的却是 301、302、403、404 或 5xx，那么问题在服务器侧，跟内容质量无关。需要区分是重定向链太长、权限拦截，还是抓取时刚好遇到故障。把同一 URL 的多次请求状态码按时间排开，很容易看出是偶发还是稳定。
抓取频次整体下滑
频次是服务器资源、更新节奏、响应速度共同作用的结果，短期波动不代表惩罚。先确认响应时间有没有变慢、是否有大量相似页面在消耗抓取额度，再考虑是否收敛低价值 URL 的入口。
日志和报表对不上时的检查项
- 时区：日志按服务器时间记录，报表按站点设置时区，跨天对比容易错位。
- 身份：移动端与桌面端蜘蛛、图片和渲染相关请求可能使用不同 UA。
- 缓存：CDN 命中时源站没有记录，但蜘蛛确实拿到了页面。
- 抽样：部分日志方案只保留一部分记录，不能当成全量数据使用。
一个可执行的自查顺序
- 导出最近两到四周的原始日志，先按 UA 过滤出主要搜索引擎的请求。
- 把目标 URL 清单与日志里的地址做交叉比对，标出“从未出现”“出现过”“频繁出现”三类。
- 对出现过的地址按状态码分组，找出非 200 的部分，回到服务器定位原因。
- 对照 sitemap 与内链结构，确认新 URL 是否有稳定入口，入口是否多套了一层跳转。
- 把结果记录下来，隔一段时间再看同一批 URL 的变化，比一次性的结论更有参考价值。
日志反映的是抓取过程，不是收录结果。它能说明蜘蛛来没来、有没有拿到页面，但页面最终是否进入索引、出现在什么位置，还要看内容本身和质量判断，不能反向倒推。
把日志当成一份过程记录，用它排除“根本没被发现”“抓取被拦截”“服务器不稳定”这类前置问题，剩下的部分才轮到内容和质量层面去讨论。按这个顺序处理收录问题，会清楚很多。