收录：日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2a3170e230a6.html
📄
收录：日志中应该核对哪些字段
要判断一个网址为什么没有被收录，日志里最该先核对的是请求时间、请求方法、请求URL、状态码、User-Agent、Referer、响应体大小、响应耗时这几类字段。它们分别回答“谁在什么时候来抓”“抓的是哪个地址”“抓取结果是否成功”“页面是否被正常返回”。只看访问次数或只看到有蜘蛛访问，都不足以判断收录问题。
先区分“抓取日志”和“收录结果”
日志只能证明抓取行为发生过，不能直接证明页面已经进入索引。一个URL被抓取多次，仍然可能因为内容质量、重复页面、状态码异常、robots限制或规范标签指向别处而不被收录。因此核对日志的目标不是找“收录证据”，而是找“抓取障碍”和“处理异常”。
如果日志中某个URL长期只有200，但搜索结果里始终没有，问题更可能在页面质量、重复内容或索引选择；如果日志里出现404、403、500、503或大量301，则应先处理抓取和响应层面的问题。
逐项核对日志字段及判断方法
- 请求时间：看抓取是否集中在短时间内爆发，还是长期没有访问。某URL连续多天没有抓取记录，说明它可能没有被发现，或抓取预算没有分配过来。
- 请求方法：
GET通常是正常抓取页面，HEAD可能只取头部信息。若只有HEAD没有GET，不能据此认定页面内容已被完整读取。 - 请求URL：核对协议、主机名、路径、参数和结尾斜杠。带
?utm_source=等参数的地址被抓取，不代表规范地址被抓取；大小写不同也可能被当成不同URL。 - 状态码：
200表示服务器正常返回；301、302要检查跳转链是否过长或最终落到无关页面；404说明地址不存在；403、401说明访问被拒绝；5xx说明服务器或应用出错。 - User-Agent：确认访问者是否为搜索引擎爬虫，以及是哪个爬虫。不同搜索引擎的爬虫名称不同，不能只看一个UA就推断所有搜索引擎的抓取情况。
- Referer：能帮助判断爬虫是从站内链接、站点地图还是外部链接进入。若某个URL只被站点地图引用、没有任何内链，抓取频率可能偏低。
- 响应体大小：同样是
200，返回0字节或极小体积通常意味着页面没有正常输出内容。可与正常页面的大小做对比，明显偏小就应检查模板、缓存或后端渲染。 - 响应耗时：抓取耗时长期过高，可能导致爬虫提前断开或降低抓取频率。先看应用响应时间，再看网络和服务器耗时，不要只凭一个慢请求下结论。
用一条日志记录做实际排查
假设日志中出现这样一条记录：
2025-03-10 08:12:31 GET /product/123 503 12ms Googlebot 0
这条记录说明：抓取发生在该时间点，访问的是/product/123，服务器返回503，响应很快但响应体大小为0。此时不应先怀疑“页面质量差”，而应先检查应用是否处于维护状态、是否触发了限流、数据库连接是否失败。处理完503后，再观察同一URL后续是否出现200记录。
如果记录变成200，但响应体大小仍然为0，则问题可能出在模板渲染、缓存返回空内容或CDN回源异常。若记录是200且响应体正常，但该URL仍未被收录，下一步才转向内容重复、规范标签、内链结构和索引选择等因素。
复查时要对比变化，而不是只看单次结果
处理完问题后，按以下顺序复查：
- 确认目标URL在日志中重新出现，且请求方法为
GET。 - 确认状态码为
200，跳转链不超过一跳，最终地址与规范地址一致。 - 确认响应体大小与同类正常页面接近，没有出现0字节或异常截断。
- 确认响应耗时回落到正常范围，没有持续超时或大量
5xx。 - 若以上都正常，再检查页面是否有唯一标题、正文、内链和规范标签，并等待搜索引擎重新处理。
需要提醒的是，robots.txt中的抓取限制不等于可靠的索引移除，站点地图也不保证收录，HTTPS同样不保证安全无漏洞或排名。日志核对解决的是“抓取和响应是否正常”，不能替代对页面内容和索引状态的判断。
下一步：从日志中导出目标URL最近30天的记录，按状态码和响应体大小分组，先处理非200和0字节的请求，再观察后续抓取是否恢复正常。
