收录网址：日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e0a37f27589e.html
📄
收录网址：日志中应该核对哪些字段
要判断一个网址为什么没被收录，日志里最该先核对的是请求时间、来源 IP 与 User-agent、请求方法、状态码、请求的完整 URL（含查询参数）、Referer，以及响应体大小。这七个字段能回答三个问题：搜索引擎是否来过、它拿到了什么、它是否被引导去了别处。多人协作时，把这几列固定成一份日志核对模板，交接和复查会省掉大量返工。
先分清两类日志，别拿错文件
服务器访问日志记录的是真实到达源站的请求，能证明某个爬虫是否抓取、抓到了什么状态码。而搜索平台后台提供的抓取统计，是平台自己汇总的口径，两者对不上是常事，不必强行对齐。需要核对“收录网址”相关问题时，优先看源站访问日志，因为它最接近事实。
如果站点前面有 CDN 或反向代理，源站日志里的来源 IP 可能是节点地址而不是爬虫真实 IP。这时要确认日志取的是哪一层，必要时改用 CDN 侧日志，或核对 X-Forwarded-For 一类转发字段。判断依据是：同一时间段的请求量是否与平台统计量级接近，差距过大说明日志层选错了。
逐字段看什么、怎么判断
- 时间：确认爬虫是否在预期时间窗口内访问过。若最近一次抓取是很久以前，问题在抓取频率，不在页面质量。
- User-agent：区分不同搜索引擎与普通用户。注意 UA 可以被伪造，不能只凭字符串下结论，要结合 IP 归属反查。
- 请求方法：
GET才是正常抓取；大量HEAD通常只是探测。看到POST出现在本该是内容页的 URL 上，说明链接或表单配置有问题。 - 状态码：
200表示正常返回；301/302看跳转目标是否是最终想收录的地址；403/404/410分别对应被拒绝、不存在、已删除；5xx是服务端故障，会直接抑制抓取。 - 完整 URL：带上查询参数的原始串才能看出是否被抓到了带跟踪参数的重复版本，或大小写、结尾斜杠不一致的变体。
- Referer：能看出爬虫是从哪个页面发现这个网址的，有助于定位内链结构问题。
- 响应体大小：返回
200但字节数极小，往往是空模板、验证页或错误页伪装成正常页，这类页面通常不会被正常收录。
一个可执行的核对流程
假设要排查 https://example.com/a 长期未被收录，可以按下面顺序做（示例域名为假设）：
- 在日志中筛选该路径，统计最近一段时间的请求次数与最近一次时间。
- 若完全没有记录，先查内链是否可达、
robots.txt是否放行、站点地图是否列出该地址。注意robots.txt只控制抓取，不等于可靠的索引移除手段。 - 若有记录，逐条看状态码与响应体大小，确认返回的是真实内容页。
- 若状态码是跳转，记录跳转链的每一跳，确认最终落点是否与想收录的地址一致。
- 若一切正常但仍未收录，把该 URL 单独提交，并在之后复查日志中是否出现新的抓取记录。
多人协作时怎么交付才不返工
把上面的字段做成固定表头，每行一条请求，附上“结论”和“下一步”两列。结论只写已定位的事实，例如“最近抓取为 2024-01-01，状态码 200，响应体 12KB”，不要写“可能是权重问题”这类无法验证的猜测。区分“可能原因”和“已经定位的原因”，是减少扯皮的关键。
复查时对比同一 URL 在修改前后的日志：抓取次数是否变化、状态码是否变化、响应体是否变大。如果没有任何变化，说明改动没有生效或爬虫尚未重访，此时继续等待或再次提交，而不是重复改同一处。
下一步：拿站点上任意一个待排查的收录网址，按上述字段从日志里导出最近 30 天的记录，填进协作模板，标出第一个异常字段，再决定是改内链、改状态码还是改服务端配置。
