📍 WDQWDWQD987AAAAA:216.73.217.13
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e826b2fcf0cd.html
📄

百度收录工具，日志中应该核对哪些字段

使用百度收录工具排查收录问题时，日志里最该优先核对的是抓取时间、请求URL、状态码、User-Agent、来源IP、响应大小和robots.txt结果这几类字段。它们能区分“百度没来抓”“抓了但被拒绝”“抓了但页面异常”“页面正常但未被索引”四种不同情况，避免把抓取问题和索引问题混为一谈。

准备阶段：先确认日志格式与字段含义

不同服务器输出的访问日志字段顺序不同。以常见的Nginx combined格式为例，一行日志大致包含：客户端IP、时间、请求方法、URL、协议版本、状态码、响应字节数、Referer、User-Agent。核对前要先确认你的日志格式定义，否则字段会读错。

建议先做一件事：在日志中筛选出User-Agent包含Baiduspider的行，单独导出成一份文件，后续所有核对都基于这份数据，避免和真实用户流量混在一起。

实施阶段：逐项核对的字段与判断依据

• 抓取时间：看百度最近一次访问距现在多久。如果长期没有新记录，说明抓取频率低或未被调度，而不是页面被惩罚。
• 请求URL：确认被抓的是目标页面，而不是参数页、旧版路径或错误拼接的地址。URL带多余参数会导致收录到非预期版本。
• 状态码：200表示正常返回；301/302看跳转是否指向最终页；404说明页面已失效；403/503可能被防火墙或限流拦截。状态码异常时，先修服务端，再谈收录。
• User-Agent：确认是百度蜘蛛而非伪装爬虫。可结合来源IP做交叉判断，但IP段会变化，不能只凭IP下结论。
• 来源IP：用于识别是否被CDN、WAF或负载均衡改写。如果日志里全是CDN节点IP，需要回源日志才能看到真实来源。
• 响应大小：返回字节数过小，可能是空页面、错误页或被拦截后的占位内容。对比正常页面的体积能快速发现异常。
• robots.txt结果：日志里出现对/robots.txt的请求是正常现象。但要单独确认目标URL是否被robots规则禁止抓取——被禁止抓取不等于被移除索引，这是两回事。

最关键的一步是把状态码和URL放在一起看。单独看状态码只能知道“这次请求成没成”，结合URL才能判断“百度想抓的到底是哪个地址”。很多收录问题就出在这里：百度抓的是带参数的旧地址，返回200，但 canonical 指向新地址，最终收录结果与预期不符。

验证阶段：用可复现的检查项确认结论

核对完日志后，用下面几个检查项验证判断是否成立：

1. 在日志中统计目标URL的状态码分布，200占比是否稳定。
2. 用curl -I或浏览器开发者工具模拟百度蜘蛛的User-Agent访问同一URL，对比返回状态码和响应大小是否与日志一致。
3. 检查服务器是否有防火墙、CDN或WAF规则会拦截特定User-Agent，这类拦截往往只在真实抓取时触发，本地访问看不出来。
4. 确认站点地图中提交的URL与日志中被抓取的URL是否一致。站点地图不保证收录，但地址不一致会直接导致抓取目标偏离。

如果日志显示抓取正常、状态码200、响应完整，但页面仍未收录，问题就不在抓取环节，而应转向内容质量、重复度和索引策略层面继续排查。

维护阶段：多人协作时的交付与复查

多人协作最容易出现的返工是：A说“百度没抓”，B说“抓了但404”，C说“已经修了”。为避免这种混乱，建议固定一份核对模板，每次排查都填写：日志时间范围、筛选出的百度抓取条数、目标URL状态码分布、robots是否放行、结论与待办人。

维护时注意两点：一是HTTPS不保证安全无漏洞，也不保证排名，证书配置错误反而可能导致抓取失败；二是不同搜索引擎对同一站点的抓取行为要分别核查，不能拿百度的日志结论直接推断其他引擎。日志文件建议保留足够长的周期，便于回溯抓取频率变化。

下一步可以直接从日志中导出最近30天包含Baiduspider的记录，按状态码分组统计，先定位异常比例最高的URL类型，再决定是修服务端、改robots还是调整页面结构。