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

百度收录批量查询日志中应该核对哪些字段

做百度收录批量查询时，真正需要核对的不是“收录数”本身，而是日志里能证明这次查询是否有效、结果是否可信的字段。核心包括：查询时间、目标URL、查询方式、返回状态、收录判定结果、判定依据、异常信息。缺少其中任何一项，批量结果都可能把“没查到”误判成“没收录”。下面用一个假设例子说明。

假设例子：一次批量查询的日志长什么样

假设你手上有 200 条 URL，用脚本逐条向百度搜索提交查询，并记录日志。一条合格的日志行应该类似：

2025-03-01 10:12:33 | https://example.com/a | site:查询 | HTTP 200 | 已收录 | 结果标题匹配 | 无

这条日志里，每个字段都有用途：时间用于判断结果时效；URL 用于对应目标；查询方式决定结果口径；HTTP 状态说明请求是否成功；收录判定是结论；判定依据说明结论怎么来的；异常信息记录失败原因。如果只记“已收录/未收录”，后面出现争议时无法复盘。

必须核对的字段清单

• 查询时间：精确到分钟。收录状态会变化，没有时间的日志无法判断结果是否过期。
• 目标URL：必须是完整规范化的地址，包括协议和路径。同一页面带不带斜杠、带不带参数，可能对应不同结果。
• 查询方式：是 site: 查询、URL 直接查询，还是其他方式。不同方式的结果口径不同，不能混在一张表里比较。
• HTTP状态码：200 表示请求成功，403、429、5xx 表示被拒绝或服务异常。状态码不是 200 时，后面的“未收录”结论无效。
• 收录判定结果：明确写“已收录”“未收录”“无法判定”三选一，不要留空。留空会被后续统计当成未收录。
• 判定依据：例如“结果标题与目标标题一致”“结果URL完全匹配”“出现验证码”“返回空结果”。这是区分误判的关键。
• 异常信息：验证码、超时、连接重置、返回内容为空等。没有这一项，批量失败会被误读为批量未收录。

常见错误：把“查不到”当成“没收录”

第一次做批量查询最容易犯的错误，是只看结果数量不看过程字段。以下情况都会导致“未收录”误判：

1. 请求被限流，返回 429，但脚本仍把空结果记为未收录。
2. 触发验证码，返回页面不是搜索结果页，脚本却按“无匹配”处理。
3. URL 没有规范化，带 ?from=xxx 的地址查不到，就判定主页面没收录。
4. 查询时间没记，三天后拿旧日志当当前状态用。

判断方法很简单：先看 HTTP 状态码和异常信息，只有状态正常且没有验证码、超时等异常时，收录判定结果才可信。否则应把该条标记为“无法判定”，而不是“未收录”。

批量查询后应该怎么处理这些字段

把日志按“可信结果”和“不可信结果”分开统计。可信结果里，再按“已收录”和“未收录”分类；不可信结果单独列出，安排重试。重试时优先处理 429 和验证码，而不是直接改判定结论。对于“未收录”的 URL，还需要单独核对 robots.txt 是否禁止抓取、页面是否返回 404 或 500、是否有 noindex 标记。注意，robots.txt 的限制不等于可靠的索引移除，站点地图也不保证收录，这些都要靠日志字段和页面状态分别确认。

下一步：先拿 10 条 URL 跑一次小批量查询，把上面七个字段写进日志，人工核对其中 3 条的结果是否与日志一致。确认字段能支撑判断后，再扩大到全量。