蜘蛛日志分析，怎样区分访问抓取与索引结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b12c90c52e97.html
📄
蜘蛛日志分析，怎样区分访问抓取与索引结果
蜘蛛日志分析里，抓取和索引是两件事：日志只能证明搜索引擎的爬虫来过、取走了页面，不能证明页面已经进入索引。判断时要看同一批URL的三组证据是否对齐：日志中的抓取记录、抓取响应状态、以及搜索结果或站长工具里的索引状态。三者缺一，就不能下“已收录”的结论。
先定义两个结果，避免协作时各说各话
抓取结果是服务端可见的事实：某个爬虫在某个时间请求了某个URL，返回了什么状态码、多少字节、耗时多久。索引结果则是搜索引擎内部把页面纳入可检索集合后的状态，通常只能通过搜索表现或官方工具查询，无法从日志直接读出。
多人协作时最常见的返工，是一方拿着日志说“蜘蛛来过，没问题”，另一方在搜索里查不到页面，双方对“完成”的定义不同。交付前应把结论写成“已抓取，索引待确认”或“已抓取且索引已确认”，不要用“已处理”这类模糊表述。
从交付结果倒推：需要哪些资料
如果最终交付物是“某批URL的抓取与索引状态对照表”，那么必需资料包括：
- 服务器访问日志，字段至少覆盖时间、爬虫标识、请求URL、状态码、响应大小。
- 本次要核查的URL清单，最好来自站点地图或栏目页，而不是随手挑几条。
- 每台服务器的时区说明，否则日志时间和报表时间会对不上。
- 索引状态的查询结果，逐条记录查询方式与查询日期。
缺少URL清单，日志分析就退化成随机抽样；缺少时区说明，抓取频率会被算错；缺少索引查询日期，结论无法复核，交接后必然返工。
日志里能确认什么，不能确认什么
日志能确认抓取行为，例如某爬虫一天内请求了列表页多少次、是否抓取了分页、是否大量请求带参数的URL。日志不能确认索引结果。一个页面被抓取十次仍可能不被索引，原因可能是内容质量、重复、被规范标签指向别处，也可能只是尚未处理。
还要注意抓取限制与索引移除的区别：robots.txt 的抓取限制不等于可靠的索引移除，被禁止抓取的URL仍可能因外部链接出现在结果中。站点地图也不保证收录，它只是提交候选URL的渠道。判断时不要把“已提交站点地图”当作“已索引”。
状态码要分开看：200表示正常返回，不等于收录；301表示跳转，索引通常指向目标URL；404和410表示不可用，但不代表会立刻从索引中消失；5xx说明服务器出错，爬虫可能降低抓取频率。把这些混在一起统计，会得出错误结论。
可直接执行的对照步骤
- 从日志中筛出目标爬虫的记录，按URL聚合，得到每个URL的抓取次数、最近抓取时间、状态码分布。
- 把URL清单与聚合结果做左连接，标记“有抓取记录”和“无抓取记录”。
- 对“有抓取记录”的URL逐条查询索引状态，记录查询日期和查询入口。
- 把结果分成四类：已抓取且索引可见、已抓取但索引不可见、未抓取、抓取被限制。
- 对“已抓取但索引不可见”的URL，先检查是否被规范标签指向其他页面、是否与其他页面高度重复、是否返回了非200状态，再决定是改内容还是继续等待。
假设某栏目有100个URL，日志显示其中80个被抓取且返回200，索引查询只有50个可见。此时不能写“收录率80%”，因为分母和口径都错了。正确写法是：抓取覆盖80%，索引可见50%，剩余30个需逐条核查原因。这里的数字仅为示例，实际以自己数据为准。
责任划分与验收标准
建议把任务拆成三段并明确责任人：日志提取由运维或后端负责，保证字段完整和时区正确；URL清单与索引查询由SEO执行人负责，保证查询日期可追溯；结论审核由交付负责人负责，确认没有把抓取当索引。
验收标准可以写成三条：每条URL都有抓取状态和索引状态两个字段；每个“索引不可见”的URL都有至少一条已核查的原因或“待观察”标记；所有查询日期和查询方式可被他人复现。满足这三条，交接后不需要重新跑一遍日志。
如果团队使用不同搜索引擎，索引状态要分别核查，不能用一个引擎的结果推断另一个。HTTPS也不构成索引或排名的保证，它只解决传输加密问题，与是否被收录是两回事。
下一步：拿一份现有日志和一份URL清单，按上面的四类分法做一次小范围对照，先确认团队对“已抓取”和“已索引”两个字段的定义一致，再扩大到全站。
